From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86062 invoked by alias); 20 Feb 2017 15:23:36 -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 86052 invoked by uid 89); 20 Feb 2017 15:23:35 -0000 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=scenes, waits, 9699919799, pubs.opengroup.org X-HELO: mail-ua0-f181.google.com Received: from mail-ua0-f181.google.com (HELO mail-ua0-f181.google.com) (209.85.217.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Feb 2017 15:23:33 +0000 Received: by mail-ua0-f181.google.com with SMTP id 92so12394763uad.2 for ; Mon, 20 Feb 2017 07:23:34 -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:in-reply-to:references:from:date :message-id:subject:to; bh=hBqkB30TxnaaAFfQjwB0nVCOLFmoRUU7m8MJqilLT/o=; b=g4ytkZ+jueS77uw6p3cyAGqd3ZSRLFTKvK3PDpEHjCydh4GIwj73MFOu8QLwUV2WX2 GRRxDlT3Ao3jboElFKq54pOBrgrrGmfP5WQqB98KANMKKI4Vxx+1F4aSuwGVU6/ePUZj gpU3HHfaQC5/whMMzCte/rIHAGQooYBmS7dfTKdVjXJrEgyZ7rn4XB1lShkrl9CQsiAO PODbZ4/1zMGcqCvj6SzQER4bf6uBgTWLNZjD7gFRVAtUvmb+v6PqSNqpKyOJxL9WBfhT qA1f7VbtNOfbEkYUdRajhQPKED9pLvRV/lh/PHxe9f3e6o/jlNb0xhAYmSRnOBvxbTbf OqGQ== X-Gm-Message-State: AMke39lGX5n5qnnbrvtlrX0GNYFqZiKi67pjcgg1Ro4rgZX/n6KgCX+jcdNEOTkpI/tbD0qzso5pcUD/enpRww== X-Received: by 10.176.0.82 with SMTP id 76mr7196033uai.20.1487604212169; Mon, 20 Feb 2017 07:23:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.115.65 with HTTP; Mon, 20 Feb 2017 07:23:31 -0800 (PST) In-Reply-To: <58AACADF.6080101@maxrnd.com> References: <58A3598F.2020405@maxrnd.com> <58A773C9.1080905@maxrnd.com> <58AACADF.6080101@maxrnd.com> From: Erik Bray Date: Mon, 20 Feb 2017 15:23:00 -0000 Message-ID: Subject: Re: Problem with zombie processes To: cygwin@cygwin.com Content-Type: multipart/mixed; boundary=001a113e45cea255060548f7d8d5 X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00242.txt.bz2 --001a113e45cea255060548f7d8d5 Content-Type: text/plain; charset=UTF-8 Content-length: 2746 On Mon, Feb 20, 2017 at 11:54 AM, Mark Geisert wrote: >> 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. > > > You might have missed a subtlety in what I said above. The Python > interpreter itself is calling wait4() to reap your child process. Cygwin > has told Python one of its children has died. You won't get the chance to > wait() for it yourself. Cygwin *does* have a handle to the process, but it > gets closed as part of Python calling wait4(). To be clear, wait4() is not called from Python until the script explicitly calls p.wait(). In other words, when run this step by step (e.g. in gdb) I don't see a wait4() call until the point where the script explicitly waits(). I don't see any reason Python would do this behind the scenes. >> 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//stat, and will add a few more as well. >> To me /proc//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. > > > The file /proc//stat is there until Cygwin finishes cleanup of the > child due to Python having wait()ed for it. When you run your test script, > pay attention to the process state character in those cases where you > successfully read the stat file. It's often S (stopped, I think) or R > (running) but I also see Z (zombie) sometimes. Your script is in a race > with Cygwin, and you cannot guarantee you'll see a killed process's state > before Cygwin cleans it up. > > One way around this *might* be to install a SIGCHLD handler in your Python > script. If that's possible, that should tell you when your child exits. Perhaps the Python script is a red herring. I just wrote it to demonstrate the problem. The difference between where I send stdout to is strange, but you're likely right that it just comes down to subtle timing differences. Here's a C program that demonstrates the same issue more reliably. Interestingly, it works when I run it in strace (probably just because of the strace overhead) but not when I run it normally. My point in all this is I'm confused why Cygwin would give up its handles to the Windows process before wait() has been called. (In fact, it's pretty confusing to have fopen returning EINVAL which according to [1] it should only be doing if the mode string were invalid.) Thanks, Erik [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/fopen.html --001a113e45cea255060548f7d8d5 Content-Type: text/x-csrc; charset=US-ASCII; name="test.c" Content-Disposition: attachment; filename="test.c" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ize931ro0 Content-length: 1708 I2luY2x1ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8c3RkbGliLmg+CiNpbmNs dWRlIDxzdGRpby5oPgojaW5jbHVkZSA8dGltZS5oPgojaW5jbHVkZSA8c3Ry aW5nLmg+CiNpbmNsdWRlIDxzaWduYWwuaD4KI2luY2x1ZGUgPGZjbnRsLmg+ CiNpbmNsdWRlIDxzeXMvd2FpdC5oPgojaW5jbHVkZSA8c3lzL2Vycm5vLmg+ CgoKaW50IGRvX3BhcmVudChwaWRfdCk7CnZvaWQgZG9fY2hpbGQoaW50KTsK CgppbnQgbWFpbih2b2lkKSB7CiAgICBpbnQgZGV2bnVsOwogICAgcGlkX3Qg cGlkOwoKICAgIGRldm51bCA9IG9wZW4oIi9kZXYvbnVsbCIsIE9fV1JPTkxZ KTsKICAgIHBpZCA9IGZvcmsoKTsKICAgIGlmIChwaWQpIHsKICAgICAgICAv KiBQYXJlbnQgKi8KICAgICAgICByZXR1cm4gZG9fcGFyZW50KHBpZCk7CiAg ICB9IGVsc2UgewogICAgICAgIC8qIENoaWxkICovCiAgICAgICAgZG9fY2hp bGQoZGV2bnVsKTsKICAgIH0KfQoKCmludCBkb19wYXJlbnQocGlkX3QgY2hp bGRfcGlkKSB7CiAgICBGSUxFICpmOwogICAgY2hhciBidWZbMTIwXTsKICAg IGNoYXIgZmlsZW5hbWVbMjBdOwoKICAgIHByaW50ZigiY2hpbGQgcGlkOiAl ZFxuIiwgY2hpbGRfcGlkKTsKICAgIHNsZWVwKDUpOwogICAgcHJpbnRmKCJz ZW5kaW5nIFNJR0tJTExcbiIpOwogICAga2lsbChjaGlsZF9waWQsIFNJR0tJ TEwpOwogICAgc3ByaW50ZihmaWxlbmFtZSwgIi9wcm9jLyVkL3N0YXQiLCBj aGlsZF9waWQpOwogICAgcHJpbnRmKCJyZWFkaW5nICVzXG4iLCBmaWxlbmFt ZSk7CiAgICBmID0gZm9wZW4oZmlsZW5hbWUsICJyIik7CiAgICBpZiAoZiA9 PSBOVUxMKSB7CiAgICAgICAgcHJpbnRmKCJmb3BlbiBlcnJvciBbJWRdOiAl c1xuIiwgZXJybm8sIHN0cmVycm9yKGVycm5vKSk7CiAgICAgICAgaWYgKCFh Y2Nlc3MoZmlsZW5hbWUsIFJfT0spKSB7CiAgICAgICAgICAgIHByaW50Zigi YnV0IHRoZSBmaWxlIGV4aXN0cyBhbmQgaXMgcmVhZGFibGVcbiIpOwogICAg ICAgIH0KICAgIH0gZWxzZSB7CiAgICAgICAgZnJlYWQoYnVmLCBzaXplb2Yo Y2hhciksIDEyMCwgZik7CiAgICAgICAgcHJpbnRmKGJ1Zik7CiAgICB9CiAg ICByZXR1cm4gd2FpdDQoY2hpbGRfcGlkLCBOVUxMLCAwLCBOVUxMKTsKfQoK CnZvaWQgZG9fY2hpbGQoaW50IG91dCkgewogICAgY2hhciAqYXJndlsxXTsK CiAgICBhcmd2WzBdID0gIi91c3IvYmluL3llcyI7CiAgICBkdXAyKG91dCwg MSk7CiAgICBleGVjdihhcmd2WzBdLCBhcmd2KTsKICAgIGV4aXQoMCk7Cn0K --001a113e45cea255060548f7d8d5 Content-Type: text/plain; charset=us-ascii Content-length: 219 -- 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 --001a113e45cea255060548f7d8d5--