bug#12980: 24.3.50; Zombie process left after call-process

[Paul Eggert]

Eli, thanks for your review.  I'm attaching a
heavily-revised patch, which tries to take your comments
into account, along with several other issues I noticed in
my own analysis and testing.  In response to your comments:

On 11/27/2012 08:00 AM, Eli Zaretskii wrote:

> I'm confused by this commentary

The new patch removes that function and its associated
commentary.

> The feature, whereby this function (call-process) could return a
> description of errno, is hereby lost.  That's quite nasty in the MSDOS
> case

That feature is supported only by MS-DOS, right?  On all
other platforms an error is thrown.  Anyway, the new patch
attempts to preserve the MS-DOS behavior.

> This is wrong for MSDOS, because the temporary file is created before
> attempting to launch the process, and so it needs to be cleaned up
> even if we failed to launch the child process.

The new patch attempts to undo that change for MSDOS.

> This seem to assume that the only trouble in call-process could be
> from some signal.  Why is that true?

By the time that part of the code is reached, any other
failures (e.g., fork failure) have already been diagnosed
and an error would have been thrown or call-process would
have returned before getting to that location.

> Why is this eassert a good idea?  We don't need to enforce the Posix
> spec at a price of crashing Emacs on users, do we?  What bad things
> can happen if you see some other errno here?

It's not a question of enforcing Posix semantics.  It's a
question of catching potentially serious internal
programming errors in Emacs.  That part of the code has been
completely rewritten, so the details of the comment is moot.
However, the new code has an "eassert (errno == EINTR)" in
the new get_child_status function.  I preceded that with a
comment to try to help explain why the eassert is there.

> The condition testing that status is non-NULL must stay, because that
> argument can be NULL, even if Emacs currently never uses that option.

OK, thanks, I did that.

> it would be nice to have somewhere a commentary with an
> overview of how termination of child processes is handled.

I added some, before handle_child_signal.

g_spawn_sync.txt
Description: Text document