CODEWITHSUNDEEP
c++assemblymemorygdb
user3520616
user3520616

Reputation: 81

gdb cannot access memory at value-type variable

When trying to debug a core thrown by a seg-fault, the line it crashes doesn't really make sense in my eyes; there are two integers compared and the result is stored in a bool. This is the not simplified code:

bool doLog = level >= debugLevel;

This is the assembly-code where it crashes:

cmp    %ebx,0x14(%rbp)
  // ebx = 3
  // rbp = 0x6e696c7265

However when trying to print the value of the address stored in rbp I get a gdb error: "cannot access memory at address 0x6e696c7279"

What bugs me is that when printing the address of debugLevel I'll get a different address then what is stored in the rbp register used for cmp:

p &debugLevel => 0x6e696c7279
i r rbp       => 0x6e696c7265

Upvotes: 1

Views: 1067

Answers (1)

Peter Cordes
Peter Cordes

Reputation: 363980

0x6e696c7265 looks like ASCII codes for letters. You probably overwrote a pointer with string bytes.

(e.g. maybe a buffer overflow stepped on a saved RBP value, and then the function returned to its caller after restoring RBP, breaking access to locals when the caller tries to use RBP as a frame pointer. Actually, RBP+14 wouldn't be a frame pointer, unless maybe this is on Windows and the compiler allocated that local in the shadow space above the return address.)

printing the address of debugLevel I'll get a different address then what is stored in the rbp register used for cmp

GDB knows from debug info that &debugLevel = RBP+0x14.

That's why the cmp instruction uses an addressing mode with a displacement of 0x14, specifically 0x14(%rbp). So of calculating &debugLevel from a corrupted base address will give you another bad address.

0x6e696c7279 - 0x6e696c7265 = 0x14 = 20. This part is not interesting or related to your memory-corruption bug.

Upvotes: 1

Related Questions