This is the mail archive of the gdb-prs@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: backtrace/1437: gdb fails to print backtrace: Cannot access memory at address 0xbf800000 in Linux/gcc/C


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]