Question

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.

Answer 1

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.