unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Zombie subprocesses
@ 2012-11-23 21:49 Harald Hanche-Olsen
  2012-11-23 22:23 ` Paul Eggert
  2012-11-24  5:51 ` James Cloos
  0 siblings, 2 replies; 11+ messages in thread
From: Harald Hanche-Olsen @ 2012-11-23 21:49 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-23 21:49 Zombie subprocesses Harald Hanche-Olsen
@ 2012-11-23 22:23 ` Paul Eggert
  2012-11-23 22:33   ` Ken Brown
                     ` (2 more replies)
  2012-11-24  5:51 ` James Cloos
  1 sibling, 3 replies; 11+ messages in thread
From: Paul Eggert @ 2012-11-23 22:23 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-23 22:23 ` Paul Eggert
@ 2012-11-23 22:33   ` Ken Brown
  2012-11-24  6:19     ` Eli Zaretskii
  2012-11-24  8:24   ` Chong Yidong
  2012-11-24  8:26   ` Paul Eggert
  2 siblings, 1 reply; 11+ messages in thread
From: Ken Brown @ 2012-11-23 22:33 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Harald Hanche-Olsen, emacs-devel

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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-23 21:49 Zombie subprocesses Harald Hanche-Olsen
  2012-11-23 22:23 ` Paul Eggert
@ 2012-11-24  5:51 ` James Cloos
  1 sibling, 0 replies; 11+ messages in thread
From: James Cloos @ 2012-11-24  5:51 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-devel

>>>>> "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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-23 22:33   ` Ken Brown
@ 2012-11-24  6:19     ` Eli Zaretskii
  0 siblings, 0 replies; 11+ messages in thread
From: Eli Zaretskii @ 2012-11-24  6:19 UTC (permalink / raw)
  To: Ken Brown; +Cc: eggert, hanche, emacs-devel

> 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.




^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-23 22:23 ` Paul Eggert
  2012-11-23 22:33   ` Ken Brown
@ 2012-11-24  8:24   ` Chong Yidong
  2012-11-24  8:26   ` Paul Eggert
  2 siblings, 0 replies; 11+ messages in thread
From: Chong Yidong @ 2012-11-24  8:24 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Harald Hanche-Olsen, emacs-devel

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-23 22:23 ` Paul Eggert
  2012-11-23 22:33   ` Ken Brown
  2012-11-24  8:24   ` Chong Yidong
@ 2012-11-24  8:26   ` Paul Eggert
  2012-11-24  8:46     ` Eli Zaretskii
  2012-11-24 10:10     ` Harald Hanche-Olsen
  2 siblings, 2 replies; 11+ messages in thread
From: Paul Eggert @ 2012-11-24  8:26 UTC (permalink / raw)
  To: Ken Brown; +Cc: Harald Hanche-Olsen, emacs-devel

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-24  8:26   ` Paul Eggert
@ 2012-11-24  8:46     ` Eli Zaretskii
  2012-11-24  9:45       ` Paul Eggert
  2012-11-24 10:10     ` Harald Hanche-Olsen
  1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2012-11-24  8:46 UTC (permalink / raw)
  To: Paul Eggert; +Cc: hanche, kbrown, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-24  8:46     ` Eli Zaretskii
@ 2012-11-24  9:45       ` Paul Eggert
  0 siblings, 0 replies; 11+ messages in thread
From: Paul Eggert @ 2012-11-24  9:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: hanche, kbrown, emacs-devel

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-24  8:26   ` Paul Eggert
  2012-11-24  8:46     ` Eli Zaretskii
@ 2012-11-24 10:10     ` Harald Hanche-Olsen
  2012-11-27  2:36       ` Paul Eggert
  1 sibling, 1 reply; 11+ messages in thread
From: Harald Hanche-Olsen @ 2012-11-24 10:10 UTC (permalink / raw)
  To: emacs-devel

[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



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: Zombie subprocesses
  2012-11-24 10:10     ` Harald Hanche-Olsen
@ 2012-11-27  2:36       ` Paul Eggert
  0 siblings, 0 replies; 11+ messages in thread
From: Paul Eggert @ 2012-11-27  2:36 UTC (permalink / raw)
  To: Harald Hanche-Olsen; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2012-11-27  2:36 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-11-23 21:49 Zombie subprocesses Harald Hanche-Olsen
2012-11-23 22:23 ` Paul Eggert
2012-11-23 22:33   ` Ken Brown
2012-11-24  6:19     ` Eli Zaretskii
2012-11-24  8:24   ` Chong Yidong
2012-11-24  8:26   ` Paul Eggert
2012-11-24  8:46     ` Eli Zaretskii
2012-11-24  9:45       ` Paul Eggert
2012-11-24 10:10     ` Harald Hanche-Olsen
2012-11-27  2:36       ` Paul Eggert
2012-11-24  5:51 ` James Cloos

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).