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
