Race condition hangs on multiple mintty/tcsh? Brad Wetmore

Takashi Yano takashi.yano@nifty.ne.jp
Tue Aug 11 04:59:48 GMT 2020


Hi Thomas,

On Thu, 6 Aug 2020 15:31:24 +0200
Thomas Wolff wrote:
> Am 06.08.2020 um 13:46 schrieb Thomas Wolff:
> > Am 06.08.2020 um 01:23 schrieb Kevin Schnitzius via Cygwin:
> >> On Wednesday, August 5, 2020, 06:56:48 PM EDT, Thomas Wolff 
> >> <towo@towo.net> wrote:
> >>> Am 04.08.2020 um 12:02 schrieb Thomas Wolff:
> >>>> Am 04.08.2020 um 00:13 schrieb Brad Wetmore via Cygwin:
> >>>>> Hi,
> >>>>>
> >>>>> I generally kick off multiple (10) mintty sessions, and place them
> >>>>> around the screen.
> >>>>>
> >>>>> C:/cygwin64/bin/mintty.exe -i /Cygwin-Terminal.ico \
> >>>> --position @3 --position 120,0 --size 80x71 /bin/tcsh &
> >>>>> C:/cygwin64/bin/mintty.exe -i /Cygwin-Terminal.ico \
> >>>>> --position @3 --position 715,0 --size 80x45 /bin/tcsh &
> >>>>> C:/cygwin64/bin/mintty.exe -i /Cygwin-Terminal.ico \
> >>>>> --position @3 --position 715,660 --size 80x24 /bin/tcsh &
> >>>>>
> >>>>> Within the last 6 months or so, about 2-3 of them would hang and
> >>>>> either mintty/tcsh would not start. I put a "sleep 1" in between each
> >>>>> invocation and that seemed to take care of it.
> >>>>>
> >>>>> With the latest cygwin update, about 8 of them just hang even with
> >>>>> the sleep 1. I put in a "sleep 2", and now everything is coming up
> >>>>> again.
> >>>>>
> >>>>> Not sure if this is a mintty or tcsh issue, but just wondering if
> >>>>> others are seeing this before I start trying to debug this.
> >>>> I can reproduce such behaviour with /bin/bash (easy cross-check), and
> >>>> in fact the shell is running in that case (easy test via `echo >
> >>>> .log`), so I have a vague and unpleasant suspicion it might in fact be
> >>>> related to mintty although I have no idea how that would happen. To be
> >>>> analysed.
> >>> When in this state, on the pty from which mintty receives child process
> >>> output, select() does not report a ready for reading condition; 
> >>> could it
> >>> be related to the recent poll/select patch? I could not reproduce it in
> >>> cygwin 3.0.7.
> >> for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ; do 
> >> mintty  -i /Cygwin-Terminal.ico  --position @3 --position 120,$i 
> >> --size 80x24 /bin/bash & done
> >>
> >> This does not fail for me.  Nor does it fail from cmd or powershell 
> >> using a script.
> >>
> >> I tried 3.1.4 and 3.1.6 on Windows 10.  I tried up to 100 instances 
> >> of of mintty...
> > Thanks for testing. It is in fact hard to reproduce, maybe also 
> > depending on system load (speculating).
> > I could reproduce one case of one of three terminals being 
> > unresponsive also with xterm.
> And it also happens if I drop select() from mintty (and use just 
> non-blocking read()).
> > Does anybody familiar with pty/select or recent changes have any idea?

I looked into this problem. After much struggle, I think
I have found a workaround for this issue.

I am not sure why this solves the issue at all, however,
this works for me.

Could you please test a patch attached?

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Cygwin-pty-Add-a-workaround-for-issue-of-starting-a-.patch
Type: application/octet-stream
Size: 2139 bytes
Desc: not available
URL: <https://cygwin.com/pipermail/cygwin/attachments/20200811/8c3312db/attachment.obj>


More information about the Cygwin mailing list