public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Takashi Yano <takashi.yano@nifty.ne.jp>
To: cygwin@cygwin.com
Subject: Re: Race condition hangs on multiple mintty/tcsh? Brad Wetmore
Date: Tue, 11 Aug 2020 13:59:48 +0900	[thread overview]
Message-ID: <20200811135948.959c10de83b8ccfa35f4281a@nifty.ne.jp> (raw)
In-Reply-To: <3d594543-c992-a22c-4631-f786cf34f76b@towo.net>

[-- Attachment #1: Type: text/plain, Size: 3034 bytes --]

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>

[-- Attachment #2: 0001-Cygwin-pty-Add-a-workaround-for-issue-of-starting-a-.patch --]
[-- Type: application/octet-stream, Size: 2139 bytes --]

From cc451648bbc7f395fa00cb2b97351d1513827f82 Mon Sep 17 00:00:00 2001
From: Takashi Yano <takashi.yano@nifty.ne.jp>
Date: Tue, 11 Aug 2020 13:16:52 +0900
Subject: [PATCH] Cygwin: pty: Add a workaround for issue of starting a lot of
 mintty.

- If a lot of mintty are started in a short time from a mintty, some
  of them hang with empty screen, crash immediately or hang on exiting
  mintty. The following report seems to be related to this issue.
    https://cygwin.com/pipermail/cygwin/2020-August/245751.html
  The cause is not clear at all, but this patch seems to solve the
  issue.
---
 winsup/cygwin/spawn.cc | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/spawn.cc b/winsup/cygwin/spawn.cc
index 840ec4a86..e70ceb86d 100644
--- a/winsup/cygwin/spawn.cc
+++ b/winsup/cygwin/spawn.cc
@@ -177,7 +177,7 @@ find_exec (const char *name, path_conv& buf, const char *search,
 /* Utility for child_info_spawn::worker.  */
 
 static HANDLE
-handle (int fd, bool writing)
+handle (int fd, bool writing, bool iscygwin)
 {
   HANDLE h;
   cygheap_fdget cfd (fd);
@@ -188,6 +188,11 @@ handle (int fd, bool writing)
     h = INVALID_HANDLE_VALUE;
   else if (!writing)
     h = cfd->get_handle ();
+  else if (cfd->get_major () == DEV_PTYS_MAJOR && iscygwin)
+    {
+      fhandler_pty_slave *ptys = (fhandler_pty_slave *)(fhandler_base *) cfd;
+      h = ptys->get_output_handle_cyg ();
+    }
   else
     h = cfd->get_output_handle ();
 
@@ -625,9 +630,11 @@ child_info_spawn::worker (const char *prog_arg, const char *const *argv,
 
       /* Set up needed handles for stdio */
       si.dwFlags = STARTF_USESTDHANDLES;
-      si.hStdInput = handle ((in__stdin < 0 ? 0 : in__stdin), false);
-      si.hStdOutput = handle ((in__stdout < 0 ? 1 : in__stdout), true);
-      si.hStdError = handle (2, true);
+      si.hStdInput = handle ((in__stdin < 0 ? 0 : in__stdin), false,
+			     iscygwin ());
+      si.hStdOutput = handle ((in__stdout < 0 ? 1 : in__stdout), true,
+			      iscygwin ());
+      si.hStdError = handle (2, true, iscygwin ());
 
       si.cb = sizeof (si);
 
-- 
2.27.0


  parent reply	other threads:[~2020-08-11  5:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 22:13 Brad Wetmore
2020-08-04 10:02 ` Thomas Wolff
2020-08-05 22:56   ` Thomas Wolff
2020-08-05 23:23     ` Kevin Schnitzius
2020-08-06 11:46       ` Thomas Wolff
2020-08-06 13:31         ` Thomas Wolff
2020-08-06 14:26           ` Corinna Vinschen
2020-08-06 14:33             ` Thomas Wolff
2020-08-07 15:34               ` Takashi Yano
2020-08-11  4:59           ` Takashi Yano [this message]
2020-08-11  9:37             ` Corinna Vinschen
2020-08-11 10:02               ` Takashi Yano
2020-08-11 10:30                 ` Corinna Vinschen
2020-08-11 17:37                   ` Thomas Wolff
2020-08-12 20:27                     ` Thomas Wolff
2020-08-06 18:07 ` Brad Wetmore
2020-08-06 18:48   ` Thomas Wolff
2020-08-06 19:25   ` Brad Wetmore
2020-08-13  3:08     ` Brad Wetmore
2020-08-25 18:45       ` Brad Wetmore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200811135948.959c10de83b8ccfa35f4281a@nifty.ne.jp \
    --to=takashi.yano@nifty.ne.jp \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).