PEXCEPTION_POINTERS
struct, which is a PEXCEPTION_RECORD
and a CONTEXT*
, both of which are defined in the header files. The context structure is different on every platform because it lists the contents of the CPU registers at the time of the exception, while the ExceptionRecord
struct is the same, and contains the ExceptionCode
and the address where it occurred (in ExceptionInformation[1]
).The job of the exception handler is to determine where program execution should proceed after it returns. For Factor, the errors we handle are memory access errors, which happen when a stack overflows or underflows and hits a guard page, division by zero, and 'any other error'. We can't just jump to these Factor exception handlers inside the Win32 exception handler, but we can set the instruction pointer, the EIP register, to our handler and return
EXCEPTION_CONTINUE_EXECUTION
. In this way, we can let the operating system catch errors and report them to the user as "Data stack underflow", "Division by zero", and continue running Factor without expensive checks for each memory access or division.The stack pointer at the time of the exception is also important. If we were executing compiled Factor code, as determined by checking the fault address against the C predicate
in_code_heap_p
, then we set a global with this address to continue execution after the exception is handled. However, if we are in C code, then the global is left as NULL.Here is the code--much cleaner, and more correct, than before.
void c_to_factor_toplevel(CELL quot)
{
AddVectoredExceptionHandler(0, (void*)exception_handler);
c_to_factor(quot);
RemoveVectoredExceptionHandler((void*)exception_handler);
}
long exception_handler(PEXCEPTION_POINTERS pe)
{
PEXCEPTION_RECORD e = (PEXCEPTION_RECORD)pe->ExceptionRecord;
CONTEXT *c = (CONTEXT*)pe->ContextRecord;
if(in_code_heap_p(c->Eip))
signal_callstack_top = (void*)c->Esp;
else
signal_callstack_top = NULL;
if(e->ExceptionCode == EXCEPTION_ACCESS_VIOLATION)
{
signal_fault_addr = e->ExceptionInformation[1];
c->Eip = (CELL)memory_signal_handler_impl;
}
else if(e->ExceptionCode == EXCEPTION_FLT_DIVIDE_BY_ZERO
|| e->ExceptionCode == EXCEPTION_INT_DIVIDE_BY_ZERO)
{
signal_number = ERROR_DIVIDE_BY_ZERO;
c->Eip = (CELL)divide_by_zero_signal_handler_impl;
}
else
{
signal_number = 11;
c->Eip = (CELL)misc_signal_handler_impl;
}
return EXCEPTION_CONTINUE_EXECUTION;
}
void memory_signal_handler_impl(void)
{
memory_protection_error(signal_fault_addr,signal_callstack_top);
}
void divide_by_zero_signal_handler_impl(void)
{
general_error(ERROR_DIVIDE_BY_ZERO,F,F,signal_callstack_top);
}
void misc_signal_handler_impl(void)
{
signal_error(signal_number,signal_callstack_top);
}
2 comments:
Cheers,
First of all, congrats for the nice post that in all web is the only that explained what was happening with my factor windows binary!
However, the use of that API exception handler prevents the use of FACTOR in Windows 2000... Is there any simple way to overcome this limitation?
What I did was to "clean-up" the
function and just use (as in Windows CE);
void c_to_factor_toplevel(CELL quot)
{
c_to_factor(quot);
}
Then i can compile with mingw and
a working factor window appear. My question is (if you are kind enough to respond to a amateur programmer...) what "dangers" i'm incurring in by short-circuiting the exception handler mechanism...
Kind regards, and thanks in advance,
António Soares
(P.S around the web i saw people complaining about the inexistence of AddVectoredExceptionHandler in Windows 2000 API...)
AddVectoredExceptionHandler() is only available in WinXP and above.
Post a Comment