6

I just stumbled upon the segvcatch library which promises to wrap segfaults and floating point errors into appropriate exceptions.

Is using this library safe, if I add the precondition that all segfaults caught will only be null pointer accesses (i.e., no array overflows or invalid pointers which could have screwed up the memory completely before segfaulting, resulting in undefined behaviour anyway)? Will the program still have defined semantics after catching a nullptr segfault? What about floating point errors? Do they behave better/different?

Sidenote: Please no comments stating that any program producing a segfault is ill-formed anyway and should be debugged/fixed. I know that and I agree. Still, I am interested in this question.

gexicide
  • 38,535
  • 21
  • 92
  • 152

1 Answers1

5

Not safe.

The signal handlers are very simple, and they are simply wrong. Here's the SEGV handler:

void default_segv()
{
    throw std::runtime_error("Segmentation fault");
}

That is quite illegal, at least on POSIX. Throwing an exception from within a signal handler is a very, very bad idea.

Addendum
So why is this a bad idea?

With SIGALRM, it's worse than a bad idea; it's undefined behavior because alarms are asynchronous. With SIGSEGV and SIGBUS it's an extremely bad idea. With other signals, it's merely a bad idea. It might work, sometimes. Other times, it might not. Results can be quite disastrous when the magic doesn't work.

I'll look at SEGV first. One common cause of segmentation violations and bus errors is smashing the stack. There is no stack to unwind if this was the cause of the signal. The throw will try to unwind the stack, which will raise another SEGV. Now what? On my computer, that's a disaster.

Regardless of the signal, throwing inside a signal handler is not safe with respect to RAII because free() (and hence delete) is not safe to call within the context of a handler. There are a whole slew of functions that aren't safe to call from within the context of a signal handler. Everything that happens after the throw in the handler is done from within the context of the signal handler because the throw doesn't return from the handler. The throw bypasses the return.

Those unsafe calls and the unsafe unwinding means that a new signal can be raised while still handling that old signal. This recursive signal is highly problematic. On my computer, for example, the signal gets changed to SIGSTOP. The program doesn't exit, it doesn't drop core. It just hangs there, permanently frozen until I either kill -9 it or reboot the machine.

David Hammen
  • 32,454
  • 9
  • 60
  • 108
  • OK but it works in gcc, especially with -fnon-call-exceptions. Though in a bit different way: http://stackoverflow.com/questions/5860999/why-doesnt-my-signal-handler-which-throws-an-exception-trigger-more-than-once – queen3 Sep 13 '12 at 19:57
  • David, **why** is this a *very, very bad idea*? why is it illegal in C++11? @queen3 what's the point when using `-fnon-call-exceptions`? – Walter Sep 13 '12 at 21:07
  • thanks Walter, good comment! In addition, the library seems to do some magic around the segfault like adjusting the PC and stuff. So the handler you posted is not the only contribution of the library (a one line signal handler does not need an own library...) – gexicide Sep 14 '12 at 10:20
  • 1
    @Walter : Many reasons. #1: There is no stack to unwind if the SIGSEGV resulted from smashing the stack. #2: Not safe with respect to RAII because `free()` (and hence `delete`) is not safe to call within the context of a handler. #3: There's a whole slew of functions that aren't safe to call, and *everything* that happens after the `throw` is done inside the context of the signal handler. #4: A signal raised inside a signal is highly problematic. On my computer, for example, the signal is changed to SIGSTOP. I don't even get a core dump. I get a frozen executable that I have to kill -9. – David Hammen Sep 14 '12 at 13:31
  • @DavidHammen: What about floating point signals like division by zero? The stack and other stuff should not be broken after such signal. – gexicide Sep 14 '12 at 15:54
  • @gexicide: You're right; the stack should be safe -- so long as someone doesn't do something nasty such as a `kill -8 program` from outside. That's unlikely and evil. However, are your destructors safe? Remember, `free()` isn't safe, and hence neither is `delete`. A `throw` inside a signal handler means that all of the code that is executed between the `throw` and `exit` runs will run in the dynamic scope of the handler. Handlers should be very short. The `throw` makes them huge. – David Hammen Sep 14 '12 at 16:03
  • @DavidHammen: are you sure the library doesn't do anything to circumvent this problem? I don't understand all of its magic but there could be something lurking inside. – gexicide Sep 14 '12 at 16:05
  • @David: From what I understood free/malloc is not safe to call if the signal was raised from within free/malloc. With SEGV/FPE this would rarely be the case (if at all) so why should we avoid to call them from the signal handler? Or, is there any low-level detailed explanation of _why_ they should not be called? – queen3 Sep 14 '12 at 17:23
  • @gexicide (and queen3, too): See this page: http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html . There is a list of safe functions near the bottom of the page. It is those functions the vendor has to ensure are safe. A function not in that list is not safe; you had better not call it from the dynamic scope of a signal handler. If you do you have just invoked undefined behavior. UB is a get out of jail free card to compiler and library vendors. – David Hammen Sep 14 '12 at 18:55