Am Mon, 17 Jun 2013 10:46:19 -0700 schrieb Sean Kelly <s...@invisibleduck.org>:
> On Jun 13, 2013, at 2:22 AM, Marco Leise <marco.le...@gmx.de> wrote: > > > Here is an excerpt from a stack trace I got while profiling > > with OProfile: > > > > #0 sem_wait () from /lib64/libpthread.so.0 > > #1 thread_suspendAll () at core/thread.d:2471 > > #2 gc.gcx.Gcx.fullcollect() (this=...) at gc/gcx.d:2427 > > #3 gc.gcx.Gcx.bigAlloc() (this=..., size=16401, poolPtr=0x7fc3d4bfe3c8, > > alloc_size=0x7fc3d4bfe418) at gc/gcx.d:2099 > > #4 gc.gcx.GC.mallocNoSync (alloc_size=0x7fc3d4bfe418, bits=10, size=16401, > > this=...) gc/gcx.d:503 > > #5 gc.gcx.GC.malloc() (this=..., size=16401, bits=10, > > alloc_size=0x7fc3d4bfe418) gc/gcx.d:421 > > #6 gc.gc.gc_qalloc (ba=10, sz=<optimized out>) gc/gc.d:203 > > #7 gc_qalloc (sz=<optimized out>, ba=10) gc/gc.d:198 > > #8 _d_newarrayT (ti=..., length=4096) rt/lifetime.d:807 > > #9 sequencer.algorithm.gzip.HuffmanTree.__T6__ctorTG32hZ.__ctor() > > (this=..., bitLengths=...) sequencer/algorithm/gzip.d:444 > > > > Two more threads are alive, but waiting on a condition > > variable (i.e.: in pthread_cond_wait(), but from my own and > > not from druntime code. Is there some obvious way I could have > > dead-locked the GC ? Or is there a bug ? > > I assume you're running on Linux, which uses signals (SIGUSR1, specifically) > to suspend threads for a collection. So I imagine what's happening is that > your thread is trying to suspend all the other threads so it can collect, and > those threads are ignoring the signal for some reason. I would expect > pthread_cond_wait to be interrupted if a signal arrives though. Have you > overridden the signal handler for SIGUSR1? No, I have not overridden the signal handler. I'm aware of the fact that signals make pthread_cond_wait() return early and put them in a while loop as one would expect, that is all. -- Marco