Sign in to follow this  
floatingwoods

Heap running out of memory, but no memory leak. How to debug?

Recommended Posts

Hello, My application performs various types of simulations and when I let one simulation run for several hours, it suddenly runs out of heap space. However if I stop the simulation before and exit the application, no memory error/leak is reported. So it seems that somewhere in my simulation loop I am allocating more and more memory, but that memory is released correctly at simulation stop and program exit. Now my question is: how to find the instruction or function that is causing the heap to run out of space? Best would be if I had a list of allocated memory together with the instructions/functions that allocated them. I am using Visual Studio 8. I also checked the _CrtCheckMemory and _CrtSetDbgFlag functions and such, but in my case it seems they can't help me further.

Share this post


Link to post
Share on other sites
Yes, that's exactly the point. However which is the container, or where is the location? I probably have several hundreds of containers of all sort filling up or emptying at each simulation step. It is probably some very stupid thing, but localizing it is very painful :(

Share this post


Link to post
Share on other sites
The other option is that you aren't actually running out of memory, but out of contigious memory (fragmentation).
This could be caused by random allocation/free patterns. Try to reserve space in all your containers before your simulation starts. Make sure you pass containers by const reference instead of value when possible. Change your containers to use something like Boost::pool to allocate instead of the standard allocators.

Grab a memory manager or tracker like the FluidStudios memory manager, or valgrind. (or wrap your own overloads of new/delete) to track allocations. This can massively slow down the application, so hope your growth pattern shows up early.

If things are still too hard to track down, consider adding a way to dump your memory reports from within the simulation, or atleast have a spot in the code with good access to all your major containers so you can occasionally break and check on their sizes.

Share this post


Link to post
Share on other sites
I finally found the reason of the memory problem: the lexical_cast from the boost library I was using was leaking memory (the lexical_cast version was of the year 2000). After updating to the newest Boost library (1.38.0) the problem disappeared.

Edit: thanks KulSeran for the information!

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