Re: Regression (last snapshot)

[Ken Brown <kbrown@cornell.edu>]

On 8/1/2019 12:04 PM, Corinna Vinschen wrote:
> On Aug  1 10:38, Eric Blake wrote:
>> On 8/1/19 10:30 AM, Ken Brown wrote:
>>
>>>>> 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.
>>
>>> 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.
>>
>> Could it be a case of xwin-xdg-menu calling signal(SIGPIPE, SIG_IGN) or
>> similar, and accidentally letting grep inherit the ignored SIGPIPE?
> 
> execve doesn't propagate the signal dispositions, they get reset to
> default.

I just realized, as a result of Eric's comment, that the explanation 
I've been pushing is nonsense.

What I've been explaining is why there would be a broken pipe, and 
therefore a SIGPIPE and EPIPE.  But I now see that that's not the issue. 
  The issue is whether grep gets the SIGPIPE and terminates before it 
has a chance to see the EPIPE.

So if grep isn't ignoring SIGPIPE, the only other possibility I can 
think of is that grep isn't receiving SIGPIPE, or at least that there's 
a delay before it receives it.  Why would that happen only in terminals 
started by xwin-xdg-menu?

Ken

--
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