On Fri, 2 Aug 2019 14:34:02, Ken Brown wrote: > I think I've finally got it. > > First of all, here's what POSIX says about signal handlers after an exec: > > "Signals set to the default action (SIG_DFL) in the calling process > image shall be set to the default action in the new process image. > Except for SIGCHLD, signals set to be ignored (SIG_IGN) by the calling > process image shall be set to be ignored by the new process image. > Signals set to be caught by the calling process image shall be set to > the default action in the new process image (see <signal.h>)." > > Second, here's a quote from the GTK+ documentation for gtk_init(): > > "Since 2.18, GTK+ calls signal (SIGPIPE, SIG_IGN) during initialization, > to ignore SIGPIPE signals, since these are almost never wanted in > graphical applications. If you do need to handle SIGPIPE for some > reason, reset the handler after gtk_init(), but notice that other > libraries (e.g. libdbus or gvfs) might do similar things." > > Third, xwin-xdg-menu calls gtk_init() near the beginning of main(). > > Putting this all together, Eric's explanation is indeed correct. All > processes created by xwin-xdg-menu via fork/exec inherit the property of > ignoring SIGPIPE. > > I don't know if this is a bug, but it certainly leads to surprising > behavior. Jon, maybe xwin-xdg-menu needs to call signal(SIGPIPE, > SIG_DFL) either after calling gtk_init() or before calling exec()?
Another option? - https://bugs.python.org/issue1652 - see msg115364 (Author: Mitar) # GHC Haskell compiler is currently opting for a different solution: # installing an default empty handler which is cleared by exec # automatically and signal handler is restored back to SIG_DFL: # # http://hackage.haskell.org/trac/ghc/ticket/4274 Installing the empty handler after the call to gtk_init() ... Henri -- 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
