[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
bug#22008: 25.1; crash: kill-emacs does not wait for child processes to terminate
Wed, 18 May 2016 22:16:33 +0100
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
> 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)
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.
|[Prev in Thread]
||[Next in Thread]|
- bug#22008: 25.1; crash: kill-emacs does not wait for child processes to terminate,
Alan Third <=