This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Strange address in the stack trace
- From: Doug Evans <dje at google dot com>
- To: santoshp <santosh dot pradhan at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Tue, 13 Nov 2012 12:34:53 -0800
- Subject: Re: Strange address in the stack trace
- References: <1352454420562-212534.post@n7.nabble.com>
On Fri, Nov 9, 2012 at 1:47 AM, santoshp <santosh.pradhan@gmail.com> wrote:
> Hi All,While debugging a crash dump using GDB (7.2) on RHEL-5, one address
> looks strange to me. i.e. valueChanges variable. The same variable getting
> passed to frames but shows different addresses in different frames. #1
> 0x00002aaaab8a163a in MR_AnyVal (this=0x2aaab9000020, *o=@0x52*) at
> repos/mr/anyvali.c:36#2 0x00002aaaabb0fa13 in
> MR_MonitoringSystem::valueChanges2monValueChanges
> (*valueChanges=@0x465a5700*) at repos/mr/MR_MonitoredValue.h:61#3
> 0x00002aaaabb1065b in MR_MonitoringSystem::processChangesStandard
> (*valueChanges=@0x465a5700*) at repos/mr/MR_MonitoringSystem.c:280#4
> 0x00002aaaabbb026c in MR_Accessor::notify (this=, *valueChanges=@0x52*) at
> repos/accessors/MR_Accessor.c:1573Can somebody please comment on this
> whether this is from OS (because it's optimized build) or the behavior from
> GDB?Thanks,Santosh
Hi. Sounds like this is just the effect of debugging optimized code.
GDB can only print a value as the debug info specifies, and when
debugging optimized code often the debug info is inaccurate. GIGO.