From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail231.csoft.net (mail231.csoft.net [96.47.74.235]) by sourceware.org (Postfix) with ESMTPS id D353A3852E3F for ; Mon, 11 Apr 2022 17:02:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D353A3852E3F Received: from mail231.csoft.net (localhost [127.0.0.1]) by mail231.csoft.net (Postfix) with ESMTP id 45CD5CC26; Mon, 11 Apr 2022 13:02:20 -0400 (EDT) Received: from mail231 (mail231 [96.47.74.235]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) (Authenticated sender: jeremyd) by mail231.csoft.net (Postfix) with ESMTPSA id 441A5CC1F; Mon, 11 Apr 2022 13:02:20 -0400 (EDT) Date: Mon, 11 Apr 2022 10:02:20 -0700 (PDT) From: Jeremy Drake X-X-Sender: jeremyd@resin.csoft.net To: Alexey Izbyshev cc: cygwin@cygwin.com Subject: Re: Re: Deadlock of the process tree when running make In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (BSO 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Mon, 11 Apr 2022 17:02:22 -0000 On Mon, 11 Apr 2022, Alexey Izbyshev wrote: > Yes, sshd is running as a service, but I'm not sure that patch is relevant. In > my case, the problematic pipe that the hanging conhost.exe is waiting on is > probably created for that specific conhost.exe process within the process tree > rooted at "make", which runs as an ordinary user. Also, wouldn't the hang be > deterministic if the problem were in the pipe ownership? Yes it would. I just noticed some of the evidence pointing that way - a presumably native javac.exe, an anonymous "named pipe" handle, and then when I saw sshd involved the last piece required for that scenario - running as a service. But Takashi's reply sounds like sshd drops the well-known service sid when it switches to the logged-on user's token anyway. This is both good and bad, I guess. Bad because your problem may not be solved yet (though maybe with the latest test dll, fingers crossed!). Good because there's a mystery hang that's been plaguing me when running (under emulation) on Windows on ARM64 that the circumstances of that environment has made virtually impossible to debug, and every commit that mentions fixing a deadlock gives me new hope that that will be the fix that makes it go away.