Null references redux

Jeremie Pelletier jeremiep at gmail.com
Tue Sep 29 12:15:17 PDT 2009


Sean Kelly wrote:
> == Quote from Sean Kelly (sean at 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.



More information about the Digitalmars-d mailing list