[Gc] Thoughts on this deadlock issue?

jim marshall jim.marshall at wbemsolutions.com
Fri Jun 29 13:16:28 PDT 2007

Boehm, Hans wrote:
>> 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.
No it isn't happening. We do not mix GC memory and non-GC memory (we've 
see how much of a bad idea that is ;) ). What is happening is the shared 
objects thread is doing some work at some point it calls a logging 
function in our server. We (for various reasons) copy the passed in 
message. Mean-while a different thread in this shared object is 
attempting to free an object it allocated via malloc (so it is calling 
free).  What appears to happen is that we call GC_MALLOC to allocate the 
size of the string at the same time this other (NON-GC) thread is 
freeing memory. So what appears to happen is that the NON-GC thread is 
in the CRT's free function, so it current has the CRT's heap lock. 
Meanwhile the GC "appears" to stop the world and call into the CRT as 
well were we deadlock.
This is all speculation based on input from another developer. I am 
sending him a debug build of the gc and going to get some real stack 
traces from him.
> 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.
I don't think the GC is grabbing the CRT's heap lock before stopping the 
world, which is what we think the issue is.

I will get more info.
>> 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/

Jim Marshall
Sr. Staff Engineer
WBEM Solutions, Inc.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://napali.hpl.hp.com/pipermail/gc/attachments/20070629/2b2e730f/attachment.htm

More information about the Gc mailing list