This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: attach.exp failure
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: carlton at kealia dot com, gdb at sources dot redhat dot com
- Date: Tue, 5 Aug 2003 13:21:33 -0400
- Subject: Re: attach.exp failure
Well now that's interesting.
attach 1065
Attaching to program: /gdb/mirror/src/gdb/testsuite/gdb.base/attach2, process 1065
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x420b0205 in nanosleep () from /lib/i686/libc.so.6
(gdb) PASS: gdb.base/attach.exp: attach call
i r r3
ERROR: Couldn't send p should_exit = 1 to GDB.
UNRESOLVED: gdb.base/attach.exp: p should_exit = 1
ERROR: Couldn't send c to GDB.
UNRESOLVED: gdb.base/attach.exp: c
Looks like gdb crashed or went into a loop. Probably crashed because
if it went into a loop, the test would take some long $TIMEOUT time
to run. Are there any funky core files lying around?
The target program is inside nanosleep, probably called from sleep, and
I know that gdb screws up the frame info when it backtraces through
sleep.
But I have never gotten this behavior. The connection between
'nanosleep' and a crash is just too tenuous. Your problem has the
word 'nanosleep' in it but I just don't see a smoking gun linking
it to the 'sleep' frame info problem. :(
What vendor/version of linux are you running on?
Can you disassemble 'sleep' from libc.so and post the first few
instructions?
Want to try this patch?
http://sources.redhat.com/ml/gdb-patches/2003-08/msg00053.html