|
From: Chris S. <c.s...@co...> - 2005-01-11 21:22:11
|
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
|
|
From: Chris S. <c.s...@co...> - 2005-01-11 21:57:14
|
On Tue, Jan 11, 2005 at 04:22:39PM -0500, Chris Shoemaker wrote: > > Now: perhaps I'm doing something dumb, but is there some way I can > preserve stack frame info when I attach gdb? <snip self> > > [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". After doing a bit more testing, I discovered that changing gdb versions makes a difference. gdb that came with FC1, gdb-5.3.90-0.20030710.41.i386.rpm, shows stack info. gdb that came with FC2, gdb-6.0post-0.20040223.19.i386.rpm, DOESN'T. and neither does the more recent, (6.1post-1.20040607.43rh) However, on a debian box, (gdb 6.1-debian), has no problem. I guess I should find the gdb mailing list, huh? -chris |
|
From: Chris S. <c.s...@co...> - 2005-01-12 14:52:10
|
On Tue, Jan 11, 2005 at 04:57:40PM -0500, Chris Shoemaker wrote: > On Tue, Jan 11, 2005 at 04:22:39PM -0500, Chris Shoemaker wrote: > > > > Now: perhaps I'm doing something dumb, but is there some way I can > > preserve stack frame info when I attach gdb? > <snip self> > > > > [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". > > After doing a bit more testing, I discovered that changing gdb versions makes a difference. > gdb that came with FC1, gdb-5.3.90-0.20030710.41.i386.rpm, shows stack info. > gdb that came with FC2, gdb-6.0post-0.20040223.19.i386.rpm, DOESN'T. > and neither does the more recent, (6.1post-1.20040607.43rh) > > However, on a debian box, (gdb 6.1-debian), has no problem. I guess I > should find the gdb mailing list, huh? I don't know what's special about gdb 6.1-debian, but a stock gdb 6.3 also fixes this problem. Sorry for the noise. -chris |
|
From: Olly B. <ol...@su...> - 2005-01-12 16:06:07
|
On 2005-01-12, Chris Shoemaker <c.s...@co...> wrote:
> I don't know what's special about gdb 6.1-debian, but a stock gdb 6.3
> also fixes this problem. Sorry for the noise.
Debian often patch software when packaging, to fix bugs which haven't
been fixed in an upstream release yet, or backporting important fixes
(most notably security fixes) to versions of the software in the stable
distribution.
So if you look in the debian patches for gdb 6.1, you'll probably find
a patch to fix this problem, which was either backported from 6.2 or
6.3, or has been submitted upstream and included in 6.2 or 6.3.
Cheers,
Olly
|