Memory leak using CoCreateInstance and MSXML ?!?
Michael Lynggaard
I am developing a mean unmanaged VC7 multi-threaded windows program using
wsock32.lib and msxml.dll. The program will be implemented as a service
running on the NT4/Win2000 platform.
When I use
CoCreateInstance(MSXML::CLSID_DOMDocument, NULL,
CLSCTX_INPROC_SERVER,
MSXML::IID_IXMLDOMDocument, (void**)&pDoc);
it leaks more then 1 mb of memory acording to the Windows task maneger,
as yuo se in my sample program.
In every thread I use several xml documents and therefore memory are
leaking.
Do you know any guidelines for doing this whitout memory leaking ?
I have also posted this issue in microsoft.public.xml
Best,
Michael Lynggaard
/Denmark
// LeakTest.cpp:
#import "msxml.dll" named_guids raw_interfaces_only
#include <stdio.h>
int _cdecl main(int /*argc*/, char /**argv[]*/)
{
MSXML::IXMLDOMDocument *pDoc = NULL;
int rc = -1;
printf("memory used in windows task manager -> 648 kb\n"); getchar();
::CoInitialize(NULL);
printf("816 kb\n"); getchar();
CoCreateInstance(MSXML::CLSID_DOMDocument, NULL, CLSCTX_INPROC_SERVER,
MSXML::IID_IXMLDOMDocument, (void**)&pDoc);
printf("2144 kb\n"); getchar();
pDoc->Release();
printf("2160 kb\n"); getchar();
::CoUninitialize();
printf("1808 kb\n"); getchar();
return rc;
}
Tom Stewart
memory charged to your process goes up after this call. The last parameter
is a pointer to a pointer, meaning that the function is allocating memory on
your behalf. Just because the memory charge goes up doesn't imply there's a
leak. There's only a leak when the means to recover the allocated memory has
been lost. E.g., your pDoc is a local, and you don't do whatever is required
to free it up within the context of your function.
--
Tom
"Michael Lynggaard" <ly...@alka.dk> wrote in message
news:ubvd0S$eCHA.1760@tkmsftngp12...
Jon Wiswall [MS]
information is somewhat misleading. "Memory usage" is the total amount of
pages you've touched recently, keeping them in memory, "VM Size" is the
total amount of virtual memory you're using. Remember that CoCreateInstance
does a LoadLibrary (in effect), which means now msxml itself is living in
your process. It's entirely believable that loading msxml requires some
memory, or that the increase you're seeing is simply because MSXML?.DLL is
now mapped in your address space.
There's another thread active on the group right now about using IMallocSpy
to track potential leaks while using msxml, you might consider
finding/reading it as well.
Your code looks solid - you get the pointer, you relase the pointer, that's
it. There's no room for leaks that I can find.
--
Jon Wiswall - Microsoft
This posting is provided AS IS with no warranties, and confers no rights.
"Tom Stewart" <tast...@msdn.microsoft.com> wrote in message
news:u$9wy1CfCHA.1992@tkmsftngp11...
Johna
news:eknSBoEfCHA.348@tkmsftngp12...
> I'd have to agree with Tom here. The task manager's "memory use"
> information is somewhat misleading. "Memory usage" is the total amount of
> pages you've touched recently, keeping them in memory, "VM Size" is the
> total amount of virtual memory you're using.
Task Managers and "VM size" matched perform's "Private Bytes". There was no
correlation that I found with for "Memory Usage".
> Remember that CoCreateInstance
> does a LoadLibrary (in effect), which means now msxml itself is living in
> your process. It's entirely believable that loading msxml requires some
> memory, or that the increase you're seeing is simply because MSXML?.DLL is
> now mapped in your address space.
MSXML caches objects.
Pavel Lebedinsky
from taskman column names to perfmon counters:
Mem Usage = Working Set
VM Size = Private Bytes
There is nothing in Task Manager that corresponds to Virtual Bytes.