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

Boehm, Hans hans.boehm at hp.com
Mon Apr 7 11:30:54 PDT 2008


Would it not make sense to just rely on GWW_VDB instead of MPROTECT_VDB for incremental collection?  I think GetWriteWatch has now been supported for long enough that we can generally rely on it.  I haven't tied it, but I suspect it dodges all these issues, and then some ...

Hans

> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Henning Makholm
> Sent: Wednesday, April 02, 2008 6:22 AM
> To: 'gc at linux.hpl.hp.com'
> Subject: [Gc] Handling segfaults that are not due to the GC's
> write barrier
>
> 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
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>



More information about the Gc mailing list