On 8/1/2019 5:17 PM, Ken Brown wrote: > 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?
I just built a version of grep in which I added 'signal(SIGPIPE, SIG_DFL)', and the error is gone. So it looks like grep has in fact been receiving SIGPIPE, and for some reason it is not using the default signal handler for SIGPIPE in a terminal started by xwin-xdg-menu. Could this be a gtk issue? Does it mess with the signal handlers? Ken
