• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 479
  • Last Modified:

MSXML and Document Deallocation

I wish to deallocate an IXMLDOMDocument and all child nodes from memory. So far I have not succeeded. I tried
pDoc->Release() with no success.
I tried walking the tree recursively calling pNode->Release() with no success. I am using perfmon to check the amount of private bytes owned by my task. Is there some sort of COM way of deallocating this memory or what?

How do I deallocate all of a IXMLDOMDocument's memmory, including all child nodes?
0
frogpassword
Asked:
frogpassword
  • 5
  • 4
  • 3
1 Solution
 
chensuCommented:
What do you mean? You should call Release on the interface whenever you get the interface by using CoCreateInstance or QueryInterface.
0
 
frogpasswordAuthor Commented:
I have actually written a dll which contains functions which use msxml.dll, and am using these functions from my executable to create my document. Maybe this is a problem?

My CreateDoc is as follows:
CXML_API BOOL CreateDoc( IXMLDOMDocument **pDoc )
{
  if( (*pDoc) ||
  FAILED(CoCreateInstance
   (CLSID_DOMDocument, NULL,  
   CLSCTX_ALL,
   IID_IXMLDOMDocument, (void**)pDoc)) )
// was a document, or no doco and failed to create one
  {
    return FALSE;
  }
  return TRUE;
}

Is it correct to call CoCreateInstance multiple times in a dll, from different exes and more than once in each exe?
0
 
chensuCommented:
So, for each CreateDoc, you must call Release.

IXMLDOMDocument *pDoc = NULL;
if (::CreateDoc(&pDoc))
{
    ASSERT(pDoc != NULL);

    // ...

    pDoc->Release();
}

Is this what you have done?
0
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

 
frogpasswordAuthor Commented:
I am indeed doing that. The thing I notice in perfmon is that when I call CreateDoc, a large chunk of memory is allocated, whereas when I call Release, a small chunk is deallocated.

I would expect that the memory allocated by the create is totally deallocated by the release.
0
 
chensuCommented:
CoCreateInstance creates an object, which may implement more than one interface. Release decreases the interface reference count by one, if it reaches zero, the interface or object is released. So, depending on what you are doing, what you have seen may be correct.
0
 
mikeblasCommented:
CoCreateInstance() initializes MSXML.DLL. That causes the DLL to be loaded, and it is initialized and
added to your application's working set. (Presumably, it's the working set number you're looking at in the perfmon.)

Then, you get an instance of the object from that DLL. That probably causes the DLL to allocate more memory for that instance. Then, you manipulate that instance. YOu use more memory.

Then, you release that instance. All of the memory associated with that object instance is freed. That explains the small decrease.

But you don't see a matching decrease because MSXML.DLL is still in your working set. It's completely up to the implemnetaiton of the DLL to allow itself to be freed. (That is, it must eventually return TRUE from calls to DllCanUnloadNow(). It may or may not do that, and OLE may or may not free it. If it frees it, it might only do so after some period of inactivity.)

Most DLL servers stay in memory--at least for a little while--even if you're not actively having them serve an object for you. That's because uninitializing a DLL is expensive, and so is reinitializing it. What if you turned around and immediately asked for a new instance of the object? That would cause the DLL to uninitialize, then reinitialize--a substantial waste of time.

..B ekiM
0
 
frogpasswordAuthor Commented:
Take the following fragment, assume all calls succeed:

BCHAR buffer[10000]; // contains xml IXMLDOMDocument *pDoc=NULL;

for(;;)
{
  CreateDoc( &pDoc );
  VARIANT_BOOL bSuccess;
  pDoc->loadXML( buffer, &bSuccess );
  pDoc->Release();
  pDoc = NULL; // so CreateDoc succeeds
}

Would you expect that this would cause mem failure, or that the OS would deallocate the previously deallocated documents when it finds itself out of memory? In theory this loop should run forever with no memory problems.

Is this the case?

We have noticed that each time a new document is created and loaded, memory is taken, but not as much (in fact only a small amount) returned when the document is released.
0
 
mikeblasCommented:
> Would you expect that this would cause mem failure,

No.

 > or that the OS would deallocate the previously
 > deallocated documents

The _documents_, yes.  But not MSXML.DLL itself.  (Assuming you didn't really mean to say "deallocated" twice. If you deallocate something already deallocated, you'll crash.)

 > when it finds itself out of memory? In theory
 > this loop should run forever with no memory problems.

Yes, if MSXML.DLL doesn't leak memory.  And what's a BCHAR?
Seems like you should be sending a BSTR to that method.

But, otherwise, abstractly, yes.

..B ekiM
0
 
mikeblasCommented:
What's the state of this?  Do you have further questions?

..B ekiM
0
 
frogpasswordAuthor Commented:
I have concluded that MSXML leaks memory, or that I don't how to use it properly. Hence due to lack of time available to resolve this problem I have written my own XML parser, which works perfectly. So I am no long interested in this question. Sorry!
0
 
mikeblasCommented:
I'm sorry you changed your mind. But, the question was already asked and already answered.

..B ekiM
0
 
frogpasswordAuthor Commented:
Fair enough.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 5
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now