Sign in to follow this  
m4gnus

heap corruption[solved]

Recommended Posts

m4gnus    240
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]

Share this post


Link to post
Share on other sites
ApochPiQ    23061
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.

Share this post


Link to post
Share on other sites
m4gnus    240
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

Share this post


Link to post
Share on other sites
Nitage    1107
bad_alloc doesn't indicate heap corruption.

What parameter are you passing to resize and what type is your vector holding?

Share this post


Link to post
Share on other sites
m4gnus    240
really? i thought 'new' throws std::bad_alloc either if there's no free memory or if the heap is corrupted

regards,
m4gnus

Share this post


Link to post
Share on other sites
ApochPiQ    23061
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.

Share this post


Link to post
Share on other sites
m4gnus    240
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:


std::vector<ngTriangle> getAdjacentFaces(short vertexindex)
{
int sz=adjacentFaces.size();
int fsz=faces.size();
int i=0;
int index=0;
std::vector<ngTriangle> res;
int size=adjacentFaces[vertexindex].size();

try
{
res.resize(adjacentFaces[vertexindex].size()); //std::bad_alloc exception!!
}catch(std::bad_alloc)
{

}


std::vector<int> adjFaces=adjacentFaces.at(vertexindex);
for(std::vector<int>::iterator it=adjFaces.begin();it!=adjFaces.end();++it)
{

index=*it;
res[i]=faces[index];
i++;
}

return res;
}



btw adjacentFaces is 1542 elements big and vertexindex is 260

regards,
m4gnus

Share this post


Link to post
Share on other sites
iMalc    2466
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.

Share this post


Link to post
Share on other sites
ApochPiQ    23061
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?

Share this post


Link to post
Share on other sites
m4gnus    240
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[i];, 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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this