DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 45SFXEui3742646 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=fNpPwgsk X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 57D9B3826DFC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1719588792; bh=dVPGpCBl8Wv/WwSfFtnVlO0RdXMHNDZNUSb2mlS/TAk=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=fNpPwgsklXuoAjoJGtw29mG0mW7EcZ98T8+NIF7oZotjo5nLymiiBWq7qQiLCGoGM Ls374wuoMX5pZOohLkW1ukc+BclORh+ZC+uxRTaIS7LBPUBn8XYK1R1W5J8n+u0oiK VqLNUA9Yj+gvIJXiEhYeCv+VjZJvpJowNYTKFjhs= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 10CBD388461C ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 10CBD388461C ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719588736; cv=none; b=gxCXCkTUsgDakUbkGUpv4wZMUzB2zy/J+e6mQheDuCQHFcocECYxyu5nBIKSmPkfb+cQUJ4T3Pprz4fF3zRcs9t8+qfEfKGCLPyay0ipBEyvfYEZGFSFAVr+D3qMD0yTpC9ZnYhUHc4LzbpqkT+p1OoW8iz2Wz1lcyxex3QCKXo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1719588736; c=relaxed/simple; bh=9XdezcgNBPksFRHrKdXJSDt9DtfuhoxAYtEMffExJgk=; h=Date:From:To:Subject:Message-Id:Mime-Version:DKIM-Signature; b=ftRxicCT6V1KO8nQEmgbqcRp8rWFNJl0F8l8UiIEFt+GmhTT+b0dqjHWLBBt4OuzCFf5ix1vQACe7yqy5/onTp83mXUPWkR0QTkD/zW+gSiQVcNLkaXTkLgbS+/NSfpgbWIwMPKA8MlvmzDCl2ctAai02Flj/tG7vtHun73AiHo= ARC-Authentication-Results: i=1; server2.sourceware.org Date: Sat, 29 Jun 2024 00:32:09 +0900 To: cygwin AT cygwin DOT com Subject: Re: cygwin application hangs on closing console Message-Id: <20240629003209.d0bd3cc2961891fb69b55b35@nifty.ne.jp> In-Reply-To: <20240628211726.c131e0a300046d1fa46f6b53@nifty.ne.jp> References: <20240423035104 DOT 85352f8a8d821c0f4d569d18 AT nifty DOT ne DOT jp> <20240423192606 DOT 7b4aa04685afca2525eb5ed3 AT nifty DOT ne DOT jp> <6dd8a568-88c0-42d5-aa46-b09247cdecec AT johannesthoma DOT com> <5ed3b0b8-d4f8-454c-951a-fc7b85a7c302 AT johannesthoma DOT com> <95442cfe-a87c-4816-b337-b130e481e3f1 AT johannesthoma DOT com> <20240628211726 DOT c131e0a300046d1fa46f6b53 AT nifty DOT ne DOT jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 X-Spam-Status: No, score=-5.1 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_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Takashi Yano via Cygwin Reply-To: Takashi Yano Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" On Fri, 28 Jun 2024 21:17:26 +0900 Takashi Yano wrote: > Sorry for very late replay. > > On Mon, 3 Jun 2024 15:20:32 +0200 > Johannes Khoshnazar-Thoma wrote: > > We did more testing and it looks like the name of the event > > that signals console master thread start and end is shared between > > unrelated processes (it uses the console minor which is always (?) > > 0 when running from a powershell). > > > > So since it is a two-state event (as opposed to a semaphore) > > in theory the following can happen: > > > > Process A Process B > > SetEvent(e) > > SetEvent(e) > > Waitforevent(e) > > Waitforevent(e) > > This should not happen. Master thread is unique to console. > get_minor() number is always 0 for the first opened console. > If you open another powershell window and start cygwin process > while the first cygwin process is still active, the get_minor() > returns 1. > > Waiting for thread_sync_event is executed only > if (shared_console_info[unit] && con.owner == myself->pid) > con.owner is in the shared memory which is shared among all > processes started in the same console. Therefore, only the > one process start to wait the event. > > > The second SetEvent does nothing. As a result the > > later Waitforevent is stuck (which is what we observe). > > > > So the question is: why should this event be used in > > unrelated cygwin processes? Is there a technical reason > > we don't understand (yet) for doing that (sharing the event). > > > > We patched cygwin to use pseudo random event names (the > > tm_usec field of gettimeofday()) and the stuckness vanished. > > So unless there is a reason for sharing the event between > > cygwin processes this patch should work: > > Do you really confirm that your patch resolves the issue? > If so, the cause might be some kind of race issue. There was similar bug in cygwin 3.5.1, however, it has been already fixed in 3.5.3. https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=fc5e9525453fea7c27b0e13635ae54abaa0db69d I believe your problem is reproducible with 3.5.3. Right? -- Takashi Yano -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple