4

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.

Slaus
  • 2,086
  • 4
  • 26
  • 41
  • Calling the same handler again could lead to endless recursion, I doubt that this is the defined behavior on any platform. – scai Aug 13 '12 at 14:14
  • Well, on that link is told about fixing the problem which caused the segmentation fould, but not about segmentation fault within segmentation fault handler itself. – Slaus Aug 13 '12 at 14:16
  • Probably infinite recursion. I don't thnk that it's a good idea to be writ ing a segfault handler anyway. If your application segfaults, you probably want to terminate. I you using the segfault hander for anything but crucial application cleanup or debugging, you probably shouldn't be using it. – Linuxios Aug 13 '12 at 14:16
  • @scai, commentary was dramatically changed. – Slaus Aug 13 '12 at 14:17
  • @Linuxios, I would BET on it too :) – Slaus Aug 13 '12 at 14:18
  • 1
    @Slav: Yeah. But this is an interesting question, and I'm interested to see if someone can come up with something definitive. – Linuxios Aug 13 '12 at 14:19

2 Answers2

2

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.

jxh
  • 69,070
  • 8
  • 110
  • 193
1

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 :)

Pavan Manjunath
  • 27,404
  • 12
  • 99
  • 125