In the call stack, what does it indicate when the argument of type pointer holds address of pattern 0x8080808080808080 or 0xf8f8f8f8f8f8f8f8?

user_5347487 0
Viewed 118

When i was debugging an issue using GDB, i came across this weird behavior. For which i could not convince myself with any logical answer.

Below is the snapshot of the call stack obtained because of the breakpoint at the beginning of the function (I am restricting the stack frame to 3 level for simplicity).

(gdb) 
#0  hashset_get (hashset=<value optimized out>, item_key=0x7fffd7e4f5b8)
    at /xxx/yyy/zzz/hashset.c:123
#1  0x00007fffed855d00 in hashmap_get (hashmap=<value optimized out>, key=0x7fffd7e4f648)
    at /xxx/yyy/zzz/hashmap.c:789
#2  0x00007ffa589d8eeb in hashmap_get_value (hashmap=0x7ff9d82d1b78, key=0x7fffd7e4f648)
    at /xxx/yyy/zzz/hashmap.c:456

After this there is one single-step execution. Later to which stack frame looked as below-

    (gdb) bt
#0  hashset_get (hashset=0xf8f8f8f8f8f8f8f8, item_key=0x7fffd7e4f5b8)
    at /xxx/yyy/zzz/hashset.c:125
#1  0x00007fffed855d00 in hashmap_get (hashmap=<value optimized out>, key=0x7fffd7e4f648)
    at /xxx/yyy/zzz/hashmap.c:789
#2  0x00007ffa589d8eeb in hashmap_get_value (hashmap=0x7ff9d82d1b78, key=0x7fffd7e4f648)
    at /xxx/yyy/zzz/hashmap.c:456

I know that when the GDB shows any variable as "value optimized out", it indicates that its value is stored in register instead of storing on the stack frame.

However, in this case, the arg hashset which was initially shown as "value optimized out" is later changed to some address location - 0xf8f8f8f8f8f8f8f8. So does that mean initially it has stored the hashset in register then created a space on the stack frame?

And this address doesn't looks like any other memory location address. You could see some pattern in the address (like f8f8...)

To add more confusion to the fact, if I try to print the data at that location, GDB outputs as below-

(gdb) p *hashset
Cannot access memory at address 0xf8f8f8f8f8f8f8f8

Some more things i tried in a hope that it could help in understand this behavior.

I assigned a valid address 0x7fffd7e4f5b8 - which is held by the arg item_key, to hashset

(gdb) s hashset=0x7fffd7e4f5b8
(gdb) p *hashset
Cannot access memory at address 0xb8b8b8b8b8b8b8b8
(gdb) p hashset
$6 = (hashset) 0xb8b8b8b8b8b8b8b8

But to my surprise, when I print the value of hashset, it is showing the address as 0xb8b8b8b8b8b8b8b8 instead of 0x7fffd7e4f5b8!!

Could someone please explain what is happening here?

[Edit: There is NO crash/hang. System is operational, normally]

gdb c debugging
1 Answers

I know that when the GDB shows any variable as "value optimized out", it indicates that its value is stored in register instead of storing on the stack frame.

That isn't what "value optimized out" means.

It means: the compiler didn't provide location information for this variable at the current program counter.

In theory, DWARF standard is rich enough that it can describe things like "this variable can be located by adding constant to value of register", or "by adding register A and register B and ORing the result with contents of location pointed by register C". In practice, few compilers go to such length, and instead simply omit the info.

However, in this case, the arg hashset which was initially shown as "value optimized out" is later changed to some address location

When you advanced the program counter, GDB found location information at the new PC. But interpreting that location information resulted in value 0xf8f8f8f8f8f8f8f8, which can't be true value of a pointer on x86_64.

From this you can conclude that either the location information is incorrect (a compiler bug; most likely) or that GDB didn't correctly interpret the DWARF description (not unheard of).

Unfortunately, such debugging artifacts are a fact of life when debugging optimized code. They are also dependent on exact versions of GCC and GDB -- newer versions are often (but not always!) better. Clang/LLVM is currently quite poor and produces "value optimized out" much more often than it should.

Employed_Russian_506170
Related