I have a small Q about heap corruption: I'm quite sure i have a heap corruption somewhere in my code and i thought std::bad_alloc is always thrown right at the next memory allocation. is that right? or is it possible that the std::bad_alloc is thrown at the second,third or twentieth allocation ? If that's the case, how do you debug an error like this? regards, m4gnus [Edited by - m4gnus on March 12, 2006 3:47:02 AM]

As far as I am aware, the standard does not specify that bad_alloc is to be thrown in the event of detected heap corruption. (Although it does get thrown in some occasionally hard-to-predict situations.) More importantly, if your heap corruption is only corrupting already-allocated memory, it is impossible to detect in code.

Most tools have a way to catch corruption errors, although they are often slow and tedious to use. What compiler and debugger are you using?

(For general techniques, try the "binary chop" - find a point in code where you know no corruption has occured, and find a point where you know it has. This might be the very beginning and very end of the program. Then, pick a point between those two, and terminate the program at that point. If you have corruption, the error is in the first half of the code. If not, it's in the second (or is just particularly spiteful and nasty). Continue splitting the code to try and narrow down the corruption to a specific set of events, and you should have a fairly clear idea of where the bug is. Blend with liberal use of debug logging for best results.

i'm using Visual Studio .net 2003.

Quote:
Then, pick a point between those two, and terminate the program at that point. If you have corruption, the error is in the first half of the code.

and how do i know that there is a heap corruption?

the only thing i know is the point where the bad_alloc exception is thrown(vector.resize())

regards,
m4gnus

really? i thought 'new' throws std::bad_alloc either if there's no free memory or if the heap is corrupted

regards,
m4gnus

Check out the link I posted earlier - it demonstrates a case where an allocation throws that you may not expect, even though there is no lack of room in the free store. You may be a victim of such a case.

If all else fails, post the code and indicate where the exception is thrown, and if the code has run multiple iterations before it gets thrown.

Quote:
Check out the link I posted earlier - it demonstrates a case where an allocation throws that you may not expect, even though there is no lack of room in the free store. You may be a victim of such a case.

i don't think that something like that is the problem. The bad_alloc get's thrown on vector.resize();

the code:


btw adjacentFaces is 1542 elements big and vertexindex is 260

regards,
m4gnus

Like where in C++ is the behaviour of something you're never supposed to do (corrupt the heap) ever well-defined?

I'd start by adding asserts whereever I use an array, to make sure that it isn't writing out-of-bounds.

The best place to start is to print out the value of adjacentFaces[vertexindex].size() before calling resize() to make sure it is a sane number.


You've marked this thread as "solved" but not mentioned how or why; would you mind posting your solution for the benefit of anyone else who happens to find this thread with a similar problem?

i thought it was quite a stupid error and no one would do such a mistake but me ...

i had a for-loop somewhere else in my code and it should run from i=0 to someVector.size() with i=i+3 but in the loop i did bla1=someVector;, bla2=someVector[i+1] and bla3=someVector[i+2] which resulted in heap corruption. I fixed it by replacing the +'s with -'s

regards,
m4gnus