DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1643D381577F
Message-ID: <fb960e5d-ccdd-474b-a046-5178563d4200@johannesthoma.com>
Date: Mon, 1 Jul 2024 13:47:56 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: cygwin application hangs on closing console
To: cygwin@cygwin.com
References: <d268ca90-3c5b-4de6-9dd5-320ee713283c@johannesthoma.com>
 <20240423035104.85352f8a8d821c0f4d569d18@nifty.ne.jp>
 <b71816f0-633c-4eaf-b9d6-955b10e4866a@johannesthoma.com>
 <20240423192606.7b4aa04685afca2525eb5ed3@nifty.ne.jp>
 <6dd8a568-88c0-42d5-aa46-b09247cdecec@johannesthoma.com>
 <b67fc4f5-3fbb-454a-a0ce-da4f987924dc@johannesthoma.com>
 <d00f900a-e70c-4a2b-9570-0d3c9fcd45d2@SystematicSW.ab.ca>
 <5ed3b0b8-d4f8-454c-951a-fc7b85a7c302@johannesthoma.com>
 <95442cfe-a87c-4816-b337-b130e481e3f1@johannesthoma.com>
 <20240628211726.c131e0a300046d1fa46f6b53@nifty.ne.jp>
 <20240629003209.d0bd3cc2961891fb69b55b35@nifty.ne.jp>
In-Reply-To: <20240629003209.d0bd3cc2961891fb69b55b35@nifty.ne.jp>
UI-OutboundReport: notjunk:1;M01:P0:poyqPsXByX8=;k1HDRsUp1ZsqfFhdsu/qhea4gGM
 fxmCPaZr8teBAf/YteWds2wHDrsIyQkvHt76C42ePa05RStsHd28c47pWpgy7drV/yodvlXG8
 /GRwvrHMu3fPi9tIEHPbHF65E3g8JskePaNTwQpENwrlrUf4NLNsJSu1lfewMGaq/WAmJecnr
 GzTw+mejsFDj/wpJCes1RWEpKImv0hNuIiYzwtLWu7m3+CrciOGpOxBj+PN4fzENsquAso3YL
 g/46AtUaBIxtftrSWKke9YMri+8Y0MeB8Y2+QV9Mvkl+q43KSltLRRmpBckQ26Z+VHAENIOop
 mSyC0sO3aS63GyGIc0jcSFuAxtmbXueH1MFJouWfsU2aDfkWzOBBBwOD6VyKGjdtHJoAurrV0
 dd1YDAPS1nNzKD3CmV0ksrxJ3s37NIvZm405qk0oqIbDqJBzekIVk+sl2uRMlm0MfIepLpJYe
 PMRJAyFk8yvnXEtaAKwK5MNeV7fhFiGpUCEMCWuMxN/2uHYcZK8hPgSWNv2PfeX5JAoCTIYod
 RhjII+rKAPE/Mt8c2LLS2VdhME8iyhyLte5e/yeY9p9LRLjg7JcJwg6qnesUUqJIpmj936knU
 VodQsIfrS3Qg3KzLRHk4+7OgaKpimlaUl7Gr8y3cTXScdPkQqKY8e2GHAarSfU6U/ZCC1bOCM
 kPWYtdkoalkwScwvJFdei1xh2v4uqB3urb3wxzlA5gXiAf/7Nmh6+eRXMMlZiWs5agKa8oHaj
 fFKQq0qxNFy7CebRppLBuiilWSIeCXb0yPqiKZ6dxc1dOscn8j7ew8=
From: Johannes Khoshnazar-Thoma via Cygwin <cygwin@cygwin.com>
Reply-To: Johannes Khoshnazar-Thoma <johannes@johannesthoma.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

Hi Takashi Yano,

Thank you for your reply, comments inline.

Am 28.06.24 um 17:32 schrieb Takashi Yano via Cygwin:
> On Fri, 28 Jun 2024 21:17:26 +0900
> Takashi Yano wrote:
>> Sorry for very late replay.
No problem we are all sometimes very busy :)

>>
>> 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.
>
This patch solved the issue for our case. It was running for
3 days (instead of about 30 minutes) and the hang in console
close did not trigger.

Note that the hang does not happen when just running cygwin
applications via terminal windows (like cmd, powershell and
MinTTY). It triggers however when a cygwin application is
run both as a service (I think as SYSTEM account, but I
can ask again) and from a terminal window.

> 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?
>
Yes it is. We did long running tests and it is reproducible
with 3.5.3. I also did tests that force the minor being the
same for two cygwin processes (by patching the source code)
and the hang also triggers (after a few minutes).

So can it be that separate cygwin processes can have the
same minor? For example when on is started as a service
and the other is started interactively?

Could you maybe point to the place in the cygwin (winsup)
source code where the minor is allocated?

Thanks again for your hard work on cygwin.

Best regards,

- Johannes

-- 
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