Could be the same as one of the previous threads. Sorry for being a little lazy (it's that kinda weekend):
I just noticed that the phobos linux 64/32 build had been running for almost 10 hours (I guess I need to add some timeout logic still). I attached gdb to get a stack trace: #0 0x55573425 in __kernel_vsyscall () #1 0x555b0469 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142 #2 0x555ab659 in _L_lock_835 () from /lib32/libpthread.so.0 #3 0x555ab4eb in __pthread_mutex_lock (mutex=0x8139264) at pthread_mutex_lock.c:82 #4 0x080f4065 in _d_criticalenter () #5 0x080d4ea3 in std.parallelism.__unittest2() () #6 0x080ed3a5 in std.parallelism.__T19ParallelForeachTaskTS3std5range13__T4iotaTiTiZ4iota6ResultTDFKiZiZ.ParallelForeachTask.impl() () #7 0x080d3253 in std.parallelism.AbstractTask.job() () #8 0x080d3523 in std.parallelism.TaskPool.tryDeleteExecute() () #9 0x080ed1e1 in std.parallelism.__T19ParallelForeachImplTS3std5range13__T4iotaTiTiZ4iota6ResultTDFKiZiZ.ParallelForeachImpl.__T17ResubmittingTasksZ.submitAndExecute() () #10 0x080e44a2 in std.parallelism.__T15ParallelForeachTS3std5range13__T4iotaTiTiZ4iota6ResultZ.ParallelForeach.opApply() () #11 0x080d49db in std.parallelism.__unittest2() () #12 0x080edba9 in std.parallelism.__modtest() () #13 0x080ff9dc in core.runtime.runModuleUnitTests() () #14 0x080efca2 in object.ModuleInfo.opApply() () #15 0x080ff8f7 in runModuleUnitTests () #16 0x080f4980 in rt.dmain2.main() () #17 0x080f45e8 in rt.dmain2.main() () #18 0x080f4594 in main () Without having looked at the code, the stack suggests a recursive call resulting in a deadlock. Notice frame 11 and 5 are in the same function. Have fun with it. Later, Brad _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
