From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mta-snd-w08.mail.nifty.com (mta-snd-w08.mail.nifty.com [106.153.227.40]) by sourceware.org (Postfix) with ESMTPS id 10CBD388461C for ; Fri, 28 Jun 2024 15:32:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 10CBD388461C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nifty.ne.jp ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 10CBD388461C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=106.153.227.40 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 Received: from HP-Z230 by mta-snd-w08.mail.nifty.com with ESMTP id <20240628153210090.EYWD.4660.HP-Z230@nifty.com> for ; Sat, 29 Jun 2024 00:32:10 +0900 Date: Sat, 29 Jun 2024 00:32:09 +0900 From: Takashi Yano To: cygwin@cygwin.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.85352f8a8d821c0f4d569d18@nifty.ne.jp> <20240423192606.7b4aa04685afca2525eb5ed3@nifty.ne.jp> <6dd8a568-88c0-42d5-aa46-b09247cdecec@johannesthoma.com> <5ed3b0b8-d4f8-454c-951a-fc7b85a7c302@johannesthoma.com> <95442cfe-a87c-4816-b337-b130e481e3f1@johannesthoma.com> <20240628211726.c131e0a300046d1fa46f6b53@nifty.ne.jp> 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.ne.jp; s=default-1th84yt82rvi; t=1719588730; bh=oAK6pbWOHNQsaCAOOMPb+0pPS+UdrID4+nP156aaR7M=; h=Date:From:To:Subject:In-Reply-To:References; b=sl7njWxD5wZ5im0PYNOti6mcs1PfAw5bG1LWgQNC9Hf6u2Kh2nMIkxALrHRZZIHFIiikQEav r8qsF4b9VSeRODsldNNNAXGY9sWP23XXUgjMtSxFkMVGi1GWIKUfBP6pq5vRMl8jzkIpeBBXT6 yxxeM5YEkB9Toho6G3xFoxFJAs3/NHZNHq59jqvgc03M0ax/m2eK2IMQoVWJDw2dn08ktpNlyG 9oFK56fmOE8jYnyWF8vz7yjFatN81mF4g51bmvI0uMk46xTE3gAhw/06Xrtzmja1nfvzleIBox EVpzotRnuzGxO0ng/r1XcsQ7R1iOZ3cqsOMlHruvVhffJ1kQ== 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 List-Id: 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