https://bugs.kde.org/show_bug.cgi?id=372504
--- Comment #7 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to David Hagood from comment #5) > OK, I've tried 3.11, with no change of behavior (still locks). > > (gdb) p vgPlain_threads[1].status > $13 = VgTs_Yielding > (gdb) p vgPlain_threads[1].exitreason > $14 = VgSrc_None > (gdb) p vgPlain_threads[2].status > $15 = VgTs_WaitSys > (gdb) p vgPlain_threads[2].exitreason > $16 = VgSrc_ExitProcess > (gdb) p vgPlain_threads[3].status > $17 = VgTs_WaitSys > (gdb) p vgPlain_threads[3].exitreason > $18 = VgSrc_ExitProcess > (gdb) p vgPlain_threads[4].status > $19 = VgTs_Empty > (gdb) p vgPlain_threads[4].exitreason > $20 = VgSrc_ExitThread > (gdb) p vgPlain_threads[5].status > $21 = VgTs_Empty > (gdb) p vgPlain_threads[5].exitreason > $22 = VgSrc_ExitThread Strange: all threads but thread 1 are in status exiting (2 and 3) or have exited already by themselves (4 and 5) However, 2 and 3 are still blocked in a syscall, while exit_group syscall in valgrind is calling VG_(nuke_all_threads_except)( tid, VgSrc_ExitProcess ); which should get the threads out of their syscall. Can you run (with 3.12) your testcase with --trace-signals=yes --trace-syscalls=yes and attach the resulting trace (from a little bit before the call to exit_group) till you reach the infinite loop. -- You are receiving this mail because: You are watching all bug changes.
