CODEWITHSUNDEEP
cgdb
Ojs
Ojs

Reputation: 954

"Cannot access memory at address 0x208c" error

Disassembly code:

   0x0804844d <+0>:     push   %ebp
   0x0804844e <+1>:     mov    %esp,%ebp
   0x08048450 <+3>:     and    $0xfffffff0,%esp
   0x08048453 <+6>:     sub    $0x20,%esp
   0x08048456 <+9>:     movl   $0x8048540,(%esp)
   0x0804845d <+16>:    call   0x8048310 <puts@plt>
   0x08048462 <+21>:    lea    0x1c(%esp),%eax
   0x08048466 <+25>:    mov    %eax,0x4(%esp)
   0x0804846a <+29>:    movl   $0x8048555,(%esp)
   0x08048471 <+36>:    call   0x8048320 <scanf@plt>
   0x08048476 <+41>:    mov    0x1c(%esp),%eax
   0x0804847a <+45>:    cmp    $0x208c,%eax
   0x0804847f <+50>:    jne    0x804848f <main+66>
   0x08048481 <+52>:    movl   $0x8048558,(%esp)
   0x08048488 <+59>:    call   0x8048310 <puts@plt>
   0x0804848d <+64>:    jmp    0x804849b <main+78>
=> 0x0804848f <+66>:    movl   $0x8048569,(%esp)
   0x08048496 <+73>:    call   0x8048310 <puts@plt>
   0x0804849b <+78>:    mov    $0x0,%eax
   0x080484a0 <+83>:    leave  
   0x080484a1 <+84>:    ret

What I'm trying to examine is $0x208c. When I type x/xw 0x208c, it gives me back an error which says:

Cannot access memory at address 0x208c.

When I type Info registers and look at eax, it says the value which I provided.

So basically, this program compares two values, and depending on that, it prints something out.

Upvotes: 25

Views: 160383

Answers (5)

Suresh Babu
Suresh Babu

Reputation: 17

If GDB says memory address not found, that means the symbol is not available in the executable file opened by GDB, or through file exefilename.

Or, you have not compiled the exefile with -g option. What happens when you are a newbie for GDB you may have given the command file argfile instead of run argfile.

Upvotes: 1

Jacek Tomaka
Jacek Tomaka

Reputation: 432

In my case the problem was caused by calling munmap with length bigger than mmap: 

#include <errno.h>
#include <sys/mman.h>
#include <stdio.h>
#include <string.h>
int main(){
    size_t length_alloc = 10354688;
    size_t length_unmap = 5917171456;
    void *v = mmap(0, 10354688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); 
    if (v == MAP_FAILED) {
            printf("mmap of %lu bytes failed with error: %s", 10354688, strerror(errno));
    }else{
            printf("mmaped %p\n", v); 
            munmap(v, length_unmap);
    }   

}

So the unmap unmapped also mappings for stacks of a few threads. Pretty nasty one because it rendered the core dump impossible to use with my current skill level. Especially that in the original problem, the size passed to munmap was somewhat random. And it crashed only sometimes and the end of a very lengthy process.

Upvotes: 1

Ciro Santilli OurBigBook.com
Ciro Santilli OurBigBook.com

Reputation: 384124

Uninitialized pointers

It is kind of obvious in retrospective, but this is what was causing GDB to show that error message to me. Along:

#include <stdio.h>

int main(void) {
    int *p;
    printf("*p = %d\n", *p);
}

And then:

gdb -q -nh -ex run ./tmp.out
Reading symbols from ./tmp.out...done.
Starting program: /home/ciro/bak/git/cpp-cheat/gdb/tmp.out 

Program received signal SIGSEGV, Segmentation fault.
0x0000555555554656 in main () at tmp.c:5
5           printf("*p = %d\n", *p);
(gdb) print *p
Cannot access memory at address 0x0

But in a complex program of course, and where the address was something random different from zero.

Upvotes: 1

user7610
user7610

Reputation: 28879

I found out that it is impossible to examine mmaped memory that does not have PROT_READ flag. This is not the OPs problem, but it was mine, and the error message is the same.

Instead of

mmap(0, size, PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);

do

mmap(0, size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);

and voila, the memory can be examined.

Upvotes: 9

Employed Russian
Employed Russian

Reputation: 213877

When I type x/xw 0x208c it gives me back error which says Cannot access memory at address 0x208c

The disassembly for your program says that it does something like this:

puts("some string");
int i;
scanf("%d", &i);  // I don't know what the actual format string is.
                  // You can find out with x/s 0x8048555
if (i == 0x208c) { ... } else { ... }

In other words, the 0x208c is a value (8332) that your program has hard-coded in it, and is not a pointer. Therefore, GDB is entirely correct in telling you that if you interpret 0x208c as a pointer, that pointer does not point to readable memory.

i finally figured out to use print statement instead of x/xw

You appear to not understand the difference between print and examine commands. Consider this example:

int foo = 42;
int *pfoo = &foo;

With above, print pfoo will give you the address of foo, and x pfoo will give you the value stored at that address (i.e. the value of foo).

Upvotes: 29

Related Questions