Debugging help - Heap Corruption.
Hello,
My project has been working fine all day, but after some 'non-critical' changes, I suddenly get a Debug error, saying "HEAP CORRUPTION DETECTED: after Normal Block #<number> at <address>. CRT detected that the application wrote to memory after end of heap buffer."
I don't know which code snippets I could provide as info, as I simply don't know what could be causing this error, nor do I know where to begin looking.
Apparently, the error appears during the (automatic) deallocation process: I have a manual breakpoint on the "return 0" of my main. The error appears when I continue from that breakpoint.
The top-level structure of my program is this:
-Read in data from a file and create a bunch of objects in a valarray<Class>. This valarray is a member of a class ("DATA") that is only created once.
-Using the read-in data, create a (self-made) binary heap of pointers to the Objects stored in "DATA".
-Perform several actions on the Heap; this swaps Pointers around and changes a value in the Objects the pointers point to, but doesn't move them.
Some guarantees:
-The valarray of objects is never changed; the only changes to the Objects are when their key or index (both ints) are changed. No objects are ever removed, added or changed once the data has been read in.
-Pointers are gotten by
-The final function before the return prints the entire heap and there don't seem to be any access errors, nor any bogus numbers (I'm using a narrow range of test numbers so I can easily spot "fauly randoms"), which suggests that both the pointer valarray and the object valarray are correct.
-All class destructors are the standard ones, because I'm not using any dynamically allocated variables. Every member is either a regular type, a (null) pointer or a valarray (which takes care of its own memory?).
Anyone know what the problem could be?
My project has been working fine all day, but after some 'non-critical' changes, I suddenly get a Debug error, saying "HEAP CORRUPTION DETECTED: after Normal Block #<number> at <address>. CRT detected that the application wrote to memory after end of heap buffer."
I don't know which code snippets I could provide as info, as I simply don't know what could be causing this error, nor do I know where to begin looking.
Apparently, the error appears during the (automatic) deallocation process: I have a manual breakpoint on the "return 0" of my main. The error appears when I continue from that breakpoint.
The top-level structure of my program is this:
-Read in data from a file and create a bunch of objects in a valarray<Class>. This valarray is a member of a class ("DATA") that is only created once.
-Using the read-in data, create a (self-made) binary heap of pointers to the Objects stored in "DATA".
-Perform several actions on the Heap; this swaps Pointers around and changes a value in the Objects the pointers point to, but doesn't move them.
Some guarantees:
-The valarray of objects is never changed; the only changes to the Objects are when their key or index (both ints) are changed. No objects are ever removed, added or changed once the data has been read in.
-Pointers are gotten by
&DATA.nodes[i], as direct addresses of the valarray slot.-The final function before the return prints the entire heap and there don't seem to be any access errors, nor any bogus numbers (I'm using a narrow range of test numbers so I can easily spot "fauly randoms"), which suggests that both the pointer valarray and the object valarray are correct.
-All class destructors are the standard ones, because I'm not using any dynamically allocated variables. Every member is either a regular type, a (null) pointer or a valarray (which takes care of its own memory?).
Anyone know what the problem could be?
Last edited on
This kind of heap corruption is usually caused by you stepping out of bounds of an array.
ie:
The code likely won't cause the crash immediately -- but instead you'll see what you're seeing now -- it is being discovered when the heap's integrity is checked before shutdown (note: this only happens if you're lucky. If you're unlucky you don't get any warning at all and the heap corruption could make your program do VERY WEIRD things).
One thing you can do is use the address it gives you in the error message as a clue. If you can find which array/variable has an address that is relatively close to the address in the error message, that's probably the array you're stepping out of bounds on.
ie:
|
|
The code likely won't cause the crash immediately -- but instead you'll see what you're seeing now -- it is being discovered when the heap's integrity is checked before shutdown (note: this only happens if you're lucky. If you're unlucky you don't get any warning at all and the heap corruption could make your program do VERY WEIRD things).
One thing you can do is use the address it gives you in the error message as a clue. If you can find which array/variable has an address that is relatively close to the address in the error message, that's probably the array you're stepping out of bounds on.
A common source of heap corruption is mismatched new & delete, although "I'm not using any dynamically allocated variables" would suggest that isn't the case here.
If you can build under *nix, valgrind will probably identify the line causing the problem.
If you can build under *nix, valgrind will probably identify the line causing the problem.
Last edited on
Apparently my post didn't come through after I marked it as solved.
The problem was, indeed, me forgetting to add a spare slot in the valarray initialization (if the index can serve as ID, I use a spare slot so I can work in [1,N] and use the 0 slot as temp variable for swapping etc.). I excluded this option because I (wrongfully) assumed valarrays did bounds-checking using asserts, the way vectors do.
So, all is right again with the world. Thanks for the quick replies nonetheless!
The problem was, indeed, me forgetting to add a spare slot in the valarray initialization (if the index can serve as ID, I use a spare slot so I can work in [1,N] and use the 0 slot as temp variable for swapping etc.). I excluded this option because I (wrongfully) assumed valarrays did bounds-checking using asserts, the way vectors do.
So, all is right again with the world. Thanks for the quick replies nonetheless!
Topic archived. No new replies allowed.