reassign 309566 valgrind thanks On Wed, May 18, 2005 at 03:52:01AM +0200, wim delvaux wrote: > Package: gdb > Version: 6.3-5 > Severity: important > > > when valgrind detects an error and I attach the debugger things > work fine. > > when I 'quit' gdb however I get : > > (gdb) q > The program is running. Quit anyway (and detach it)? (y or n) y > > /nevyn/local/gdb/gdb-6.3/gdb/linux-nat.c:1007: internal-error: > linux_nat_detach: Assertion `num_lwps == 1' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) n > > /nevyn/local/gdb/gdb-6.3/gdb/linux-nat.c:1007: internal-error: > linux_nat_detach: Assertion `num_lwps == 1' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) n > > core files are not created and valgrind fails to terminate (only kill > -9 helps)
This is a valgrind bug, I think. Here's what happens. When valgrind wants to attach a debugger, it doesn't attach it directly to the "real" process; instead it forks, and attaches the debugger to the fork. But you can't do this with a threaded application and expect to get something sensible. The in-process threading data still has the real PIDs of the threads, so GDB attaches to those. That leads to inconsistencies like this one: (gdb) bt #0 0x000000000040119f in philosopher (philosopher_data=0x349fe1a0) at philosopher.c:230 #1 0x0000000011c27b1c in start_thread (arg=<value optimized out>) at pthread_create.c:261 #2 0x0000000011f86c22 in clone () from /usr/lib/debug/libc.so.6 #3 0x0000000000000000 in ?? () (gdb) thread apply all bt 1 Thread 6 (Thread 312473952 (LWP 14609)): #0 0x0000000070029328 in ?? () (More stack frames follow...) Thread 5 (Thread 321915232 (LWP 14610)): #0 0x0000000070029328 in ?? () (More stack frames follow...) Thread 4 (Thread 330307936 (LWP 14611)): #0 0x0000000070029328 in ?? () (More stack frames follow...) Thread 3 (Thread 338700640 (LWP 14612)): #0 0x000000007005bdc4 in ?? () (More stack frames follow...) Thread 2 (Thread 347093344 (LWP 14613)): #0 0x0000000070029328 in ?? () (More stack frames follow...) Thread 1 (Thread 304076496 (LWP 14608)): #0 0x000000007005bdc4 in ?? () Huh, the current thread's backtrace doesn't match any of the listed threads... that's because the listed threads are the "real" valgrind, pid 14608 in this case. The detach assertion failure is the same. We look in the thread list for something with PID 14616 and TID 14616. We don't find it; 14616 is the "fake" thread that valgrind told us to attach to, the real thread has PID 14616 (because that's what we thought we were attaching to) and TID 14608. So we detach from six threads instead of five and can't find the last one. I could work around the assertion failure but gdb still won't see the state of the other threads. I think valgrind needs to rethink how this works if it wants gdb attach to handle threaded applications. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
