[Gc] Re: Win32 hang with MPROTECT_VDB
hans.boehm at hp.com
Thu May 21 15:32:00 PDT 2009
> -----Original Message-----
> From: gc-bounces at napali.hpl.hp.com
> [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> Sent: Thursday, May 21, 2009 7:07 AM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Re: Win32 hang with MPROTECT_VDB
> "Boehm, Hans" <hans.boehm at hp.com> wrote:
> > I think the offending scenario is as follows:
> > - thread A takes a protection fault, and is somewhere
> inside ntdll, holding a system lock.
> > - thread B starts a GC, suspending A.
> > - thread B reprotects the heap.
> > - thread B subsequently tries to restart the world, in the
> process, setting t -> suspended to FALSE, for some t.
> I also observed fault at "thread -> last_stack_min = stack_min;"
Good point. Thanks.
> > - the access to t faults; B tries to invoke the protection handler.
> > - A hasn't yet been restarted; hence it still holds the system lock.
> B tries to invoke the protection handler... and what?
> At which point are A and B exactly?
A is still in a system library, presumably with a lock held; B tries to acquire the same lock in the process of trying to enter its fault handler.
I'm working on a patch that invokes GC_remove_protection in the right places. GC_remove_protection needs some tweaking to avoid redoing the system call if the page was already unprotected.
> Q: Is this possible in Unix too?
> /* Currently we do this by disabling the thread
> stopping */
> /* signals while this handler is running. An
> alternative might */
And indeed that should avoid the problem. Unfortunately, I don't know of a Windows interface that lets me do this.
More information about the Gc