[Gc] Re: Win32 hang with MPROTECT_VDB

Boehm, Hans 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
> 
> Hi!
> 
> "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.

Hans
> 


More information about the Gc mailing list