[Gc] Re: Win32: Deadlock if DEBUG_THREADS
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
> 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
> > gcc -DALL_INTERIOR_POINTERS -DGC_THREADS -DDEBUG_THREADS -g
> > [-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
> GC_USE_GETWRITEWATCH value (0/1).
> > 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
> 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.
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc