[Gc] Question on MPROTECT
hans.boehm at hp.com
Sat Sep 19 11:40:24 PDT 2009
> -----Original Message-----
> From: Ivan Maidanski
> Sent: Saturday, September 19, 2009 1:39 AM
> Let's assume: the client code uses signal(SEGV) for handling
> null pointer de-references (to throw NullPtrExc).
> At present, MPROTECT doesn't work with such client code (at
> least on Win32).
> Theoretical Q: Is it possible to change MPROTECT
> implementation (e.g, on Win32) to deal with such client code
I think the details are platform-specific, and somewhat dependent on the client. The GC code tries to save a prior exception handler, and invokes that if the GC can't handle the exception. It tries to do this for Windows SetUnhandledExceptionFilter, as well as for Posix handlers. In both cases, this requires that the GC be initialized second, or that the client code is similarly careful. For Windows, it also requires that the client code actually use SetUnhandledExceptionFilter, as opposed more directly installing a handler. Or the client code has to rethrow the exception if it can't handle it.
I suspect that in both cases, ther are some rough edges. On Posix, there's an issue of invoking the old handler with the right calling convention. The code to do that has gradually improved, but it's probably still imperfect.
In spite of all of this, I think gcj on Linux, for example, fundamentally supports using SIGSEGV for both the collector and null pointer exceptions, though I think it has other problems with incremental GC.
> PS. For now, such client code works with
> GC_ENABLE_INCREMENTAL on Win32 using GWW.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc