From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104983 invoked by alias); 14 Feb 2017 11:14:53 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 104413 invoked by uid 89); 14 Feb 2017 11:14:53 -0000 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 Received: from mail-vk0-f48.google.com (HELO mail-vk0-f48.google.com) (209.85.213.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Feb 2017 11:14:51 +0000 Received: by mail-vk0-f48.google.com with SMTP id k127so77857324vke.0 for ; Tue, 14 Feb 2017 03:14:51 -0800 (PST) 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 Received: by 10.103.133.147 with HTTP; Tue, 14 Feb 2017 03:14:49 -0800 (PST) From: Erik Bray Date: Tue, 14 Feb 2017 11:14:00 -0000 Message-ID: Subject: Problem with zombie processes To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00187.txt.bz2 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/ 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//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