Memory leak C++, XML, MSXML, COM

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I've got a problem and I haven't found any solution in the web till now. I'm
using MSXML4.0SP2 with VC6 creating large XML files. The (only) problem I've
got is the not-existing release of memory. My app allocs more and more memory
and gives no back.

I've build a small code part explaining my problem:

CoInitialize(NULL);

CoCreateInstance(__uuidof(DOMDocument40),
NULL,
CLSCTX_INPROC_SERVER,
__uuidof(IXMLDOMDocument2),
(void**)&pDOMDoc),
"Create a new DOMDocument";

m_pDOMDoc->load(_variant_t("1.xml"),0);

IXMLDOMElement *pEl;

m_pDOMDoc->get_documentElement(&pEl);

for(int i= 0; i<500; i++)
{
IXMLDOMElement *pElb;
m_pDOMDoc->createElement(_bstr_t("B1"), &pElb);
pElb->setAttribute(_bstr_t("b1"),_variant_t("2"));
pEl->appendChild(pElb,NULL);

//pElb->Release(); //OPTIONAL, OP EFFECT ?!?
}

m_pDOMDoc->save(_variant_t("1.xml"));
//pEl->Release(); //Optional, no effect!!
m_pDOMDoc->Release();
delete m_pDOMDoc;

CoUninitialize();

That's it! I create a simple XML Document ...

<A1>
<B1 b1="2" />
<B1 b1="2" />
<B1 b1="2" />

... 500 times ...

<B1 b1="2" />
</A1>

Before loading I've used 1,4MB, after load 1,7MB, after saving 1,8MB ...
after releasing (or/and) couninitializing still 1,8MB. Why? Shouldn't the
memory be released? The CoUninitializing function ist just for fun, because
i'm using more than one XML file and I can't throw the library away, still
using it for other objects.

Please Help, Mayday :-)

Greetz from Mainz

Mathew
 
Hi Mathew!
I've got a problem and I haven't found any solution in the web till now. I'm
using MSXML4.0SP2 with VC6 creating large XML files. The (only) problem I've
got is the not-existing release of memory. My app allocs more and more memory
and gives no back.

MSXML uses some kind of GC (garbage collector) which does not
automatically free memory when you expect it...

See: Understanding the MSXML garbage collection mechanism
http://support.microsoft.com/kb/304227/en-us

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
I've got a problem and I haven't found any solution in the web till now.
I'm
using MSXML4.0SP2 with VC6 creating large XML files. The (only) problem
I've
got is the not-existing release of memory. My app allocs more and more
memory
and gives no back.

I've build a small code part explaining my problem:

CoInitialize(NULL);

CoCreateInstance(__uuidof(DOMDocument40),
NULL,
CLSCTX_INPROC_SERVER,
__uuidof(IXMLDOMDocument2),
(void**)&pDOMDoc),
"Create a new DOMDocument";
...
m_pDOMDoc->Release();
delete m_pDOMDoc;

What do you mean with delete m_pDOMDoc?
I strongly advice you to use _com_ptr_t type and use #import directive to
create com wrappers. This way your code will be much simplier and you won't
forget clean up resources.
 
Thx,

but I've got still the same problem ... after optimizing VARIANT and BSTR
allocations i need 49,6 instead of 49,8 MB for my testfile (1,1 MB xml file)
.... and calling CoFreeUnusedLibraries() doesn't seem to work ... using SP2 of
MSXML40 I've got no "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\msxml40" Key in my
Registry and creating this key is absolutly irrelevant.

I've checked all DOM Objects for beenig Released, but everything seems to be
fine.

Please help!!

Mathew
 
Hi Mathew!
but I've got still the same problem ... after optimizing VARIANT and BSTR
allocations i need 49,6 instead of 49,8 MB for my testfile (1,1 MB xml file)
... and calling CoFreeUnusedLibraries() doesn't seem to work ... using SP2 of
MSXML40 I've got no "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\msxml40" Key in my
Registry and creating this key is absolutly irrelevant.

I've checked all DOM Objects for beenig Released, but everything seems to be
fine.

To find leaks, you can try my leakfinder at:
http://blog.kalmbachnet.de/files/LeakFinder-RC3.zip

See also: http://www.codeproject.com/tools/leakfinder.asp

But as I said: It is hard to track down MSXML leaks...

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Back
Top