Sean Kelly wrote:
== Quote from Sean Kelly (s...@invisibleduck.org)'s article
One thing I'm not entirely sure about is whether the signal handler will always
have a valid, C-style call stack tracing back into user code. These errors are
triggered by hardware, and I really don't know what kind of tricks are common
at that level of OS code. longjmp() doesn't have this problem because it
doesn't
care about the call stack--it just swaps some registers and executes a JMP. I
don't suppose anyone here knows more about the feasibility of throwing
exceptions from signal handlers at all? I'll ask around some OS groups and
see what people say.
I was right, it is illegal to throw an exception from a signal handler. And
worse,
it's illegal to call malloc from a signal handler, so you can't safely create an
exception object anyway. Heck, I'm not sure it's even safe to perform IO from
a signal handler, so tracing directly from within the handler won't even work
reliably. In short, while I'm totally fine with people using this in their own
code, it's too unreliable to make an "official" solution by adding it to
Druntime.
Weird, it works just fine for me. Maybe its because the exception is
always caught in the thread's entry point, i never tried to let such an
exception unwind past the entry point. I haven't tried malloc or any I/O
either.
There still should be a way to grab the backtrace and context data from
the hidden ucontext_* parameter and do something with it after returning
from the signal handler.
The whole idea of a crash handler is to limit the number of times you
need to do postmortem debugging after a crash, or launch the process
again within the debugger.
