This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: pipe handling errors
- From: "Nellis, Kenneth" <Kenneth dot Nellis at xerox dot com>
- To: "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Tue, 15 Jul 2014 18:52:56 +0000
- Subject: RE: pipe handling errors
- Authentication-results: sourceware.org; auth=none
- References: <20140715154534 dot GQ10401 at calimero dot vinschen dot de>
From: Corinna Vinschen
> Hi Kenneth,
>
> On Jul 15 13:50, Nellis, Kenneth wrote:
> > From: Corinna Vinschen
> > > On Jul 14 17:40, Nellis, Kenneth wrote:
> > > > When running a bash pipeline using the latest 64-bit packages, I
> > > > occasionally get output like the following:
> > > >
> > > > 1479561950 [waitproc] -bash 10000 sig_send: error sending signal
> > > > 20, pipe handle 0x2710, nb 132, packsize 0, Win32 error 109
> > > >
> > > <snip>
> > >
> > > I know that we got this message more often in the past, but I'm
> > > totally unable to reproduce it these days. I tried with 1.7.30 as
> > > well as the latest snapshots.
> > >
> > > I'm wondering if a pipe could be intercepted by a virus checker or
> > > something like that. Whatever it is, would you mind to give the
> > > latest developer snapshot DLL (2014-07-15) from
> > > http://cygwin.com/snapshots/ a try? Chris has fixed a typo in the
> > > above debug message. If it still happens for you, maybe the new output helps better to find the cause.
> >
> > FYI, got it again this morning, this time with the suggested snapshot:
> >
> > 0 [main] -bash 8812 sig_send: error sending signal -66, pid
> > 8812, pipe handle 0x80, nb 0, packsize 176, Win32 error 0
> >
> > Cygwin64> uname -srvmo
> > CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 09:22:44 x86_64 Cygwin
> > Cygwin64>
>
> Thanks. I just created another snapshot which is supposed to fix this issue (curtesy cgf). Can you give it a try, please?
Well, I'm getting different results with the latest snapshot. Instead of
getting the error message, I'm getting a hang for maybe a minute before it
continues.
I used the following command to encourage a failure:
clear; for f in $(find */Debug -name '*Subsystem'); do echo === $f ===; strings $f | grep '\.cpp$' | sort | uniq -c | sort -n; done
9 invocations of this resulted in 3 hangs. During the last such hang,
ps output showed the following (from a 2nd mintty window):
Cygwin64> ps
PID PPID PGID WINPID TTY UID STIME COMMAND
6268 11100 8800 10808 pty0 12779 14:41:03 /usr/bin/sort <defunct>
1812 2968 1812 10924 pty1 12779 14:41:49 /usr/bin/ps
2968 10840 2968 10340 pty1 12779 14:41:41 /usr/bin/bash
5208 11100 8800 5212 pty0 12779 14:41:03 /usr/bin/grep <defunct>
11196 1 11196 11196 ? 12779 14:37:15 /usr/bin/mintty
7752 11100 8800 10324 pty0 12779 14:41:03 /usr/bin/sort <defunct>
10840 1 10840 10840 ? 12779 14:41:41 /usr/bin/mintty
11100 11196 11100 6260 pty0 12779 14:37:15 /usr/bin/bash
9536 11100 8800 10368 pty0 12779 14:41:03 /usr/bin/uniq <defunct>
Cygwin64>
After it completed, it showed the following
Cygwin64> ps
PID PPID PGID WINPID TTY UID STIME COMMAND
2968 10840 2968 10340 pty1 12779 14:41:41 /usr/bin/bash
10316 2968 10316 3152 pty1 12779 14:42:08 /usr/bin/ps
11196 1 11196 11196 ? 12779 14:37:15 /usr/bin/mintty
10840 1 10840 10840 ? 12779 14:41:41 /usr/bin/mintty
I 11100 11196 11100 6260 pty0 12779 14:37:15 /usr/bin/bash
Cygwin64>
Just to confirm I was using the later snapshot:
Cygwin64> uname -srvmo
CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 15:34:37 x86_64 Cygwin
Cygwin64>
--Ken Nellis