This is the mail archive of the gdb@sourceware.org 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: Strange address in the stack trace


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.


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