[Gc] Thoughts on this deadlock issue?

Boehm, Hans hans.boehm at hp.com
Fri Jun 29 12:48:25 PDT 2007

> From:  jim marshall
> Sent: Friday, June 22, 2007 5:05 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Thoughts on this deadlock issue?
> We've run into what appears to be a deadlock situation. We 
> have an application which dynamically loads shared objects. 
> These shared objects can do a lot of things and are not 
> required to use our applications memory routines (which use 
> GC). We are seeing a situation where one of these shared 
> objects starts a bunch of threads, it uses normal malloc/free 
> calls. At some point a thread calls a function in our 
> application which allocates some memory. The GC does it's 
> stop world thing, then goes into debug_malloc (this is a 
> debug build). What appears to happen is that the GC attempts 
> to get the heap lock, but one of the other non-GC threads is 
> already in a malloc/free call and owns the lock. 
> So we get into a deadlock where the GC is stuck waiting for a 
> mutex which is owned by one of the other threads which is stopped.
In general, performing a garbage collected allocation (or maniuplating
pointers to the GC heap) from a thread that the garbage collector does
not know about is a bad thing.  I'm not quite sure whether that's
happening here.

But these aren't quite the symptoms I would have expected.  The GC
should always get the heap lock (and any other lock it might need)
before it stops the world.  Thus I'm not sure how a thread could be
stopped while holding the lock.  The thread doing the stopping should
have the lock.

> Does this sound plausible (I am basing this off of result 
> from another engineer)?
> Any thoughts on how to work around it?
> Thanks
> Jim
> --
> Jim Marshall
> Sr. Staff Engineer
> WBEM Solutions, Inc.
> 978-947-3607
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> https://www.hpl.hp.com/hosted/linux/mail-archives/gc/

More information about the Gc mailing list