On 05/21/2014 06:28 PM, Kieran Colford wrote: > It is not mentioned anywhere why the signals which generate core dumps > are ignored by this module even though they are equally fatal to the > process. > > The only speculated reason for this is that the cleanup routine my > alter the state of the running process, making the core dump difficult > to use in debugging. > > On the other hand, in a program that sets up temporary files, a fatal > signal from an assert statement or a rogue call to abort (say from the > xalloc-die module) will kill the process and pollute the user's /tmp > directory. This also covers things such as segmentation faults and > division by 0 errors. > --- > lib/fatal-signal.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/lib/fatal-signal.c b/lib/fatal-signal.c > index 9a6f5f1..7138e3f 100644 > --- a/lib/fatal-signal.c > +++ b/lib/fatal-signal.c > @@ -75,6 +75,19 @@ static int fatal_signals[] = > #ifdef SIGBREAK > SIGBREAK, > #endif > + /* Core dump signals. */ > +#ifdef SIGABRT > + SIGABRT, > +#endif > +#ifdef SIGFPE > + SIGFPE, > +#endif > +#ifdef SIGSEGV > + SIGSEGV, > +#endif > +#ifdef SIGSYS > + SIGSYS, > +#endif > 0 > }; > >
I think the idea here is that the current set of listed signals are _externally_ generated. I.E. the program is in a consistent state when it gets the signal and therefore can legitimately gracefully terminate. However the signals you add above would be generated due to an _internal_ inconsistency, and the safest thing in that case would be to stop and dump core rather than trying to run more logic and potentially do something undefined. I see SIGQUIT is not one of the listed signals. That one might be added to the list? cheers, Pádraig.
