Heap running out of memory, but no memory leak. How to debug?
Author
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.
It could be that you have a container where you keep adding things that at some point should be removed but are not.
Author
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 :(
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.
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.
Author
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!
Edit: thanks KulSeran for the information!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
