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

[Alan Third <alan@idiocy.org>]

David Reitter <david.reitter@gmail.com> 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