You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Kelly Davis <th...@yahoo.com> on 2012/10/29 10:27:38 UTC

DOMNodeIterator leak?

It seems that proper, as far as I understand it, use of a DOMNodeIterator
leads to a leak. To whit, when one uses a DOMNodeIterator...


DOMNode *domNode = ...
ElementFilter  elementFilter;
DomDocument *domDocument = ...

DOMNodeIterator *domNodeIterator = domDocument->createNodeIterator(domNode,ElementFilter::SHOW_ELEMENT,&elementFilter,false);
while(DOMElement *domElement = (DOMElement*) domNodeIterator->nextNode()) {
  // Do something with domElement
}

domNodeIterator->release();


the call to release() on domNodeIterator removes the DOMNodeIterator
from the fNodeIterators member of DOMDocumentImpl and sets the
fDetached member of DOMNodeIteratorImpl to false.

As fNodeIterators is a RefVectorOf<DOMNodeIteratorImpl>, created,
see DOMDocumentImpl:: createNodeIterator(), with adoptElems set
to false, this removal from fNodeIterators  does not delete the the
DOMNodeIterator.

However, this leads to the case where DOMDocumentImpl, through
fNodeIterators, has no pointer to fNodeIterators and domNodeIterator
is not deleted.

To me, and the observed heap explosion in my program, this seems
like a leak.

The obvious solution, as I see it, is to modify the DOMDocumentImpl
method createNodeIterator() as follows:

-    fNodeIterators = new (fMemoryManager) NodeIterators(1, false, fMemoryManager);

+   fNodeIterators = new (fMemoryManager) NodeIterators(1, true, fMemoryManager);


this would case the release() and subsequent removal to delete the
DOMNodeIterator.


Are there problems with this solution?

Best,
Kelly

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org