Geek Answers Handbook

Debugging a memory error using GDB and C ++

I am running my C ++ program in gdb. I am not very good at gdb, but I get messages like:

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

How can I track where this is happening? Looking at the memory does not give me any clues.

Thanks!

+4
source share
5 answers

So you are destroying your heap. Here's a good GDB tutorial to keep in mind.

My normal practice is to set a break in a known good piece of code. As soon as he gets there until an error comes out. You can usually identify the problem this way.

Since you are getting a heap error, I would suggest that it is related to what you put in the heap, so pay special attention to the variables (I think you can use printing in GDB to determine its memory address and may be able to synchronize you with where you are wrong). You should also remember that entering functions and returning from functions are reproduced with a bunch, so they may be where your problem is (especially if you mixed up your bunch before returning from a function).

+4
source

Perhaps you can use a function called the "observation point". It looks like a breakpoint, but the debugger stops when the memory changes.

I gave a general idea of ​​how to use this in answering another question.

+1
source

If you can use other tools, I highly recommend trying Valgrind . This is an instrumental structure that can run your code in such a way that, as a rule, it stops at the exact instruction that causes the error. Thus, heap errors are usually easy to find.

+1
source

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

If you cannot exit gdb (if your application is finished, just use "r" to restart), you can set a memory breakpoint at this address "hbreak 0x64EA569", also use "help hbreak" to configure the condition or other breakpoitn options enable / disable to prevent excessive entry of this breakpoint ....

You can simply configure the log file, set the log ... configure the stack trace at each break, "display / bt -4", then press r and just hold the enter key and scroll it "or use C ## to continue x times .. ., etc. ", in the end you will see the same statement, then you will now have (due to the / bt display) a stack that you can associate with what code was changing at this address ...

+1
source

I had a similar problem when I tried to reassign an array of pointers to my structures, but instead I was redistributed as an array of ints (because I got the code from the tutorial and forgot to change it). The compiler did not fix me because it could not be checked in the size argument. My variable is:

itemsetList_t ** iteration_isets;

So in realloc instead

iteration_isets = realloc(iteration_isets, sizeof(itemsetList_t *) * max_elem);

I have had:

iteration_isets = realloc(iteration_isets, sizeof(int) * max_elem);

And that caused my heap problem.

0
source

More articles:


All Articles