[Gc] Handling segfaults that are not due to the GC's write barrier

Henning Makholm Henning at octoshape.com
Wed Apr 2 05:22:14 PST 2008


Hi.

I'm using version 6.7 of the garbage collector for a win32 project.

I want to install a last-resort filter for unhandled SEH exceptions
that makes a post-mortem dump for later analysis rather than let
everything be forgotten once the user has seen the tombstone dialog.

The task at hand is to make this coexist with the GC's MPROTECT_VDB
filter. For the time being we're not using incremental collection
(so, IIUC, the GC does not actually install any filter), but I'm
researching things such as not to accidentally make it too difficult
to start doing so in the future.

Two options may be considered:

 a) First let the GC install its handler, and afterwards install
    my own handler, saving the address of the GC's one. My handler
    would start by calling the saved handler and only act if it
    returns EXCEPTION_CONTINUE_SEARCH.

 b) Install my own handler before initializing the GC, and except
    its handler to call through to me for exceptions that are not
    of interest to it.

The trouble with (a) is that the GC will re-assert its own handler
whenever a thread starts. I see a comment to the effect that
the SetUnhandledExceptionFilter syscall may not work quite as
globally as it is documented to - but if it at least affects all
_existing_ threads, there will be a time window before I have a
chance to re-install my own handler over the GC one, and some other
thread may throw an exception during this time.

On the other hand, the GC source code does not look like (b) is a
supported option. The GC_write_fault_handler() function in os_dep.h
calls through to the previous handler only inside the

   if (SIG_OK && CODE_OK) { ... }

If this condition is false (the exception is anything but a
write access violation, e.g., a read of *NULL, illegal instruction
or divide-by-0), the fault handler returns
EXCEPTION_CONTINUE_SEARCH without considering that a previous
handler may exist.

Is that a bug, or am I overlooking something?
The same thing appears to happen in 7.1alpha3.

--
Henning Makholm
OctoShape ApS



More information about the Gc mailing list