Zombie subprocesses

Zombie subprocesses

[Harald Hanche-Olsen]

I recently discovered that emacs has a bunch of zombie subprocesses.
A bit of experimenting reveals that if I run

(call-process "/bin/sleep" nil 0 nil "5")

then this returns immediately, as expected, but after 5 seconds, the
subprocess becomes a zombie and never goes away.

Is this the intended behaviour, or a bug? Should I file a bug report?

This is on OS X 10.8.2, Emacs built from trunk a couple weeks ago.

(I use this technique to start external viewers for various types of
files. But the program I use the most forks on its own, so I can
easily replace the argument 0 by nil and avoid the problem. But I
thought it worth reporting anyhow.)

- Harald

Re: Zombie subprocesses

[Paul Eggert]

On 11/23/2012 01:49 PM, Harald Hanche-Olsen wrote:
> I recently discovered that emacs has a bunch of zombie subprocesses.
> A bit of experimenting reveals that if I run
> 
> (call-process "/bin/sleep" nil 0 nil "5")
> 
> then this returns immediately, as expected, but after 5 seconds, the
> subprocess becomes a zombie and never goes away.
> 
> Is this the intended behaviour, or a bug? Should I file a bug report?

It's a bug.  Please file a bug report.  Sigh, and I just put a change
into emacs-24 that may trigger the same bug.  I'll try to look into
it later today, but I don't have easy access to OS X so this may
well require some help.

Re: Zombie subprocesses

[Ken Brown]

On 11/23/2012 5:23 PM, Paul Eggert wrote:
> On 11/23/2012 01:49 PM, Harald Hanche-Olsen wrote:
>> I recently discovered that emacs has a bunch of zombie subprocesses.
>> A bit of experimenting reveals that if I run
>>
>> (call-process "/bin/sleep" nil 0 nil "5")
>>
>> then this returns immediately, as expected, but after 5 seconds, the
>> subprocess becomes a zombie and never goes away.
>>
>> Is this the intended behaviour, or a bug? Should I file a bug report?
>
> It's a bug.  Please file a bug report.  Sigh, and I just put a change
> into emacs-24 that may trigger the same bug.  I'll try to look into
> it later today, but I don't have easy access to OS X so this may
> well require some help.

I can reproduce this on Cygwin (on the emacs-24 branch with your latest 
change), so it's not just an OS X issue.

Ken

Re: Zombie subprocesses

[Eli Zaretskii]

> Date: Fri, 23 Nov 2012 17:33:59 -0500
> From: Ken Brown <kbrown@cornell.edu>
> Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>, emacs-devel@gnu.org
> 
> On 11/23/2012 5:23 PM, Paul Eggert wrote:
> > On 11/23/2012 01:49 PM, Harald Hanche-Olsen wrote:
> >> I recently discovered that emacs has a bunch of zombie subprocesses.
> >> A bit of experimenting reveals that if I run
> >>
> >> (call-process "/bin/sleep" nil 0 nil "5")
> >>
> >> then this returns immediately, as expected, but after 5 seconds, the
> >> subprocess becomes a zombie and never goes away.
> >>
> >> Is this the intended behaviour, or a bug? Should I file a bug report?
> >
> > It's a bug.  Please file a bug report.  Sigh, and I just put a change
> > into emacs-24 that may trigger the same bug.  I'll try to look into
> > it later today, but I don't have easy access to OS X so this may
> > well require some help.
> 
> I can reproduce this on Cygwin (on the emacs-24 branch with your latest 
> change), so it's not just an OS X issue.

Doesn't happen in the native MS-Windows build, FWIW.  I tried on the
emacs-24 branch after Paul back-ported the sub-process related changes
from trunk.

Re: Zombie subprocesses

[Chong Yidong]

Paul Eggert <eggert@cs.ucla.edu> writes:

