Re: Regression (last snapshot)

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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

On Jul 27 15:24, Ken Brown wrote:
> On 7/27/2019 6:21 AM, Houder wrote:
> > On Fri, 26 Jul 2019 22:12:43, Ken Brown  wrote:
> > 
> >> On 7/22/2019 2:47 PM, Houder wrote:
> > 
> >>> The specific regression as reported, has gone.
> >>>
> >>> 64-@@ uname -a
> >>> CYGWIN_NT-6.1 Seven 3.1.0s(0.339/5/3) 2019-07-22 16:43 x86_64 Cygwin
> >>> 64-@@ ls -lL <(grep bash .bashrc)
> >>> pr-------- 1 Henri None 0 Jul 22 20:36 /dev/fd/63
> >>
> > Over all the behavior has simularity w/ the error reported by David Karr:
> > 
> >      https://cygwin.com/ml/cygwin/2019-07/msg00150.html
> >      ( Piping input from subprocess loses track of temp file )
> 
> Thanks, I hadn't noticed that.
> 
> The situation is more complicated than what I reported.  First, it happens even 
> in cygwin-3.0.7, as David Karr's report suggests.  Second, it's true that I can 
> only reproduce it under X11, but the pattern is not as regular as I thought.  I 
> just ran the ls command 1000 times in an xterm window under cygwin-3.0.7, and I 
> got the "Broken pipe" error 390 times, with a varying number of consecutive 
> successful runs between the errors.
> 
> Repeating this under the 20190722 or 20190725 snapshots gave slightly worse 
> results (close to 500 errors).  Using my own unoptimized build of cygwin1.dll, 
> the error count went up to about 650.

I just tried this myself and I can't reproduce the problem.  1000 runs,
no error.

> I tried running under gdb, but I couldn't get grep to fail.  More precisely, I 
> didn't see an error message from grep.  Every run looked like this:
> 
> $ gdb bash
> GNU gdb (GDB) (Cygwin 8.2.1-1) 8.2.1
> [...]
> (gdb) r -c 'ls -lL <(grep bash .bashrc)'
> Starting program: /usr/bin/bash -c 'ls -lL <(grep bash .bashrc)'
> [...]
> pr-------- 1 kbrown None 0 2019-07-27 11:07 /dev/fd/63
> [...]
> [Inferior 1 (process 21712) exited normally]
> 
> It would be better to be able to debug ls and/or grep, but I don't know how to 
> get to subprocesses in gdb.  And I think I have to start with 'gdb bash' in 
> order for the process substitution to happen.

Yeah, subprocess debugging is a problem in GDB.  Given how this works,
you can at least take grep out of the picture.  Bash is doing all the
lifting, so it's just bash and ls.   Did you try to reproduce this under
strace?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]