Bug 11630 – shared library segv

Daniel Murphy's ubuntu 12.10 box libc-2.15 using ld.bfd (not ld.gold) g++ 4.7.2 druntime/test/shared/obj/linux/64/host test fails very reliably, but not 100%. From the core file: #0 0x00007ffff7908c1d in get_nprocs () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ffff789513e in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007ffff78990cb in malloc () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007ffff7ddb371 in ?? () from /lib64/ld-linux-x86-64.so.2 #4 0x00007ffff7dec5e0 in __tls_get_addr () from /lib64/ld-linux-x86-64.so.2 #5 0x00007ff80cb13324 in core.thread.thread_suspendHandler() () from /home/user/d-tester/client/master-test-Linux_64_64/druntime/lib/libdruntime-linux64.so #6 0x00007ff80cb14938 in core.thread.callWithStackShell() () from /home/user/d-tester/client/master-test-Linux_64_64/druntime/lib/libdruntime-linux64.so #7 0x00007ff80cb13302 in thread_suspendHandler () from /home/user/d-tester/client/master-test-Linux_64_64/druntime/lib/libdruntime-linux64.so #8 <signal handler called> #9 0x00007ff80d0583c1 in clone () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x00007ff80c697dc0 in ?? () from /lib/x86_64-linux-gnu/libpthread.so.0 #11 0x00007ff80c190700 in ?? () #12 0x0000000000000000 in ?? () disassembly of frame 5 from objdump (looks the same from inside gdb): 000000000005e308 <_D4core6thread21thread_suspendHandlerUiZv2opMFPvZv>: 5e308: 55 push %rbp 5e309: 48 8b ec mov %rsp,%rbp 5e30c: 48 81 ec 98 00 00 00 sub $0x98,%rsp 5e313: 53 push %rbx 5e314: 66 48 8d 3d ac e8 23 data32 lea 0x23e8ac(%rip),%rdi # 29cbc8 <_DYNAMIC+0x7b0> 5e31b: 00 5e31c: 66 66 48 e8 1c 4d ff data32 data32 callq 53040 <__tls_get_addr@plt> 5e323: ff 5e324: 48 8b 18 mov (%rax),%rbx 5e327: 48 85 db test %rbx,%rbx ... The main linux tester boxes all pass this test quite reliably.

I remember that I had a dead lock with this test once, but I couldn't reproduce it.

It's deadlocked a few times in the tester. When that happens, I eventually notice and kill it. I'll try to remember to gather a stack trace next time.

Maybe related to bug 11684?

This looks like a it may be a duplicate of issue #11981, could you re-test with the fix for 11981 applied ? (The fix has already been merged.)

Daniel, when you get a chance, can you confirm that this is fixed on that older ubuntu vm you have? I just tried to login to it and it's not up right now, apparently. If you can't reproduce it by running the druntime unit tests several times, go ahead mark this bug resolved.

It does appear to be fixed after updating to head, I agree it's most likely a duplicate. *** This issue has been marked as a duplicate of issue 11684 ***

*** This issue has been marked as a duplicate of issue 11981 ***

(In reply to comment #6) > It does appear to be fixed after updating to head, I agree it's most likely a > duplicate. > > *** This issue has been marked as a duplicate of issue 11684 *** Martin notified me that there's a bounty on this issue, so I went to explicitly double check that it was indeed an incidental fix in case I go claiming someone else's merit. On a VM with an environment from the OP (Ubuntu 12.10, libc-2.15) 'host' test indeed segfaults on every single run up to and including commit https://github.com/D-Programming-Language/druntime/commit/932c05ce386d9ee585c67745e268867c10a6e337 (last commit before the 11981 fix). On https://github.com/D-Programming-Language/druntime/commit/4ce7f1d36008ec9c00f4ec8d3a1b38fc2ef3452f (merge for 11981 fix) segfaults are gone. I guess in later libc versions the persistent segfault transformed into an occasional deadlock, but the reason remained the same.