问题
Is there some defined behaviour for segmentation faults which happen within segmentation falut handler under Linux? Will be there another call to the same handler? If so, on all platforms, is it defined and so on. Thank you.
回答1:
Than answer depends on how you installed your signal handler. If you installed your signal handler using the deprecated signal() call, then it will either reset the signal handler to the default handler or block the signal being handled before calling your signal handler. If it blocked the signal, it will unblock it after your signal handler returns.
If you use sigaction(), you have control over which signals get blocked while your signal handler is being called. If you so specify, it is possible to cause infinite recursion.
It is possible to implement a safe wrapper around sigaction() that has an API similar to signal():
sighandler_t safe_signal (int sig, sighandler_t h) {
struct sigaction sa;
struct sigaction osa;
sa.sa_handler = h;
sigemptyset(&sa.sa_mask);
sa.sa_flags = 0;
if (sigaction(sig, &sa, &osa) < 0) {
return SIG_ERR;
}
return osa.sa_handler;
}
This blocks all signals for the duration of the signal handler call, which gets restored after the signal handler returns.
回答2:
From C-11 standard, 7.14.1.1,
When a signal occurs and func points to a function, it is implementation-defined whether the equivalent of signal(sig, SIG_DFL); is executed or the implementation prevents some implementation-defined set of signals (at least including sig) from occurring until the current signal handling has completed;
So Standard says that it is implementation defined whether it allows for recursive calls of the same signal handler. So I would conclude that the behaviour is defined but is implementation defined!
But its a total mess if a segfault handler is itself segfaulting :)
来源:https://stackoverflow.com/questions/11936020/segmentation-fault-within-segmentation-fault-handler