[Gc] Re: Win32: Deadlock if DEBUG_THREADS

Boehm, Hans hans.boehm at hp.com
Thu Nov 5 16:21:52 PST 2009

> From:  Ivan Maidanski
> Sent: Thursday, November 05, 2009 12:28 PM
> To: gc at napali.hpl.hp.com
> Subject: [Gc] Re: Win32: Deadlock if DEBUG_THREADS
> Hi!
> An hour ago I wrote:
> > Today I ran into a deadlock on Win32 with DEBUG_THREADS defined.
> > The simplest config to reproduce is (for MinGW, for VC++ is 
> similar):
> > [-DGC_ASSERTIONS] -I include -I libatomic_ops/src tests/test.c *.c 
> > -luser32
> It's easier to reproduce it with -DPARALLEL_MARK (with or w/o 
> > 
> > The deadlock occurs at least in 1/5 runs. Not observed if 
> set GC_DISABLE_INCREMENTAL=1. Doesn't depend on 
> > 
> > At present, I've failed to found out the place of the 
> problem (I observe 3 threads waiting for alloc lock in 
> GC_malloc, 2 threads are waiting for some system resource in 
> WriteFile(),...
> Not in WriteFile(), in EnterCriticalSection() in GC_write().
> > ... 1 thread is waiting for a system resource in 
> CreateThread() and the backtrace for the main thread is not visible).
> The main thread is in GC_write acquiring GC_write_cs too.
Is one of the threads waiting for GC_write_cs already holding it, e.g. is it running a collection?

> > 
> > BTW. What's the purpose of GC_write_cs (beyond atomicity of 
> in-line writes)?
I'm not sure it should be 100% necessary.  I did find some old message from Romano Paolo Tenca that it helps with debugging in some configurations, perhaps for those atomicity reasons.

> And why do we need to acquire it in GC_stop_world?
So that we don't stop a thread that's holding it, and then try to acquire it ourselves, which would of course lead to a deadlock.
> (Removing GC_write_cs doesn't solve anything...)
Which seems odd, since it did seem to be involved in the deadlock.

Clearly the trick here is to figure out who is holding which lock.  I think that for GC_write_cs that should be easily determinale by what's on the stack.  It's only acquired in a couple of places which, based on code inspection, always release it again.

If this happens with assertions enabled, GC_lock_holder should tell you who holds the allocation lock, I think.

> Bye.
> _______________________________________________
> 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