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 0x0040119f in philosopher (philosopher_data=0x349fe1a0) at
philosopher.c:230
#1 0x11c27b1c in start_thread (arg=value optimized out) at
pthread_create.c:261
#2 0x11f86c22 in clone () from /usr/lib/debug/libc.so.6
#3 0x in ?? ()
(gdb) thread apply all bt 1
Thread 6 (Thread 312473952 (LWP 14609)):
#0 0x70029328 in ?? ()
(More stack frames follow...)
Thread 5 (Thread 321915232 (LWP 14610)):
#0 0x70029328 in ?? ()
(More stack frames follow...)
Thread 4 (Thread 330307936 (LWP 14611)):
#0 0x70029328 in ?? ()
(More stack frames follow...)
Thread 3 (Thread 338700640 (LWP 14612)):
#0 0x7005bdc4 in ?? ()
(More stack frames follow...)
Thread 2 (Thread 347093344 (LWP 14613)):
#0 0x70029328 in ?? ()
(More stack frames follow...)
Thread 1 (Thread 304076496 (LWP 14608)):
#0 0x7005bdc4 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]
