This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: backtrace/1437: gdb fails to print backtrace: Cannot access memory at address 0xbf800000 in Linux/gcc/C
- From: "Burckhardt, Jacob, CTR" <Jacob dot Burckhardt-contractor at jntf dot osd dot mil>
- To: kettenis at gnu dot org
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 6 Jan 2004 16:18:00 -0000
- Subject: Re: backtrace/1437: gdb fails to print backtrace: Cannot access memory at address 0xbf800000 in Linux/gcc/C
- Reply-to: "Burckhardt, Jacob, CTR" <Jacob dot Burckhardt-contractor at jntf dot osd dot mil>
The following reply was made to PR backtrace/1437; it has been noted by GNATS.
From: "Burckhardt, Jacob, CTR" <Jacob.Burckhardt-contractor@jntf.osd.mil>
To: gdb-gnats@sources.redhat.com, bjacob@ca.metsci.com, kettenis@gnu.org,
gdb-prs@sources.redhat.com
Cc:
Subject: Re: backtrace/1437: gdb fails to print backtrace: Cannot access m
emory at address 0xbf800000 in Linux/gcc/C
Date: Tue, 6 Jan 2004 09:15:26 -0700
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&databas
e=gdb&pr=1437
I guess another example would be if a program wrote to an invalid pointer
and the pointer happened to point to the memory where it recorded the call
stack information. I guess it is unreasonable of me to expect that gdb can
give a call stack even when my program's bug destroys the record of that
call stack. Maybe gdb is not the right tool for such a case. Maybe the
right tool would be a memory error checking tool like Valgrind
(http://valgrind.kde.org).
So anyway, I agree it is not a gdb bug.