Debugging a memory error with GDB and C++

Question

I'm running my C++ program in gdb. I'm not real experienced with gdb, but I'm getting messages like:

warning: HEAP[test.exe]:
warning: Heap block at 064EA560 modified at 064EA569 past requested size of 1

How can I track down where this is happening at? Viewing the memory doesn't give me any clues.

Thanks!

Answer 1

So you're busting your heap. Here's a nice GDB tutorial to keep in mind:

http://www.cs.princeton.edu/~benjasik/gdb/gdbtut.html

My normal practice is to set a break in known good part of the code. Once it gets there step through until you error out. Normally you can determine the problem that way.

Because you're getting a heap error I'd assume it has to do with something you're putting on the heap so pay special attention to variables (I think you can use print in GDB to determine it's memory address and that may be able to sync you with where your erroring out). You should also remember that entering functions and returning from functions play with the heap so they may be where your problem lies (especially if you messed your heap before returning from a function).

Answer 2

You can probably use a feature called a "watch point". This is like a break point but the debugger stops when the memory is modified.

I gave a rough idea on how to use this in an answer to a different question.

Answer 3

If you can use other tools, I highly recommend trying out Valgrind. It is an instrumentation framework, that can run your code in a manner that allows it to, typically, stop at the exact instruction that causes the error. Heap errors are usually easy to find, this way.

Answer 4

One thing you can try, as this is the same sort of thing as the standard libc, with the MALLOC_CHECK_ envronment variable configured (man libc).

If you keep from exiting gdb (if your application quit's, just use "r" to re-run it), you can setup a memory breakpoint at that address, "hbreak 0x64EA569", also use "help hbreak" to configure condition's or other breakpoitn enable/disable options to prevent excessively entering that breakpoint....

You can just configure a log file, set log ... setup a stack trace on every break, "display/bt -4", then hit r, and just hold down the enter key and let it scroll by "or use c ## to continue x times... etc..", eventually you will see that same assertion, then you will now have (due to the display/bt) a stacktrace which you can corolate to what code was modifying on that address...