Re: Regression (last snapshot)

[Ken Brown <kbrown@cornell.edu>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4388 bytes --]

On 8/1/2019 10:27 AM, Jon Turney wrote:
> On 31/07/2019 19:00, Ken Brown wrote:
>> On 7/31/2019 11:53 AM, Ken Brown wrote:
>>> On 7/29/2019 2:55 PM, Ken Brown wrote:
>>>> Here's the error that I can reproduce easily in xterm:
>>>>
>>>> $ ls <(grep bash .bashrc)
>>>> /dev/fd/63
>>>> grep: write error: Broken pipe
>>>>
>>>> This happens 98% of the time.  Notice that I used plain 'ls' rather 
>>>> than the
>>>> original 'ls -lL'.  With the latter, I get the broken pipe error 60% 
>>>> of the time
>>>> rather than 98%:
>>>>
>>>> $ ls -lL <(grep bash .bashrc)
>>>> pr-------- 1 kbrown None 0 2019-07-29 14:46 /dev/fd/63
>>>> grep: write error: Broken pipe
>>>>
>>>> What about the explanation I tried earlier, but perhaps not clearly: 
>>>> ls prints
>>>> /dev/fd/63 and then exits, thereby closing the read end of the pipe, 
>>>> while grep
>>>> (running asynchronously) hasn't finished writing to the write end of 
>>>> the pipe.
>>>>
>>>> The fact that I get the broken pipe error more often with plain 'ls' 
>>>> than with
>>>> 'ls -lL' is consistent with that.  And the fact that I get no errors 
>>>> with 'cat
>>>> <(grep bash .bashrc)' is also consistent with it, since cat doesn't 
>>>> exit until
>>>> grep has finished writing.
>>>>
>>>> On the other hand, this doesn't explain why I see the error only 
>>>> under xterm,
>>>> nor does it explain why you can't reproduce it at all.
>>>
>>> I've made some progress.  It turns out that the problem only occurs 
>>> in terminals
>>> launched from the xwin-xdg-menu tray icon.  I can even launch a 
>>> mintty window
>>> from that icon (System Tools -> Cygwin Terminal) and I'll see the 
>>> problem.  On
>>> the other hand, I can launch an xterm without using that icon (e.g., 
>>> 'DISPLAY=:0
>>> xterm -l&' from a mintty window) and I won't see the problem.
>>>
>>> So the issue has something to do with how xwin-xdg-menu launches 
>>> applications,
>>> and how that interacts with bash's process substitution.  I've just 
>>> downloaded
>>> the xwin-xdg-menu source and will see if I can figure out what's 
>>> going on.  I've
>>> also added Jon to the CC in case he has a chance to take a look.
>>
>> OK, when xwin-xdg-menu launches an application, it creates two pipes 
>> and sets
>> the application's stdout and stderr to the write ends of those pipes.  
>> For
>> example, here's what I see when I launch mintty from xwin-xdg-menu:
>>
>> $ pgrep mintty
>> 5375
>>
>> $ ls -l /proc/5375/fd
>> total 0
>> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 0 -> /dev/null
>> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 1 -> pipe:[38654736160]
>> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 2 -> pipe:[42949703456]
>> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 3 -> /dev/ptmx
>> lrwxrwxrwx 1 kbrown None 0 2019-07-31 13:37 4 -> /dev/windows
>>
>> These pipes are apparently used for logging.
> 
> That's correct.  Writes to those pipes are drained into the session 
> logfile (~/.xsession-errors), which you can view with the 'View logfile' 
> menu item.
> 
>> I don't see how this would explain my observations (grep reporting a 
>> broken
>> pipe), but it is at least a difference between a terminal started from
>> xwin-xdg-menu and an "ordinary" terminal.
>>
>> Anyway, I don't see any evidence here of a Cygwin bug.
> 
> I'm not so sure: these pipes for stdout/stderr of the mintty process 
> shouldn't have any influence at all on the child bash process (since 
> it's stdin/stdout/stderr is the slave end of a pty), but apparently they 
> somehow do?

Well, I can't be sure that the pipes are responsible.  It's just that 
the existence of the pipes is the only difference I could spot between 
an ordinary terminal and a terminal started from xwin-xdg-menu.

Is it possible that the logging somehow slows things down or changes the 
buffering, so that the grep process takes longer to complete?  This 
would be consistent with my theory that the broken pipe error doesn't 
really represent a bug, but rather it reflects the fact that ls exits 
before grep has finished writing.

Ken
\x03B‹KCB”\x1c›Ø›\x19[H\x1c™\^[ܝ\x1cΈ\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÜ\x1c›Ø›\x19[\Ëš\x1d^[[\x03B‘TNˆ\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ˜\KÃB‘^[ØÝ[Y[\x18]\x1a[ÛŽˆ\b\b\b\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÙ^[ØÜËš\x1d^[[\x03B•[œÝXœØÜšX™H\x1a[™›Îˆ\b\b\b\b\b\x1a\x1d\x1d\x1c\x0e‹ËØÞYÝÚ[‹˜ÛÛKÛ[\vÈÝ[œÝXœØÜšX™K\Ú[\^[\x19CBƒB