This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with zombie processes

On Fri, Feb 17, 2017 at 11:06 PM, Mark Geisert <> 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 [1] 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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]