Sign in to follow this  

Specific Memory Leak question

This topic is 3378 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey Gamedev'erz, I have a question. I recently decided to have a look at the memory leaks in my program of which there are many. My goal is to essentially trim the worst off for good measure, and I've set up paul nettles memory manager to do some of the dirty work. I put to you the following snippet of code:
CvPoint *tempPoint;
for(int i = 0; i < 4; i++ ) {
	tempPoint = (CvPoint*)cvGetSeqElem( mPotentialSquare, i );
	mTempTagPoints.push_back(new tagPoint());
	mTempTagPoints.back()->imgFeedPoint.x = tempPoint->x;
	mTempTagPoints.back()->imgFeedPoint.y = tempPoint->y;
}

mCalcTag->updateTagPointsUnsorted(mTempTagPoints, mPotentialTagInnerContours);

// Clear out any recieved "old" points
for (listIterator = mTempTagPoints.begin(); listIterator != mTempTagPoints.end(); listIterator++) {
	delete (*listIterator);
}

mTempTagPoints.clear();
In essence, the memory manager goes ape-shit over the new tagPoint being created in the for loop. Which is fair enough, except that the points are deleted shortly after in the iterator section. To be fair, the contents of "mTempTagPoints" is actually swapped in the "updateTagPointsUnsorted" function, but it is continously swapped throughout the program. Kind of like a revolving door where the data is at most stored in an alternate list until this portion of code is revisited and then the contents is swapped "out" and the iterator cleans it all out. So I'm wondering if the memory manager is going wonky since the code is obscure or due to some other reason I am as of yet unaware of. A bug perhaps? Regards, Gazoo

Share this post


Link to post
Share on other sites
Does the memory leak log say the leak is caused by that call to new(), or by the push_back()? What if you put the two calls on seperate lines like so:

tagPoint* pPoint = new tagPoint();
pPoint->imgFeedPoint.x = tempPoint->x;
pPoint->imgFeedPoint.y = tempPoint->y;
TempTagPoints.push_back(pPoint);

It's possible that the leak is caused by the push_back; is that vector destroyed before the memory leak report is generated?

Share this post


Link to post
Share on other sites
And while you're coding angel_steve's suggestion, make sure that in your "updateTagPointsUnsorted" function you are swapping vectors of similar sizes, otherwise in your iterator loop, you will delete tagpoints which possibly still need to exist.

Share this post


Link to post
Share on other sites
Why are you using a container of pointers?

I try to use containers of objects, not containers of pointers. If I need polymorphic behavior, I either use a container of boost::shared_ptr, or I use the Boost Pointer Container Library. If my objects are too big to be moved around, I try to use a container type that doesn't move them around (like std::deque). I haven't had a memory leak in years.

Share this post


Link to post
Share on other sites
Ok - I coded in the changes and the memory manager points to the "new" and not the push_back part. I'm not exactly sure when the rapport is generated, but I assume it's when the application closes since that's when the "memleaks.log" file is updated.

I should mention that "mTempTagPoints" is a list and it is destroyed since it is allocated on the stack within an object which is deleted.

ddlox - the lists are either of exactly the same size (4) or 0 in the beginning. But why is it important that they are same sized? The iterator goes through the entire list deleting every entry...

Regards,

Gazoo

Share this post


Link to post
Share on other sites
As for the use of the container in question, the operation is carried out frequently, as in 1-20 times per frame and using a list of pointers is what I believe is the proper balance between functionality and maintainability.

Shared pointers are nice, but I don't really need the control here since the lists are handled in a very closed environment and aren't passed further around in the structure. I used regular pointer since I'd prefer to avoid copying larger amounts of data.

Regards,

Gazoo

Share this post


Link to post
Share on other sites
Call me crazy, but if you delete listIterator, how can you do listIterator++ since this memory no longer exists for you to touch? Did you try stepping through this code with a small subset of data to see if it's actually working properly?

Share this post


Link to post
Share on other sites
Well by dereferencing the iterator I am deleting the object it is pointing to and not the actual iterator, but you do have a point as iterators are often invalidated when deleting things from the container they reference. I'll have a look at it... :)

Share this post


Link to post
Share on other sites
What's a CvPoint? Is it polymorphic? It seems to be, since you instantiate a new tagPoint. What are these things, logically? These are some kind of representation of, well, a point in space, yes? What kind of behaviour do those really need? Why does a tagPoint behave differently from a general sort of CvPoint?

Share this post


Link to post
Share on other sites
Quote:
Original post by Gazoo
Well by dereferencing the iterator I am deleting the object it is pointing to and not the actual iterator, but you do have a point as iterators are often invalidated when deleting things from the container they reference. I'll have a look at it... :)
What you're doing there is fine, the other poster was mistaken. You are just dereferencing the iterator to get the pointer to send to delete. It's okay for the container to then hold the memory address of a deleted block of memory, so long as you don't try to access it or delete it again. I would definitely put the .clear() immediately after that loop though, as you have done.

Share this post


Link to post
Share on other sites
From the code you have posted, I can't tell what the problem is. Perhaps you should try to create a tiny program that shows the problem, so we can look at the whole thing and try to reproduce the problem ourselves.

Unless you tried to have a container of objects and found that to be a performance bottleneck, I would say using a container of pointers is premature optimization.

Share this post


Link to post
Share on other sites

This topic is 3378 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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