[Valgrind-users] stack frames garbage after gdb attach

[Chris S. <c.s...@co...>]

First off: I _love_ valgrind.  This is an amazingly ambitious piece of
software and it is incredibly useful and useable.  My thanks to the developer(s)!

Now: perhaps I'm doing something dumb, but is there some way I can
preserve stack frame info when I attach gdb?

For example:
[chris@badger2 test]$ cat a.c
int main (int argc, char ** argv)
{
  free((void *) 0xbadbad);
  return 0;
}
[chris@badger2 test]$ gcc -o a.out a.c
[chris@badger2 test]$ gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/3.4.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-java-awt=gtk --host=i386-redhat-linux
Thread model: posix
gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)

[I've tried this with gcc 3.3, too, with same results.]

[chris@badger2 test]$ gdb a.out
GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) r
Starting program: /home/chris/gnucash/gnucash/src/gnome-utils/test/a.out
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0xf6f0eab9 in free () from /lib/tls/libc.so.6
(gdb) bt
#0  0xf6f0eab9 in free () from /lib/tls/libc.so.6
#1  0x08048391 in main ()
(gdb) q
The program is running.  Exit anyway? (y or n) y

[Obviously, the symbols are there.]

[chris@badger2 test]$ valgrind --tool=none --db-attach=yes a.out
==23865== Nulgrind, a binary JIT-compiler for x86-linux.
==23865== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote.
==23865== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==23865== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==23865== For more details, rerun with: -v
==23865==
==23865==
==23865== Process terminating with default action of signal 11 (SIGSEGV)
==23865==  Access not within mapped region at address 0xBADBA9
==23865==    at 0x3A9F6AB9: free (in /lib/tls/libc-2.3.4.so)
==23865==    by 0x8048390: main (in /home/chris/gnucash/gnucash/src/gnome-utils/test/a.out)
==23865==

[ I notice that symbol name and locations are good.  Curious about 0xBADBA9 vs. 0xbadbad. ]

==23865== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==23865== starting debugger with cmd: /usr/bin/gdb -nw /proc/23867/fd/821 23867
GNU gdb Red Hat Linux (6.1post-1.20040607.43rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /proc/23867/fd/821, process 23867
0x3a9f6ab9 in ?? ()
(gdb) bt
#0  0x3a9f6ab9 in ?? ()
#1  0x3a970a80 in ?? ()
#2  0x3aabd15c in ?? ()
#3  0x3aabaff4 in ?? ()
#4  0xafefe9b4 in ?? ()
#5  0xafefe940 in ?? ()
#6  0xafefe928 in ?? ()
#7  0x08048391 in main ()

[ very unhelpful, even main() is off-by-one, no? ]

(gdb) q
The program is running.  Quit anyway (and detach it)? (y or n) y
Detaching from program: /proc/23867/fd/821, process 23867
==23865==
==23865== Debugger has detached.  Valgrind regains control.  We continue.
==23865==
Segmentation fault
[chris@badger2 test]$ valgrind --version
valgrind-2.2.0


[If this is a bug in valgrind, I'm willing to test patches, although,
my setup is probably reproducible, (FedoraCore3)]

-chris