Austin Donnelly wrote:
>
> Current gimp (1.1.21) seems to have problems with recovering from any
> plugin that dies. Things start going wrong when it takes a SIGPIPE
> while trying to write(read?) to the pipe to the plugin which is dead.
> Rather than ignoring SIGPIPE, and collecting an EPIPE from the io
> operation and using this to trigger dead plugin cleanup operations,
> gimp currently treats SIGPIPE just like any other signal: it's fatal.
> Unfortunately, while attempting to print out some error message or
> other, gimp causes a segfault. This might be due to non-reentrant
> stdio libraries in use, I don't know. According to POSIX, the only
> thing you're allowed to do is read or write variables of type
> sigatomic_t. Calling libc funcitions (including printf()) sounds like
> a recipe for disaster, especially with a non-reentrant libc.
>
> This needs some more thought, and I don't have much time right now to
> look into any more. I'm pretty sure that plugins were correctly
> cleaned up on their unexpected termination at some earlier stage. The
> whole point of plugins being separate processes is that a plugin
> should be unable to cause the main gimp app to crash: if they can then
> this is a fairly critical bug that should be fixed.
Hi Austin,
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.
There is also an infinite loop using 30% of my cpu time in all cases where
a dying plugin does _not_ kill gimp. This also happens if a plugin calls
gimp_quit() (which is the recomended way of aborting a plugin and it
definitely worked before, too).
I suspect there are some strange things going on in plug_in.c like
a forgotten plug_in_push() or the following (unrelated):
-------------------------------
/* plug_in_pop (); */
plug_in_params_destroy (proc_run.params, proc_run.nparams, FALSE);
old_recurse = plug_in->recurse;
plug_in->recurse = TRUE;
/* gtk_main (); */
/* return_vals = plug_in_get_current_return_vals (proc_rec); */
-------------------------------
which, toghether with libgimp/gimp.c:
-------------------------------
/* No longer a return message */
/* proc_return.name = proc_run->name; */
/* proc_return.nparams = nreturn_vals; */
/* proc_return.params = (GPParam*) return_vals; */
/* if (!gp_temp_proc_return_write (_writechannel, &proc_return)) */
/* gimp_quit (); */
-------------------------------
makes it impossible to call temp procs across plugins. I tried to use temp
procs in a naive way (i.e. how expected) and totally failed when hacking
the help browser's temp proc. The caller just doesn't get a return message
when calling a plugin's temp proc. At least this is my theory :)
[ no conclusion ]
starting gdb...
--Mitch
