[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22008: 25.1; crash: kill-emacs does not wait for child processes to

From: Alan Third
Subject: bug#22008: 25.1; crash: kill-emacs does not wait for child processes to terminate
Date: Wed, 18 May 2016 22:16:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (darwin)

David Reitter <address@hidden> writes:

> The bug report below led me to reproduce the situation roughly with
> the following steps:
> Emacs -Q   (25.1 branch)
> Start a second emacs with 
>       (start-process "em2" nil 
>                      (car command-line-args) "-q")
> Then, in the child emacs, make sure we’re doing something in
> kill-emacs-hook so we don’t quit immediately:
>       (setq kill-emacs-hook '((lambda () (sit-for 1))))
> Now, in the parent process, do 
>       (kill-emacs)
> and answer the kill-the-process? question with yes.
> On my system that reliably leads to the crash that Konrad describes
> below. OS X 10.11.
> Looking at what’s happening, I think that the child is sent a SIGHUP
> in kill_buffer_processes(), and that we do not wait for the child to
> finish. The system then terminates the child prematurely.

I think this is actually simpler. Just sending a SIGHUP to Emacs causes
essentially the same crash:

    kill -hup <emacs pid>

You don't need to bother with nesting Emacs within Emacs.

It looks like this bit of code in nsterm.m -> ns_read_socket fires
emacs_abort (line 4122):

    if (++apploopnr != 1)
        emacs_abort ();

which then sends SIGABRT which basically just kills Emacs on the spot,
as you'd expect.

I don't know why emacs_abort gets called here, I don't understand this
bit of the code. Perhaps it's intentional, but I'd imagine you'd want
Emacs to quit cleanly on hang-up rather than just abort.
Alan Third

reply via email to

[Prev in Thread] Current Thread [Next in Thread]