This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: backtrace/1406: gdb 5.3/6.0 broken with valgrind --gdb-attach=yes (gdb refuses to display the stack frame)
- From: Mark Kettenis <kettenis at chello dot nl>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 6 Oct 2003 12:28:01 -0000
- Subject: Re: backtrace/1406: gdb 5.3/6.0 broken with valgrind --gdb-attach=yes (gdb refuses to display the stack frame)
- Reply-to: Mark Kettenis <kettenis at chello dot nl>
The following reply was made to PR backtrace/1406; it has been noted by GNATS.
From: Mark Kettenis <kettenis@chello.nl>
To: gdb-gnats@sources.redhat.com, nobody@sources.redhat.com,
pommier@gmm.insa-tlse.fr, gdb-prs@sources.redhat.com
Cc:
Subject: Re: backtrace/1406: gdb 5.3/6.0 broken with valgrind --gdb-attach=yes (gdb refuses to display the stack frame)
Date: Mon, 6 Oct 2003 14:26:37 +0200 (CEST)
Thanks for your bugreport.
As you probably realised, the duplicate frame check isn't the real
probelm here. If you look at the backtrace you provided:
(gdb) where
#0 vg_do_syscall3 (syscallno=4294966784, arg1=3161, arg2=0, arg3=0)
at vg_mylibc.c:92
#1 0x40191b7d in vgPlain_system (cmd=0xbffff040 "/usr/bin/gdb -nw /proc/3160/exe
3160") at vg_mylibc.c:1277
#2 0x4018d727 in
vgPlain_start_GDB_whilst_on_client_stack () at vg_main.c:1821
#3 0x40194e48 in vgPlain_swizzle_esp_then_start_GDB()
from /usr/lib/valgrind/valgrind.so
#4 0xbffff0d8 in ?? ()
#5 0x08048401 in coin () at k.c:5
Previous frame identical to this frame (corrupt stack?)
(gdb)
There's something rather suspicious about frame #4; I doubt that
you're really executing code on the stack. It's defenitely more
likely that GDB is unable to properly unwind frame #3. I took a quick
look at valgrind, and vgPlain_swizzle_esp_then_start_GDB() is
hand-coded assembler that fiddles with the stack. I'm not surprised
that GDB chockes on this, and teaching GDB to properly unwind this
particular frame is very difficult. It's properly a better idea to
ask the author of valgrind to add DWARF Call Frame Info (DWARF CFI) to
this particular bit of code.
Mark