>> (call-process "/bin/sleep" nil 0 nil "5")
>> 
>> then this returns immediately, as expected, but after 5 seconds, the
>> subprocess becomes a zombie and never goes away.
>
> It's a bug.  Please file a bug report.  Sigh, and I just put a change
> into emacs-24 that may trigger the same bug.  I'll try to look into
> it later today, but I don't have easy access to OS X so this may
> well require some help.

I can reproduce this on GNU/Linux (x86_64-unknown-linux-gnu, latest
emacs-24 and trunk).

ps shows the process as "[sleep] <defunct>", which stays until Emacs
exits.  Emacs 24.2 does not have the same problem.

If you are looking into it now, I can wait till I hear back from you
before making the pretest.

Re: Zombie subprocesses

[Paul Eggert]

I've also been able to reproduce the bug.  Fixing this
is nontrivial, unfortunately, so I've removed the
patch from the emacs-24 branch (in bzr 110950).

I will look into it further as soon as I can, and will
follow up at Bug#8855.  I expect that any fix will
require further shakeout so it seems more appropriate
for the trunk than for the emacs-24 branch.  Sorry.

Re: Zombie subprocesses

[Eli Zaretskii]

> Date: Sat, 24 Nov 2012 00:26:36 -0800
> From: Paul Eggert <eggert@cs.ucla.edu>
> Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>, emacs-devel@gnu.org
> 
> I've also been able to reproduce the bug.  Fixing this
> is nontrivial, unfortunately, so I've removed the
> patch from the emacs-24 branch (in bzr 110950).
> 
> I will look into it further as soon as I can, and will
> follow up at Bug#8855.  I expect that any fix will
> require further shakeout so it seems more appropriate
> for the trunk than for the emacs-24 branch.  Sorry.

Is leaving zombie processes here and there really worse than the
conflict with GTK-launched subprocesses?  Maybe I'm missing something,
but it sounds to me the other way around.  So IMO we should leave the
backported changes on the emacs-24 branch, even if it is eventually
decided not to fix the zombie problem, due to complexities of that
fix.

Re: Zombie subprocesses

[Paul Eggert]

On 11/24/2012 12:46 AM, Eli Zaretskii wrote:
> Is leaving zombie processes here and there really worse than the
> conflict with GTK-launched subprocesses?

My impression is yes, as the zombies can exhaust process slots,
which means the user won't be able to run subprocesses.
This could happen pretty quickly on a system where the number
of processes that a single user can run is limited to a small
number, for quota or other reasons (ulimit -u).  On the system
I happened to be running on when I was typing this message,
the limit was 100 processes per user.  This is pretty low,
but it's not ridiculously low.

In contrast, the conflict with GTK-launched subprocesses means
that GTK won't report proper exit statuses and will chatter
misleading messages to the user.  This is a real bug, sometimes
fairly serious, but still, it's typically less serious than not being
able to run subprocesses at all.

Re: Zombie subprocesses

[Harald Hanche-Olsen]

[Paul Eggert <eggert@cs.ucla.edu> (2012-11-23 22:23:40 UTC)]

> It's a bug.  Please file a bug report.  Sigh, and I just put a change

Done: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12980

[Paul Eggert <eggert@cs.ucla.edu> (2012-11-24 08:26:36 UTC)]

> I will look into it further as soon as I can, and will
> follow up at Bug#8855.

I made sure to put in a reference to that bug in my bug report,
not that I claim to understand the connection.

- Harald

Re: Zombie subprocesses

[Paul Eggert]

On 11/24/2012 02:10 AM, Harald Hanche-Olsen wrote:
> Done: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=12980

Thanks, I posted a proposed fix there.

Re: Zombie subprocesses

[James Cloos]

>>>>> "HH" == Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

HH> A bit of experimenting reveals that if I run

HH> (call-process "/bin/sleep" nil 0 nil "5")

HH> then this returns immediately, as expected, but after 5 seconds,
HH> the subprocess becomes a zombie and never goes away.

Thanks for finding an easy way to reproduce this bug.

I had asked about it, but have been too busy elsewhere to follow up.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6