I have a 200 MB XML file that I am loading using TinyXML. My problem is that when the TinyXML object is destroyed, the memory it used will not be reused. I have used a memory leak detector that I have used in other projects, and have manually stepped through the code and have not been able to find any memory leaks, so I don't suspect that leaked memory is the problem.
This code will reproduce the problem:
#include <iostream>
#include <tinyxml.h>
int main()
{
char* filename = "../LargeFile.xml";
{
TiXmlDocument targetDoc( filename );
targetDo开发者_JS百科c.LoadFile();
}
char* buf = new char[ 524288000 ];
delete [] buf;
return 0;
}
Using Address Space Monitor I can see that after LoadFile()
there is a large chunk of red, then after targetDoc
is destroyed it is all yellow. Then when the final char buf is allocated it appears in red but over the top of green space rather than the yellow freed from TinyXML. If try to allocate more buffers than there is green address space the application will crash(out of memory). This can be seen in the images below.
According to the Address space monitor page "Free address space is shown in green, reserved addresses in yellow and used (committed) memory regions in red" So why is the memory that is freed by TinyXML staying "reserved" according to Address Space Monitor. What can cause that to happen, and how do I stop it?
EDIT:
"Are you allocating large buffers? If so, then there may be memory fragmentation in the yellow space and there's nowhere that a large contiguous buffer can be allocated"
Great question however this would indicate that TinyXML has a memory leak and none of my tools have shown there to be one.
UPDATE
I made loop that endlessly allocated ints, which eventually appeared to used all the yellow space. However larger allocations don't use it. This indicated to me that there were small leaks that were getting littered through the heap during the parsing of the xml file by tinyXML which fragments the heap in such a way that only objects small enough to fit between the leaks could be allocated in the yellow space. So I searched longer and harder for leaks in TinyXML and still did not find any. Everything seems to be getting freed up correctly, which brings me back to my initial state of confusion.
I am at a loss to explain the problem.
Are you actually seeing any other indications of memory issues? Reserved memory indicates that the address range is reserved from the OS, but there is no physical memory actually in use. It is nothing to worry about. When you next need memory, it will first come from that reserved space.
Most OSes don't actually release memory back to the OS when a free() is done (Linux does sometimes for large deallocations). Instead, application's use the OS sbreak() function to grow memory, maintaining a "high water mark". As long as you're doing the free() for each malloc() then memory's not being leaked, and future allocations will come from the same memory. Of course, it may be that something inside TinyXML's not doing such matching frees, deliberately or otherwise, e.g.:
- some function in the TinyXML class, or called by it, could have a static local pointer variable that is initialised to point to newly allocated heap when the function is first called. If that happens after other routines have allocated a lot of memory for more transient data, then even after the latter memory is freed the static pointer's allocation may cause some fragmentation, preventing allocation of a huge contiguous block in the reclaimed space.
精彩评论