gnu gdb malloc return inaccessible pointer

Question

malloc in gdb debug session returns inaccessible address after running some codes.

first break at the start of main function. everything is ok.

Breakpoint 9, main (argc=5, argv=0x7fffffffe418) at src/ose/sdv/ose_sdv/linux/main.c:557
557     char *cfgfile = NULL;
(gdb) call malloc(4)
$50 = 23293968
(gdb) x 23293968
0x1637010:  0x00000000
(gdb) c

after running some lines it begins to return inaccessible memory address which is start at 0xffffffff~

Program received signal SIGINT, Interrupt.0x00007ffff70c1f4d in read () from /lib64/libc.so.6
(gdb) call malloc(4)
$52 = -1811110576
(gdb) x -1811110576
0xffffffff940ca550: Cannot access memory at address 0xffffffff940ca550

i'm using a 64bit linux os.

i cannot find the exact line of code that causes this.

The line after which malloc begins to like this is always change.

No exception occurred during runtime and the program runs as expected. I am not sure what is wrong here.

I find really strange that people so easily believe that "there is no bug in their program"... Do you have a formal proof of that pretentious assertion? — Basile Starynkevitch, May 25 '13 at 06:55
@BasileStarynkevitch To prove that take long pages and it is not an important point here.Because the behavior of gdb is what I want to ask.Even if my program have bugs,gdb should works fine to help me debugging. They are different processes. — oyss, May 25 '13 at 07:18
But when you do `call malloc(4)` under `gdb` the `malloc` is running in your buggy process, and you have messed up `malloc` internal data to the point of making it crash or return some faulty address... The *bug is yours* not inside `malloc` or `gdb` — Basile Starynkevitch, May 25 '13 at 07:19
And if you cannot prove that your program is correct you should presume it is buggy.... (please put the suspicion first on your own code, not on the system, or `malloc`, or `gdb`) — Basile Starynkevitch, May 25 '13 at 07:50

Basile Starynkevitch · Answer 1 · 2013-05-25T07:21:19.333

There are bugs in your program. Bugs in C++ don't always give exceptions, and C has no notion of exceptions. Read about undefined behavior.

When typing call malloc(4) under gdb you ask gdb to call malloc inside your buggy process.

The reason why malloc (or new) may give different addresses from one run to the next is ASLR. You could disable ASLR if you wanted to by

 echo 0 > /proc/sys/kernel/randomize_va_space

You should compile with gcc -Wall -g and use gdb as a debugger (perhaps the watch command of gdb could be useful).

What might have happened is that you wrongly overwrote some word outside a heap malloc-ed memory zone, or got a buffer overflow, or used an uninitialized variable, etc...

^{A good way to mess malloc really badly is to write before some malloc-ed zone like int *p = malloc(4); p[-1]=1234; then future free and malloc could exhibit very weird behavior...}

And you should use valgrind to hunt your memory bugs. Try running

valgrind yourprogram your-program-arguments ....

With a recent GCC (i.e 4.8) you could also try compiling and linking with -fsanitize=address option (in addition to -Wall -g)

gnu gdb malloc return inaccessible pointer

1 Answers1

Linked