Bug 187789 - Wrong addresses calculated for local variables (64bit issue, -gstabs or -gstabs+)
Wrong addresses calculated for local variables (64bit issue, -gstabs or -gsta...
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Elena Zannoni
Depends On:
  Show dependency treegraph
Reported: 2006-04-03 12:50 EDT by Stefan Ring
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-10 20:13:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Very simple test program in C (83 bytes, text/plain)
2006-04-03 12:50 EDT, Stefan Ring
no flags Details

  None (edit)
Description Stefan Ring 2006-04-03 12:50:07 EDT
Description of problem:
When trying to look at local variables (or function parameters), gdb gives me
"Cannot access memory at address 0x<garbage><yyyyyyyy>", where <yyyyyyyy> would
be the correct address.

Version-Release number of selected component (if applicable):
GNU gdb Red Hat Linux (
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db
library "/lib64/libthread_db.so.1".

How reproducible:
Always when showing stack traces for programs built with -gstabs+ or -gstabs.

Steps to Reproduce:
1. Build the attached test program with "gcc -gstabs+ test.c"
2. gdb ./a.out
3. br a
4. r
Actual results:
Breakpoint 1, a (x=Cannot access memory at address 0x8000ffd85118
) at test.c:3

Expected results:
Breakpoint 1, a (x=<some address close to 0xffd85118>
) at test.c:3

Additional info:
The production case which bugs me looks like this (the value 0x00000001 in the
upper 32 bits):

#0  vtex_breakpoint () at VTXMLMessages/CLS_XMLMessages.cpp:268
#1  0x000000000066366b in VTException::VTException (this=Cannot access memory at
address 0x143202f28
) at VTXMLMessages/CLS_XMLMessages.cpp:445
#2  0x0000000000415869 in VTE_TP<AnsiString> (xc=Cannot access memory at address
) at VTCOM/../VTXMLMessages/CLS_XMLMessages.h:118
#3  0x000000000053478c in network_error () at VTCOM/CLS_VTCOMUnix.cpp:34
#4  0x0000000000536bdf in VTCOMUnixSocketAdaptor::next (this=Cannot access
memory at address 0x1432038b8
) at VTCOM/CLS_VTCOMUnix.cpp:121
#5  0x00000000005348fc in VTCOMUnixSocketAdaptor::ReceiveString (this=Cannot
access memory at address 0x143203948
) at VTCOM/CLS_VTCOMUnix.cpp:170
#6  0x000000000052fb5f in VTCOMMarshaller::ReadFromSocket (this=Cannot access
memory at address 0x1432039e8
) at VTCOM/CLS_VTCOM.cpp:218
#7  0x0000000000532dc9 in VTCOM::GetNextRequest (s=Cannot access memory at
address 0x143203ad8
) at VTCOM/CLS_VTCOMServer.cpp:136
#8  0x0000000000532ea2 in VTCOM::ServerRequestLoop (s=Cannot access memory at
address 0x143203b50
) at VTCOM/CLS_VTCOMServer.cpp:157
Comment 1 Stefan Ring 2006-04-03 12:50:07 EDT
Created attachment 127244 [details]
Very simple test program in C
Comment 2 Stefan Ring 2006-04-03 18:12:45 EDT
Apparently, SYMBOL_VALUE (var) contains a signed 32 bit value in
read_var_value() that has not been correctly expanded to long. I haven't been
able to find out where it originates from, however.
Comment 3 Stefan Ring 2006-04-06 05:30:56 EDT
Maybe it's a gcc problem and doesn't have anything to do with gdb at all because
it seems to work with gcc 3.4.
Comment 4 Andrew Cagney 2006-09-10 20:13:51 EDT
Stabs is not supported; one reason being 64-bit breakage in the non-existant
spec. Use DWARF 2/3, which is the default.

Note You need to log in before you can comment on or make changes to this bug.