On 7/26/2019 6:12 PM, 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 > > It turns out that this isn't completely fixed, but I only see the problem when > working under X11, and the error message is different. Here are the complete > reproduction steps: > > 1. Start the X server by using the XWin Server shortcut. > > 2. Use the X Applications Menu -> System Tools to start an xterm window. > > 3. In that window, execute the above 'ls' command.: > > $ ls -lL <(grep bash .bashrc) > pr-------- 1 kbrown None 0 2019-07-26 17:24 /dev/fd/63 > grep: write error: Broken pipe > > This is with the 2019-07-22 snapshot. With the 2019-07-25 snapshot, it's better > but still broken: I have to run the ls command twice to get the error: > > $ ls -lL <(grep bash .bashrc) > pr-------- 1 kbrown None 0 2019-07-26 17:39 /dev/fd/63 > > $ ls -lL <(grep bash .bashrc) > pr-------- 1 kbrown None 0 2019-07-26 17:39 /dev/fd/63 > grep: write error: Broken pipe > > Here's one more fact, which may or not provide further clues: When I exited the > X server while testing the 2019-07-22 snapshot, there was a /bin/sh process > still running that I couldn't kill with 'kill -9'. I had to kill it with the > Task Manager. > > Finally, here's an excerpt from the strace output for the failing ls command: > > 24 23441 [main] ls 1033 fhandler_proc::get_proc_fhandler: > get_proc_fhandler(/proc/1033/fd/63) > 25 23466 [main] ls 1033 mount_info::conv_to_win32_path: src_path > /proc/1033/fd/63, dst /proc/1033/fd/63, flags 0x0, rc 0 > 28 23494 [main] ls 1033 build_fh_pc: fh 0x180340098, dev 000000FB > 24 23518 [main] ls 1033 fhandler_process::exists: exists (/proc/1033/fd/63) > 28 23546 [main] ls 1033 __set_errno: cygheap_fdget::cygheap_fdget(int, > bool, bool):679 setting errno 9 > 24 23570 [main] ls 1033 __set_errno: off_t format_process_fd(void*, > char*&):394 setting errno 2 > > I'm in the process of building an unoptimized cygwin1.dll to see if I can get > further information. I just discovered that this problem already existed in commit f0ea836b7, which preceded the commit that led to the problem Houder reported. So this must be something different. I'll do a new bisection for the current problem. Ken BKCB؛[H\ܝΈY[K؛[\˚[BTNY[K٘\KB[][ێY[K˚[B[XܚXH[ΈY[K[ [XܚXK\[\CBB