Regression (last snapshot)
Thu Aug 1 21:17:00 GMT 2019
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
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?
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin