Hi,

SignalToRunError is a signal handler, but it calls an ErrorProc calling many functions, like CRelocateThreadVar (for accessing the exception stack), GetMem (to allocate an exception object); are these functions guaranteed to run correctly in a signal handler ?

Micha

Probably not. For darwin/ppc, I actually do it differently (for another reason, but that's not relevant here): I change the signal context to return to HandleErrorAddrFrame, putting the required parameters (runerror number, program counter/instruction pointer, stack pointer) in the parameter registers of the context.

Since there are only 3 parameters, it should be possible to do this even on i386.

Jonas

Jonas Maebe wrote

Since there are only 3 parameters, it should be possible to do this even on i386.

Implemented and committed; but thinking about it, does it really matter ? It's still being executed more or less asynchronous to the application: it could be in the middle of heap manager operation or throwing exception etc... which exactly was the problem with the signal handler, and isn't really solved.

Micha

It indeed only solves the problem that many functions (including some syscalls, or does this only apply to libc?) cannot be called safely during the execution of a signal handler.

Crashes due to errors in the run time system itself (or corruption of the rtl structures by external code) can probably never be handled properly using exceptions, since exceptions are also part of this same run time system. Even if you use dwarf exception frame info, you may still need some RTL support during exception handling.

Jonas