From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from conssluserg-06.nifty.com (conssluserg-06.nifty.com [210.131.2.91]) by sourceware.org (Postfix) with ESMTPS id 0C26C3858405 for ; Wed, 27 Apr 2022 11:23:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0C26C3858405 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from Express5800-S70 (ak044095.dynamic.ppp.asahi-net.or.jp [119.150.44.95]) (authenticated) by conssluserg-06.nifty.com with ESMTP id 23RBMEKJ007824; Wed, 27 Apr 2022 20:22:15 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com 23RBMEKJ007824 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=dec2015msa; t=1651058535; bh=ri3A0zL0T9wgcVoVm0POkY/D3gzntYTVtSRzKaHOB0I=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=yIn8ykbAUV15CopeI32WS1+oYsM+dtgxGYF6ncfkuIrC46l6lyNA0WlcXdbi7TZnv xHAHKodvSLVZkUt281QYo/wd3gvkATTo2Tc8i+WYyK+IuVXi4kAhYFidnNwnTWRiY2 PHGSct+3ckpE9E+3yR8YF0ULTOS8M6UJLqVvZV0wNWmhL4a4DdDKwp4GMrpvXU6gbb iku688mAessIdPSLGG+9RM028jvAS6H2GXg01kYjJ6d0ULP685mG4+SotC7IvhQ/Lf 0Vj2nIZEiSEoexWdUiSgTvo+Kdm37ZPlBQLLo0Pf6necjhZn46rGvT/ZHlFrQcP4uI r4onhnS8LYP4A== X-Nifty-SrcIP: [119.150.44.95] Date: Wed, 27 Apr 2022 20:22:16 +0900 From: Takashi Yano To: cygwin@cygwin.com Cc: Alexey Izbyshev Subject: Re: Deadlock of the process tree when running make Message-Id: <20220427202216.4901f538e9916e4a8bde10d9@nifty.ne.jp> In-Reply-To: <45f9160a597b25bc576eb153a138fb88@ispras.ru> References: <9388316255ada0e0fcb2d849cce5a894@ispras.ru> <1ecd670b1cdff43e0b0d7e5ee4c9cfc5@ispras.ru> <20220409204619.dd0e53902d5e108ef462e510@nifty.ne.jp> <907ce1b4416a826cb07990dd601bd687@ispras.ru> <20220410015753.753e2a238513eaf2a3da81e9@nifty.ne.jp> <20220410025410.196aa0a04368147dbbb31d3e@nifty.ne.jp> <7204ed0aa2d6b3fcfb239010e6b67646@ispras.ru> <20220410163432.00dd7b9f81f8f322d97688f2@nifty.ne.jp> <0e1a53626639cb21369225ff9092ecfc@ispras.ru> <20220411173526.6243b9492e0fc3d4132a58a8@nifty.ne.jp> <1bdd5ac77277343fbff9b560fa98b15e@ispras.ru> <20220416183910.b532b2cc95725b508bfd0991@nifty.ne.jp> <45f9160a597b25bc576eb153a138fb88@ispras.ru> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2022 11:23:09 -0000 Hi Alexey, On Sat, 16 Apr 2022 16:21:34 +0300 Alexey Izbyshev wrote: > On 2022-04-16 12:39, Takashi Yano wrote: > > I am not sure yet what is essential, but the current code closes > > pseudo console only if there is no other process which is attaching > > to the pseudo console. I wonder why javac.exe is remaining as > > zombie. The parent bash.exe calls ColosePseudoConsole() when > > child non-cygwin app is terminated, i.e., after WaitForSingleObject() > > for child process handle returns. > > https://www.cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/spawn.cc;h=81dba5a941e919ea2514013069aef22c6fad8004;hb=7ac0767053e278f0ce9811bf6f77278bd2f49c20#l1009 > > > > What does the "zombie" mean? Is it listed in the process list of > > ProcessHacker? I still suspect that the zombie javac.exe holds > > the hWritePipe handle leaked from parent bash.exe. > > > By "zombie" I meant the same thing as in the Linux kernel: a data > structure that remains after a process terminated, but hasn't been > waited for yet (I don't know how this is implemented in Cygwin). So > there is no javac.exe process in ProcessHacker, but "ps" and similar > tools in Cygwin still list "javac". > > I'm now trying to create a small reproducer that I can share, and I've > had a first small success this night: I could get a very similar hang > with a simple Makefile and a script with Cygwin 3.3.4. Here is the tree: > > make(14479)-+-bash(14484)---bash(14611) > |-bash(14515)---bash(14618) > |-bash(14491)---bash(14500)---bash(14612) > |-bash(14501)---bash(14510)---bash(14605) > |-bash(14505)---bash(14607) > |-bash(14494)---bash(14617) > |-bash(14506)---bash(14513)---bash(14610) > |-bash(14512)---bash(14518)---bash(14615) > |-bash(14486)---bash(14495)---bash(14606) > |-bash(14483)---bash(14490)---bash(14609) > |-bash(14509)---bash(14614) > |-bash(14489)---bash(14608) > |-bash(14499)---bash(14613) > |-bash(14481)---bash(14485)---python(14588) > |-bash(14496)---bash(14504)---bash(14616) > `-bash(14482)---bash(14604) > > > "python" is a zombie, just as "javac" is in the original case. There is > also a single "conhost.exe" again, and all of its 5 threads are doing > the same things as in the original case (including the signal pipe > thread trying to EnterCriticalSection()). The only difference is that > leaf bash.exe are trying to acquire pcon mutex at a different point [1], > but I guess this difference is not important. > > I'll try this reproducer with your patched DLL as well as on another > machine and share it in case of success. > > Thanks, > Alexey > > [1] > https://www.cygwin.com/git?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/spawn.cc;h=81dba5a941e919ea2514013069aef22c6fad8004;hb=cygwin-3_3_4-release#l697 Is there any progress on this? -- Takashi Yano