This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Problem with zombie processes
On Fri, Feb 17, 2017 at 11:06 PM, Mark Geisert <mark@maxrnd.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
results.
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
process.
Thanks,
Erik
[1] https://msdn.microsoft.com/en-us/library/windows/desktop/ms682658(v=vs.85).aspx
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple