Re: [Gc] Question on MPROTECT
ivmai at mail.ru
Sat Sep 19 12:07:11 PDT 2009
"Boehm, Hans" <hans.boehm at hp.com> wrote:
> > From: Ivan Maidanski
> > Sent: Saturday, September 19, 2009 1:39 AM
> > Hi!
> > 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
> > correctly?
> 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.
Here you really reached my theoretical Q - I try to reformulate it (for Win32 only):
1. Could GC be able to rethrow the exception if it can't handle it (eg. for addresses in NULL area);
2. If 1 is yes: if GC_INIT() is called first, could GC intercept the client attempts to set a handler so that GC would be able to rethrow the exception (and be "invisible" to the client).
[May be, if I'd knew SEH better then I wouldn't ask such questions.]
> 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.
More information about the Gc