cygwin application hangs on closing console

[Johannes Khoshnazar-Thoma]

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