This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem with zombie processes
On Fri, Feb 17, 2017 at 11:06 PM, Mark Geisert <email@example.com> wrote:
> Erik Bray wrote:
>> On Tue, Feb 14, 2017 at 8:25 PM, Mark Geisert <XXXX@XXXXXX.XXX> wrote:
> Please don't quote raw email addresses. We try to avoid feeding spammers.
Sorry--normally replies on this ML are just back to the ML itself (my
preference as well) so I wasn't expecting it.
>>> Erik Bray wrote:
>>>> The attached Python script
>> D'oh! Here is the script. It at least demonstrates the problem.
> Thanks! Running this script repeatedly on my system (Win7, 2 cores / 4 HT
> threads) showed no differences between your Test 1 and Test 2. Each Test
> concludes in one of three ways, seemingly randomly: (1) read of
> /proc/<pid>/stat succeeds and process status is displayed, (2) read fails
> with Python IOError, (3) read apparently succeeds but there's no process
> data displayed.
> An strace of your script shows Python itself is calling wait4() to reap the
> child process. So, as Doug suggested on another thread, the script's
> actions are just subject to the whims of process scheduling and vary from
> run to run.
You're right. The first time I was testing this, for whatever reason,
I was getting *very* consistent results. Test 1 *always* succeeded
and test 2 always fails. But trying it now, I am getting similar
What I was going by was the docs for ExitProcess  which states:
"Exiting a process does not necessarily remove the process object from
the operating system. A process object is deleted when the last handle
to the process is closed."
So my guess was that Cygwin might try to hold on to a handle to a
child process at least until it's been explicitly wait()ed. But that
does not seem to be the case after all.
Anyways, I think it would be nicer if /proc returned at least partial
information on zombie processes, rather than an error. I have a patch
to this effect for /proc/<pid>/stat, and will add a few more as well.
To me /proc/<pid>/stat was the most important because that's the
easiest way to check the process's state in the first place! Now I
also have to catch EINVAL as well and assume that means a zombie
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple