[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 <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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#22008: 25.1; crash: kill-emacs does not wait for child processes to terminate,
Alan Third <=