Re: [PATCH] Added the core dumps signals to the list of caught signals.

[Pádraig Brady]

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.