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:from:date:message-id:subject:to
	:content-type; q=dns; s=default; b=V5FLkZABodcfOcJFSqkDFx49BAacj
	Xs1hs008Z/DjwPxEwgkUU+scS8mwEMjUWFKbUamVYpV/baoAmKAIXebPQb/QreC7
	LTNJLb5SguQEcmB5N2eqevI3aM+FzpAtLoRtuErKIqHkgwd5JMnEzYT7x3BhNQ3+
	ftOX86xvar1IVw=
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:from:date:message-id:subject:to
	:content-type; s=default; bh=eW0kulVV45hwl05EJPWb+fHs/jI=; b=MQV
	cjm7ZQu6w0RCHvM07wbsSCcCAqrJbJ1oxRrS07fxHZvEnsPdupIx6kQI2TOZW3F8
	bJR26d5utWaJAB67M71TJwxSIlijjpWC6buAfHYX7Cxvn85uhbqu1gYeYekf3Qt6
	qscd8daCrecgGRgQk7Ppr5Iv85anwW8PqQ1D9nSc=
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.2 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=sigkill, SIGKILL, Hx-languages-length:1788, reaped
X-HELO:	mail-vk0-f48.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:from:date:message-id:subject:to; bh=JH8Ef3eScmeVBq7d/pvS5Ph3cCl8vIp8jUB0MOk5ipU=; b=BIcBnyZnnRXA6SZUXKwl/agwb0qR+TDLxNcjQlnqYRMvwBNoK5Oanb94SMM53mR0Nt 61zp4FcLidkC1qSOycQHfQrPyf/WDFMBWflRQjodEsqALjcjAfcg3imWcIquLwKyzySZ jkygHgiL6ZgxnoHpDqBfndl7QGqnunML1yQDCVn0u5QMEFXs5Q3ik5oQuzK6U5yUhSoX lZXoDO4k+fDQxSm8WaSIqDtnGW4diaw25ZILySnivok522cM7GBSsWUcyCmNoW+0fkx1 PPsM04HVqZ+GHh2VMsCYuPYX+j+w4eecupLAFhXse7IYlRJ54OIBgi3SABzLwuYIkDOn Mk/Q==
X-Gm-Message-State:	AMke39nJxacjtRrkclxUOJrbPl01UBEms77xaT5TOLkAx7zwBovsQ/agEDS2Gim167p5R9UxuNaJfbJ85R2RJg==
X-Received:	by 10.31.83.66 with SMTP id h63mr14113329vkb.72.1487070890026; Tue, 14 Feb 2017 03:14:50 -0800 (PST)
MIME-Version:	1.0
From:	Erik Bray <erik DOT m DOT bray AT gmail DOT com>
Date:	Tue, 14 Feb 2017 12:14:49 +0100
Message-ID:	<CAOTD34bHSDJErA0B8Qt8Zqi54ciV5ZpRJdTa_pGs9Mp2PERsuw@mail.gmail.com>
Subject:	Problem with zombie processes
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

Hi all,

I encountered a strange bug concerning zombie child processes during
my testing.  Specifically, it came up in the context of trying to read
the /proc/<pid> entries of processes that should be zombified but not
reaped yet (i.e. they have received and processed a SIGKILL or SIGTERM
but have not been wait()ed on yet).

In some cases it's still possible to read, for example,
/proc/<pid>/stat of the zombie process, while in other cases it fails
with errno 22 (EINVAL).  In the latter case, this is coming from the
OpenProcess() call in format_process_stat() (or similarly in other
format_process_* methods) indicating that Windows has already removed
the process object from its process table.  Or equivalently, there are
no more open handles to the child process.

What I don't understand is if this is intentional or not.  I feel like
Cygwin should try to keep the Windows process object alive as long as
it's a zombie process.  But in some cases it does and in some cases it
doesn't.

The attached Python script shows two such cases, and I don't
understand quite where they differ.  In one case, stdout from the
child process is being sent to the parent over a pipe.  In the second
case stdout from the child is sent to /dev/null.  In the first case
the process object is kept alive and I can read its /proc entries.  In
the latter case it dies even before wait().  I'm not sure what the
difference is in terms of keeping the process object alive.

If Cygwin can't guarantee that the Windows process object is kept
around while the process is in zombie state, it would be nice, as an
alternative, to change the error handling in the format_process_*
methods to return as much info as it can, with other fields zero'd
out, rather than an error.

Best,
Erik

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