Subject: bug#9488: closed (Re: 24.3.50; Zombie process left after call-process)

From: [email-masked] (GNU bug Tracking System)
Date: Mon, 03 Dec 2012 21:51:03 +0000

Your bug report

#9488: 23.2; `call-process' races with SIGCHLD handler

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
9488: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9488
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: 24.3.50; Zombie process left after call-process
From: Paul Eggert <[email-masked]>
To: [email-masked], [email-masked]
Date: Mon, 03 Dec 2012 13:47:59 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

No further comment, so I installed the patch as Emacs trunk bzr 111081
and am marking bugs 9488 and 12980 as done.

Subject: 23.2; `call-process' races with SIGCHLD handler
From: Taylor R Campbell <[email-masked]>
To: [email-masked]
Date: Mon, 12 Sep 2011 20:14:11 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

`call-process' relies on `wait_for_termination' to block until the
SIGCHLD handler has run for the synchronous subprocess.  But this is
not the condition that `wait_for_termination' guarantees on exit.
Rather, if `wait_for_termination' returns, then either

(a) there is no process having the same pid as the child had, or
(b) a SIGCHLD has been delivered.

If the subprocess has died, but no SIGCHLD has been delivered yet,
then `wait_for_termination' may return even though the SIGCHLD handler
has yet to run.  As an aside, these conditions are not sufficient for
`wait_for_termination' to return: it may block indefinitely if the
operating system has already delivered SIGCHLD and reused the pid
before control enters `wait_for_termination'.  I have not observed
indefinite blocking behaviour in practice, but only because pids don't
get reused very fast.

What I have observed is process exit values of 0 that should have been
nonzero on

GNU Emacs 23.2.1 (i386--netbsdelf, X toolkit) of 2011-03-02.

I noticed this because `M-x grep' sometimes prompts me with `grep -nH'
and sometimes with `grep -nH -e', in turn because

(call-process "grep" nil nil nil "-e" "/dev/null")

sometimes returns 0 and sometimes returns 1 depending on who wins the
race.

I have not tested newer versions of GNU Emacs, but a cursory glance at
the code suggests that while the relevant subprocess code has grown
more unmaintainably complicated, the problem persists.