* Re: pipe handling errors
@ 2014-07-16 17:36 Ti Strga
2014-07-17 8:25 ` Corinna Vinschen
0 siblings, 1 reply; 15+ messages in thread
From: Ti Strga @ 2014-07-16 17:36 UTC (permalink / raw)
To: cygwin
Christopher Faylor wrote:
> Increasing the size of the buffer should have been enough to fix the
> problem but, when possible, I like to use two forms of protection when I
> fix a bug.
I recall someone on a project here doing a bugfix with a commit log like:
yyyy-mm-dd The Guy's Name <blah@blah>
Fix #nnnnn
foo.cc (func1): Belt.
bar.cc (func2): Suspenders.
Anyhow, I'm looking forward to trying out the fix myself. We've been
getting those errors here but not nearly as often.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 15+ messages in thread
* pipe handling errors
@ 2014-07-14 17:40 Nellis, Kenneth
2014-07-15 9:49 ` Corinna Vinschen
0 siblings, 1 reply; 15+ messages in thread
From: Nellis, Kenneth @ 2014-07-14 17:40 UTC (permalink / raw)
To: cygwin
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
That one was the result of: strings <binary file> | grep <pattern> | sort | uniq -c
Here's a different one that I got twice when sending "strings"
output to "grep" and once sending "strings" output to "wc -l":
605884587 [main] -bash 10000 sig_send: error sending signal -66, pipe handle 0x2710, nb 132, packsize 0, Win32 error 0
I haven't found them to be repeatable.
I just tried on 32-bit Cygwin and got the following twice in a row,
but not a third time, so I suspect a race condition.
1 [main] -bash 9528 sig_send: error sending signal -34, pipe handle 0x2538, nb 152, packsize 0, Win32 error 0
25098461 [main] -bash 9528 sig_send: error sending signal -34, pipe handle 0x2538, nb 152, packsize 0, Win32 error 0
The initial "1" on the first one looks interesting.
This one also was: strings <binary file> | grep <pattern>
The common element in all these examples was generating the pipeline data
with "strings". I don't recall whether strings was always involved or not.
Not a big concern because the generated output looks correct,
but a tad annoying. Thought it worth reporting.
FWIW, on 64-bit:
Cygwin64> uname -a
CYGWIN_NT-6.1 COR900GFY5 1.7.30(0.272/5/3) 2014-05-23 10:36 x86_64 Cygwin
Cygwin64> cygcheck -f `which strings`
binutils-2.24.51-4
Cygwin64>
On 32-bit:
Cygwin32> uname -a
CYGWIN_NT-6.1-WOW64 COR900GFY5 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin
Cygwin32> cygcheck -f `which strings`
binutils-2.24.51-4
Cygwin32>
--Ken Nellis
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: pipe handling errors
2014-07-14 17:40 Nellis, Kenneth
@ 2014-07-15 9:49 ` Corinna Vinschen
2014-07-15 13:51 ` Nellis, Kenneth
0 siblings, 1 reply; 15+ messages in thread
From: Corinna Vinschen @ 2014-07-15 9:49 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 2557 bytes --]
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
>
> That one was the result of: strings <binary file> | grep <pattern> | sort | uniq -c
>
> Here's a different one that I got twice when sending "strings"
> output to "grep" and once sending "strings" output to "wc -l":
>
> 605884587 [main] -bash 10000 sig_send: error sending signal -66, pipe handle 0x2710, nb 132, packsize 0, Win32 error 0
>
> I haven't found them to be repeatable.
>
> I just tried on 32-bit Cygwin and got the following twice in a row,
> but not a third time, so I suspect a race condition.
>
> 1 [main] -bash 9528 sig_send: error sending signal -34, pipe handle 0x2538, nb 152, packsize 0, Win32 error 0
> 25098461 [main] -bash 9528 sig_send: error sending signal -34, pipe handle 0x2538, nb 152, packsize 0, Win32 error 0
>
> The initial "1" on the first one looks interesting.
> This one also was: strings <binary file> | grep <pattern>
>
> The common element in all these examples was generating the pipeline data
> with "strings". I don't recall whether strings was always involved or not.
>
> Not a big concern because the generated output looks correct,
> but a tad annoying. Thought it worth reporting.
>
> FWIW, on 64-bit:
> Cygwin64> uname -a
> CYGWIN_NT-6.1 COR900GFY5 1.7.30(0.272/5/3) 2014-05-23 10:36 x86_64 Cygwin
> Cygwin64> cygcheck -f `which strings`
> binutils-2.24.51-4
> Cygwin64>
>
> On 32-bit:
> Cygwin32> uname -a
> CYGWIN_NT-6.1-WOW64 COR900GFY5 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin
> Cygwin32> cygcheck -f `which strings`
> binutils-2.24.51-4
> Cygwin32>
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.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: pipe handling errors
2014-07-15 9:49 ` Corinna Vinschen
@ 2014-07-15 13:51 ` Nellis, Kenneth
2014-07-15 15:45 ` Corinna Vinschen
0 siblings, 1 reply; 15+ messages in thread
From: Nellis, Kenneth @ 2014-07-15 13:51 UTC (permalink / raw)
To: cygwin
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>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: pipe handling errors
2014-07-15 13:51 ` Nellis, Kenneth
@ 2014-07-15 15:45 ` Corinna Vinschen
2014-07-15 18:53 ` Nellis, Kenneth
0 siblings, 1 reply; 15+ messages in thread
From: Corinna Vinschen @ 2014-07-15 15:45 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1608 bytes --]
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?
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: pipe handling errors
2014-07-15 15:45 ` Corinna Vinschen
@ 2014-07-15 18:53 ` Nellis, Kenneth
2014-07-15 19:17 ` Nellis, Kenneth
0 siblings, 1 reply; 15+ messages in thread
From: Nellis, Kenneth @ 2014-07-15 18:53 UTC (permalink / raw)
To: cygwin
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: pipe handling errors
2014-07-15 18:53 ` Nellis, Kenneth
@ 2014-07-15 19:17 ` Nellis, Kenneth
2014-07-15 19:36 ` Nellis, Kenneth
2014-07-15 19:52 ` Christopher Faylor
0 siblings, 2 replies; 15+ messages in thread
From: Nellis, Kenneth @ 2014-07-15 19:17 UTC (permalink / raw)
To: cygwin
From: Nellis, Kenneth
<snip>
> 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
<snip>
Thought it might be useful to add that I can fairly easily get the same
minute-long hang with a simpler command:
Cygwin64> strings *Subsystem | wc -l
--Ken Nellis
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: pipe handling errors
2014-07-15 19:17 ` Nellis, Kenneth
@ 2014-07-15 19:36 ` Nellis, Kenneth
2014-07-15 19:52 ` Christopher Faylor
1 sibling, 0 replies; 15+ messages in thread
From: Nellis, Kenneth @ 2014-07-15 19:36 UTC (permalink / raw)
To: cygwin
At the risk of annoying folks uninterested in this problem,
here is a simpler test case:
Cygwin64> date; seq 10000 | wc -l; date
Tue Jul 15 15:30:03 EDT 2014
10000
Tue Jul 15 15:31:03 EDT 2014
Cygwin64>
The output ("10000") occurs immediately and then the hang
for precisely one minute before the 2nd date.
As before:
Cygwin64> uname -srvmo
CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 15:34:37 x86_64 Cygwin
Cygwin64>
--Ken Nellis
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: pipe handling errors
2014-07-15 19:17 ` Nellis, Kenneth
2014-07-15 19:36 ` Nellis, Kenneth
@ 2014-07-15 19:52 ` Christopher Faylor
2014-07-15 20:40 ` Nellis, Kenneth
1 sibling, 1 reply; 15+ messages in thread
From: Christopher Faylor @ 2014-07-15 19:52 UTC (permalink / raw)
To: cygwin
On Tue, Jul 15, 2014 at 07:17:48PM +0000, Nellis, Kenneth wrote:
>From: Nellis, Kenneth
><snip>
>> 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
><snip>
>
>Thought it might be useful to add that I can fairly easily get the same
>minute-long hang with a simpler command:
>
>Cygwin64> strings *Subsystem | wc -l
What's your cwd when you run this command?
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: pipe handling errors
2014-07-15 19:52 ` Christopher Faylor
@ 2014-07-15 20:40 ` Nellis, Kenneth
2014-07-15 22:05 ` Christopher Faylor
0 siblings, 1 reply; 15+ messages in thread
From: Nellis, Kenneth @ 2014-07-15 20:40 UTC (permalink / raw)
To: cygwin
From: Christopher Faylor
>On Tue, Jul 15, 2014 at 07:17:48PM +0000, Nellis, Kenneth wrote:
>>From: Nellis, Kenneth
>><snip>
>>> 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
>><snip>
>>
>>Thought it might be useful to add that I can fairly easily get the same
>>minute-long hang with a simpler command:
>>
>>Cygwin64> strings *Subsystem | wc -l
>
>What's your cwd when you run this command?
Well, it *was* on a network drive, but that appears to be irrelevant:
Cygwin64> date; seq 10000 | wc -l; date
Tue Jul 15 16:31:52 EDT 2014
10000
Tue Jul 15 16:32:52 EDT 2014
Cygwin64> pwd
/home/knellis
Cygwin64> cygpath -w $PWD
C:\cygwin\home\knellis
Cygwin64> uname -srvmo
CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 15:34:37 x86_64 Cygwin
Cygwin64>
--Ken Nellis
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: pipe handling errors
2014-07-15 20:40 ` Nellis, Kenneth
@ 2014-07-15 22:05 ` Christopher Faylor
2014-07-15 22:27 ` Christopher Faylor
0 siblings, 1 reply; 15+ messages in thread
From: Christopher Faylor @ 2014-07-15 22:05 UTC (permalink / raw)
To: cygwin
On Tue, Jul 15, 2014 at 08:40:32PM +0000, Nellis, Kenneth wrote:
>From: Christopher Faylor
>>On Tue, Jul 15, 2014 at 07:17:48PM +0000, Nellis, Kenneth wrote:
>>>From: Nellis, Kenneth
>>><snip>
>>>> 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
>>><snip>
>>>
>>>Thought it might be useful to add that I can fairly easily get the same
>>>minute-long hang with a simpler command:
>>>
>>>Cygwin64> strings *Subsystem | wc -l
>>
>>What's your cwd when you run this command?
>
>Well, it *was* on a network drive, but that appears to be irrelevant:
>
>Cygwin64> date; seq 10000 | wc -l; date
>Tue Jul 15 16:31:52 EDT 2014
>10000
>Tue Jul 15 16:32:52 EDT 2014
>Cygwin64> pwd
>/home/knellis
>Cygwin64> cygpath -w $PWD
>C:\cygwin\home\knellis
>Cygwin64> uname -srvmo
>CYGWIN_NT-6.1 1.7.31s(0.273/5/3) 20140715 15:34:37 x86_64 Cygwin
>Cygwin64>
Yes, I saw that, but I can't duplicate the problem with that command sequence.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: pipe handling errors
2014-07-15 22:05 ` Christopher Faylor
@ 2014-07-15 22:27 ` Christopher Faylor
2014-07-16 12:44 ` Nellis, Kenneth
0 siblings, 1 reply; 15+ messages in thread
From: Christopher Faylor @ 2014-07-15 22:27 UTC (permalink / raw)
To: cygwin
On Tue, Jul 15, 2014 at 06:05:27PM -0400, Christopher Faylor wrote:
>Yes, I saw that, but I can't duplicate the problem with that command sequence.
I took a stab at another change which may ameliorate the problem. Please
try the latest snapshot.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: pipe handling errors
2014-07-15 22:27 ` Christopher Faylor
@ 2014-07-16 12:44 ` Nellis, Kenneth
2014-07-16 14:28 ` Christopher Faylor
0 siblings, 1 reply; 15+ messages in thread
From: Nellis, Kenneth @ 2014-07-16 12:44 UTC (permalink / raw)
To: cygwin
From: Christopher Faylor
>On Tue, Jul 15, 2014 at 06:05:27PM -0400, Christopher Faylor wrote:
>>Yes, I saw that, but I can't duplicate the problem with that command sequence.
>
>I took a stab at another change which may ameliorate the problem. Please try the latest snapshot.
Indeed, with this snapshot I was not able to reproduce the problem. Thank you!
Cygwin64> uname -srvmo
CYGWIN_NT-6.1 1.7.31s(0.272/5/3) 20140716 11:15:29 x86_64 Cygwin
Cygwin64>
--Ken Nellis
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: pipe handling errors
2014-07-16 12:44 ` Nellis, Kenneth
@ 2014-07-16 14:28 ` Christopher Faylor
0 siblings, 0 replies; 15+ messages in thread
From: Christopher Faylor @ 2014-07-16 14:28 UTC (permalink / raw)
To: cygwin
On Wed, Jul 16, 2014 at 12:44:25PM +0000, Nellis, Kenneth wrote:
>From: Christopher Faylor
>>On Tue, Jul 15, 2014 at 06:05:27PM -0400, Christopher Faylor wrote:
>>>Yes, I saw that, but I can't duplicate the problem with that command sequence.
>>
>>I took a stab at another change which may ameliorate the problem. Please try the latest snapshot.
>
>Indeed, with this snapshot I was not able to reproduce the problem. Thank you!
>
>Cygwin64> uname -srvmo
>CYGWIN_NT-6.1 1.7.31s(0.272/5/3) 20140716 11:15:29 x86_64 Cygwin
Good to hear. Thanks for confirming.
For the curious, I increased the size of the signal pipe buffer. I
should have done that when I made signal pipes "nowait" to work around
problems with gdb a couple of releases ago. I also made the signal
sender retry if WriteFile returns success but the number of bytes sent
was not what was requested (since these are message-style pipes the
size should always be either zero or correct).
Increasing the size of the buffer should have been enough to fix the
problem but, when possible, I like to use two forms of protection when I
fix a bug.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2014-07-17 8:25 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-16 17:36 pipe handling errors Ti Strga
2014-07-17 8:25 ` Corinna Vinschen
-- strict thread matches above, loose matches on Subject: below --
2014-07-14 17:40 Nellis, Kenneth
2014-07-15 9:49 ` Corinna Vinschen
2014-07-15 13:51 ` Nellis, Kenneth
2014-07-15 15:45 ` Corinna Vinschen
2014-07-15 18:53 ` Nellis, Kenneth
2014-07-15 19:17 ` Nellis, Kenneth
2014-07-15 19:36 ` Nellis, Kenneth
2014-07-15 19:52 ` Christopher Faylor
2014-07-15 20:40 ` Nellis, Kenneth
2014-07-15 22:05 ` Christopher Faylor
2014-07-15 22:27 ` Christopher Faylor
2014-07-16 12:44 ` Nellis, Kenneth
2014-07-16 14:28 ` Christopher Faylor
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).