[Gc] Thoughts on this deadlock issue?
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
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?
> Jim Marshall
> Sr. Staff Engineer
> WBEM Solutions, Inc.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc