X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=qFkQSf1
	8WMj9r5ptCURgyKsB0sIDuh1wpRyiKQgnqGprON4iag2K4Pu+mEJYA0kQGUMALae
	fye/CzSf2x+iICHUVXDkZ1gu0kl7VIFOpPqAGSp1QEur3grBDdm0E3UZXhn59DbR
	8GixAuk7xMyQ3m/HRmn7SIeNSHpwn6/c2Yng=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=gSOyX+o3sTJVY
	sd4mVB1r+2LoJw=; b=oQUKFr0urkEtIeip0J8xDnRIYcSDrs/ganGztjTn05rQ/
	zIs7tXUICITvRkPACYloMg9uy3oKI8Ym2nYgEzl7NxVfIGHG3wL/F2aDBUxYpsDO
	vh66toLu7GeRGqRs0kOW7ZVe2KsCMslVTf5Yhriu8ALVZ0jin3dJmtlcO5Vr9k=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=place, place!, zombie, randomly
X-HELO:	mail-ua0-f179.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=DoNZMbK78mI7Y3u6uv3tMD9Y38av/7QV9ivHLBaqHoo=; b=VOEJUUdcqV6L4X8C05cmghUDzsFxoXiXWoURHb2kkih3vCohkRDTYFFtEQd8zTpZUz qr1dxNsEFaluAz/aNCVQwG60bDXPrqHwOIVUwKPxGGV42aAjhI8OJKCf8aHuoJnszsRy 1NsAMv+r9utztGLrjXHEh9Y/gmtZCo4SadvDoSqXQs8pZj7EaBmsKyPdpVFqPT9n4D6L JTdnsHXAJp9NziSPLD+U/Mg0GjmiVT+nHLqFTJQajaTfhkjBk9NTohuhZlyO5nJtZGtp UwM/Phz3ww0QJo4nNDSfcFAZWeK5BKwRDah9Qbx98ngYEzLTl5ojVx3bzd/zl1B1P0bU OEhw==
X-Gm-Message-State:	AMke39n8bsorJfQksOfDYUasy7osj8Lq0f5JP1H9jGTJCQIh6klHzbL6f46BpJ4AhORXOOPW9V/hDKCclloL6Q==
X-Received:	by 10.176.66.66 with SMTP id i60mr10671716uai.131.1487583979498; Mon, 20 Feb 2017 01:46:19 -0800 (PST)
MIME-Version:	1.0
In-Reply-To:	<58A773C9.1080905@maxrnd.com>
References:	<CAOTD34bHSDJErA0B8Qt8Zqi54ciV5ZpRJdTa_pGs9Mp2PERsuw AT mail DOT gmail DOT com> <58A3598F DOT 2020405 AT maxrnd DOT com> <CAOTD34Z7VM=6=Ss_gCLS97c4sFNpnaT-+RgJq+xme-VyWYbbpw AT mail DOT gmail DOT com> <58A773C9 DOT 1080905 AT maxrnd DOT com>
From:	Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date:	Mon, 20 Feb 2017 10:46:19 +0100
Message-ID:	<CAOTD34ZHspOy0kSrxNbZCEDj++gRFUQOh2rmE08N9TZt3wXVrw@mail.gmail.com>
Subject:	Re: Problem with zombie processes
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

On Fri, Feb 17, 2017 at 11:06 PM, Mark Geisert <mark AT maxrnd DOT com> wrote:
> Erik Bray wrote:
>>
>> On Tue, Feb 14, 2017 at 8:25 PM, Mark Geisert <XXXX AT XXXXXX DOT 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

- Raw text -