Tim Mooney wrote:
> In regard to: Re: EPIPE, Michael Natterer said (at 8:22pm on May 8, 2000):
> >Unfortunately this is not the reason why gimp dies on just any aborting
> >child. Although I 100% agree that SIGPIPE being fatal is the wrong thing
> >to do. I browsed CVS and Gimp is connecting SIGPIPE to on_signal() since
> >the beginning of CVS time.
> >Mysteriously, as you mention, it worked before. I'm also pretty sure that
> >the current state of signal processing behaves exactly like before Garry
> >started to fix the SIGCHLD bug.
> The current state of signal processing does *not* behave exactly as before:
> plug-in query works on alpha-dec-osf now. Using sigaction instead of signal
> should improve things across the board, on all platforms. signal() on HP-UX
> and Solaris was the SYSV signal, where the handler needed to be reset after
> every signal (and there was therefore a race condition), so even though major
> problems regarding signal handling were never reported on those platforms,
> they were lurking.
Ok, the handling of SIGCHLD has changed but SIGPIPE is handled as always in
Gimp and the call to gimp_signal_private() emulates the old signal()
> The SIGPIPE problem is because on_signal is currently treating it as a
> fatal signal (see the case on_signal in app/main.c). The on_signal routine
> should probably be modified to not treat SIGPIPE as fatal. That should fix
> the problem Austin is seeing (that others will no doubt see too). Someone
> should investigate the handler in 1.1.19 or earlier, and see what was being
> done on SIGPIPE there.
Nope, it unfortunately has another reason. I can't explain why it used to
work with SIGPIPE being fatal but the diffs of app/main.c show no semantical
changes at all down to CVS version 1.1.
> Austin is also correct that calling printf from the handler is probably
> asking for trouble. If a message must be written, some other method should
> be found (write *is* ok from a signal handler, but won't using *that* be
Hm, I guess printf from a signal handler which aborts the program should be
totally safe (while we should of course _not_ call the handler for SIGPIPE).
My current theory (TM) is that there are weird implications between SIGPIPE
and SIGCHLD (which we currently ignore) but I suspect this is total nonsense :)