Thorkil Naur wrote:
(gdb) info threads
* 1 process 20926 local thread 0x301b 0x94be61a8 in semaphore_wait_trap ()
(gdb) info thread
Thread 0x813 (local 0x301b) has current state "WAITING"
Thread 0x813 has a suspend count of 0.
(gdb) where
#0 0x94be61a8 in semaphore_wait_trap ()
#1 0x94bed424 in pthread_mutex_lock ()
#2 0x01342f00 in newBoundTask () at Task.c:153
#3 0x0132d03c in rts_lock () at RtsAPI.c:568
#4 0x013304f4 in hs_add_root (init_root=0x103b8 <__stginit_ZCMain>) at
RtsStartup.c:335
#5 0x013304c4 in startupHaskell (argc=5, argv=0xbffff3e4, init_root=0x103b8
<__stginit_ZCMain>) at RtsStartup.c:294
#6 0x01326550 in real_main () at Main.c:57
#7 0x013266d8 in main (argc=7, argv=0xbffff3e4) at Main.c:156
(gdb)
I recognize some of the functions from the dtrace entry trace from the GHC
RTS. In the next step, I would look at the involved code in more detail and
try to figure out what goes on, possibly helped by suitable instrumentation.
But in the meantime, I thought I would let have a look at it and hope that
you might provide some hints.
Ah, I bet you're falling afoul of the recent changes to OSThreads.h.
newBoundTask() does an ASSERT_LOCK_HELD(), which calls pthread_mutex_lock()
on a lock that is already held, hoping that it will return EDEADLK, and I
assume that it doesn't on OS X.
In any case, I rather think that we shouldn't be performing those
ASSERT_LOCK_HELDs unless DEBUG is on.
Kili: it looks like we need at least an #ifndef darwin_HOST_OS here, but
perhaps we should be inclusive rather than exclusive, and only add those
OSs that we know support EDEADLK.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
