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 "Vit Ondruch (JIRA)" <xe...@xml.apache.org> on 2006/03/28 12:46:21 UTC
[jira] Created: (XERCESC-1585) Memory leaks in DOMDocumentImpl
Memory leaks in DOMDocumentImpl
-------------------------------
Key: XERCESC-1585
URL: http://issues.apache.org/jira/browse/XERCESC-1585
Project: Xerces-C++
Type: Bug
Components: DOM
Versions: 2.6.0
Environment: Win XP, VS.NET 2k3
Reporter: Vit Ondruch
Hi,
I wanted to use xerces and DOMDocument as kind of dynamical XML fragments container. I want to add new and remove old unused XML elements, but i have encountered that the memory usage is increasing without any apparent reason. If i want to remove the element i wanted to use following code:
DOMNode* pNode = pParent->removeChild(pElement);
pNode->release();
By the documentation, all the memory should be marked as usable for feature use, but that is not true, because the attributes are not released and memory usage is increasing. So I modified the code as follows:
DOMNode* pNode = pParent->removeChild(pElement);
DOMNamedNodeMap* pAttributes = pElement->getAttributes();
while(pAttributes->getLength() != 0)
{
DOMAttr* pAttr = pElement->removeAttributeNode((DOMAttr*) pAttributes->item(0));
pAttr->release();
}
pNode->release();
This code will release the node with its attributes, but still the memory usage is increasing. I have traced the xerces code and found where the problem lies. Its in the method void DOMBuffer::expandCapacity(const unsigned int extraNeeded) which is leaking. The easy solution could be to use the DOMBuffer* DOMDocumentImpl::popBuffer() in a way where the necessary buffer size will be specified and it will return sufficient buffer from fRecycleBufferPtr used or null to create new large enough buffer? I propose something like
DOMBuffer* DOMDocumentImpl::popBuffer(int nMinLength)
{
if (!fRecycleBufferPtr || fRecycleBufferPtr->empty())
return 0;
DOMBuffer* first = fRecycleBufferPtr->pop();
DOMBuffer* buffer = first;
do
{
if (buffer->getLen() >= nMinLength) return buffer;
else
{
fRecycleBufferPtr->push(buffer);
buffer = fRecycleBufferPtr->pop();
}
}
while(buffer != first);
return 0;
}
By this code you can avoid the void DOMBuffer::expandCapacity(const unsigned int extraNeeded) call and the memory leaks. What do you think about it?
Sincerely,
Vit Ondruch
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1585) Memory leaks in DOMDocumentImpl
Posted by "Alberto Massari (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1585?page=comments#action_12423261 ]
Alberto Massari commented on XERCESC-1585:
------------------------------------------
I think this code has an infinite loop coded inside; if you push a not-big-enough buffer back into the stack, and then pop it back, you will be looking at the same buffer for ever.
I will try to code something equivalent.
> Memory leaks in DOMDocumentImpl
> -------------------------------
>
> Key: XERCESC-1585
> URL: http://issues.apache.org/jira/browse/XERCESC-1585
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
> Affects Versions: 2.6.0
> Environment: Win XP, VS.NET 2k3
> Reporter: Vit Ondruch
>
> Hi,
> I wanted to use xerces and DOMDocument as kind of dynamical XML fragments container. I want to add new and remove old unused XML elements, but i have encountered that the memory usage is increasing without any apparent reason. If i want to remove the element i wanted to use following code:
> DOMNode* pNode = pParent->removeChild(pElement);
> pNode->release();
> By the documentation, all the memory should be marked as usable for feature use, but that is not true, because the attributes are not released and memory usage is increasing. So I modified the code as follows:
> DOMNode* pNode = pParent->removeChild(pElement);
> DOMNamedNodeMap* pAttributes = pElement->getAttributes();
> while(pAttributes->getLength() != 0)
> {
> DOMAttr* pAttr = pElement->removeAttributeNode((DOMAttr*) pAttributes->item(0));
> pAttr->release();
> }
> pNode->release();
> This code will release the node with its attributes, but still the memory usage is increasing. I have traced the xerces code and found where the problem lies. Its in the method void DOMBuffer::expandCapacity(const unsigned int extraNeeded) which is leaking. The easy solution could be to use the DOMBuffer* DOMDocumentImpl::popBuffer() in a way where the necessary buffer size will be specified and it will return sufficient buffer from fRecycleBufferPtr used or null to create new large enough buffer? I propose something like
> DOMBuffer* DOMDocumentImpl::popBuffer(int nMinLength)
> {
> if (!fRecycleBufferPtr || fRecycleBufferPtr->empty())
> return 0;
> DOMBuffer* first = fRecycleBufferPtr->pop();
> DOMBuffer* buffer = first;
> do
> {
> if (buffer->getLen() >= nMinLength) return buffer;
> else
> {
> fRecycleBufferPtr->push(buffer);
> buffer = fRecycleBufferPtr->pop();
> }
> }
> while(buffer != first);
> return 0;
> }
> By this code you can avoid the void DOMBuffer::expandCapacity(const unsigned int extraNeeded) call and the memory leaks. What do you think about it?
> Sincerely,
> Vit Ondruch
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1585) Memory leaks in DOMDocumentImpl
Posted by "Vit Ondruch (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1585?page=comments#action_12424083 ]
Vit Ondruch commented on XERCESC-1585:
--------------------------------------
The code is better than it was, but still, why are you returning some not big enough buffer on lines:
// if we didn't find a buffer big enough, get the last one
return fRecycleBufferPtr->pop();
This is memory leak again, because in the next step you will allocate new memory and through out the current pointer, isnt that right? Isnt better to return NULL pointer and allocate new one, but you will have still all the allocated memory available for future. Yes, it is performance penalty, but isnt it better then memory leaks?
> Memory leaks in DOMDocumentImpl
> -------------------------------
>
> Key: XERCESC-1585
> URL: http://issues.apache.org/jira/browse/XERCESC-1585
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
> Affects Versions: 2.6.0
> Environment: Win XP, VS.NET 2k3
> Reporter: Vit Ondruch
>
> Hi,
> I wanted to use xerces and DOMDocument as kind of dynamical XML fragments container. I want to add new and remove old unused XML elements, but i have encountered that the memory usage is increasing without any apparent reason. If i want to remove the element i wanted to use following code:
> DOMNode* pNode = pParent->removeChild(pElement);
> pNode->release();
> By the documentation, all the memory should be marked as usable for feature use, but that is not true, because the attributes are not released and memory usage is increasing. So I modified the code as follows:
> DOMNode* pNode = pParent->removeChild(pElement);
> DOMNamedNodeMap* pAttributes = pElement->getAttributes();
> while(pAttributes->getLength() != 0)
> {
> DOMAttr* pAttr = pElement->removeAttributeNode((DOMAttr*) pAttributes->item(0));
> pAttr->release();
> }
> pNode->release();
> This code will release the node with its attributes, but still the memory usage is increasing. I have traced the xerces code and found where the problem lies. Its in the method void DOMBuffer::expandCapacity(const unsigned int extraNeeded) which is leaking. The easy solution could be to use the DOMBuffer* DOMDocumentImpl::popBuffer() in a way where the necessary buffer size will be specified and it will return sufficient buffer from fRecycleBufferPtr used or null to create new large enough buffer? I propose something like
> DOMBuffer* DOMDocumentImpl::popBuffer(int nMinLength)
> {
> if (!fRecycleBufferPtr || fRecycleBufferPtr->empty())
> return 0;
> DOMBuffer* first = fRecycleBufferPtr->pop();
> DOMBuffer* buffer = first;
> do
> {
> if (buffer->getLen() >= nMinLength) return buffer;
> else
> {
> fRecycleBufferPtr->push(buffer);
> buffer = fRecycleBufferPtr->pop();
> }
> }
> while(buffer != first);
> return 0;
> }
> By this code you can avoid the void DOMBuffer::expandCapacity(const unsigned int extraNeeded) call and the memory leaks. What do you think about it?
> Sincerely,
> Vit Ondruch
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Resolved: (XERCESC-1585) Memory leaks in DOMDocumentImpl
Posted by "Alberto Massari (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1585?page=all ]
Alberto Massari resolved XERCESC-1585.
--------------------------------------
Resolution: Fixed
A fix is in SVN (v. 3.0 branch). Please verify.
Alberto
> Memory leaks in DOMDocumentImpl
> -------------------------------
>
> Key: XERCESC-1585
> URL: http://issues.apache.org/jira/browse/XERCESC-1585
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
> Affects Versions: 2.6.0
> Environment: Win XP, VS.NET 2k3
> Reporter: Vit Ondruch
>
> Hi,
> I wanted to use xerces and DOMDocument as kind of dynamical XML fragments container. I want to add new and remove old unused XML elements, but i have encountered that the memory usage is increasing without any apparent reason. If i want to remove the element i wanted to use following code:
> DOMNode* pNode = pParent->removeChild(pElement);
> pNode->release();
> By the documentation, all the memory should be marked as usable for feature use, but that is not true, because the attributes are not released and memory usage is increasing. So I modified the code as follows:
> DOMNode* pNode = pParent->removeChild(pElement);
> DOMNamedNodeMap* pAttributes = pElement->getAttributes();
> while(pAttributes->getLength() != 0)
> {
> DOMAttr* pAttr = pElement->removeAttributeNode((DOMAttr*) pAttributes->item(0));
> pAttr->release();
> }
> pNode->release();
> This code will release the node with its attributes, but still the memory usage is increasing. I have traced the xerces code and found where the problem lies. Its in the method void DOMBuffer::expandCapacity(const unsigned int extraNeeded) which is leaking. The easy solution could be to use the DOMBuffer* DOMDocumentImpl::popBuffer() in a way where the necessary buffer size will be specified and it will return sufficient buffer from fRecycleBufferPtr used or null to create new large enough buffer? I propose something like
> DOMBuffer* DOMDocumentImpl::popBuffer(int nMinLength)
> {
> if (!fRecycleBufferPtr || fRecycleBufferPtr->empty())
> return 0;
> DOMBuffer* first = fRecycleBufferPtr->pop();
> DOMBuffer* buffer = first;
> do
> {
> if (buffer->getLen() >= nMinLength) return buffer;
> else
> {
> fRecycleBufferPtr->push(buffer);
> buffer = fRecycleBufferPtr->pop();
> }
> }
> while(buffer != first);
> return 0;
> }
> By this code you can avoid the void DOMBuffer::expandCapacity(const unsigned int extraNeeded) call and the memory leaks. What do you think about it?
> Sincerely,
> Vit Ondruch
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
[jira] Commented: (XERCESC-1585) Memory leaks in DOMDocumentImpl
Posted by "Vit Ondruch (JIRA)" <xe...@xml.apache.org>.
[ http://issues.apache.org/jira/browse/XERCESC-1585?page=comments#action_12423314 ]
Vit Ondruch commented on XERCESC-1585:
--------------------------------------
Thank you! I will try to check it ASAP.
> Memory leaks in DOMDocumentImpl
> -------------------------------
>
> Key: XERCESC-1585
> URL: http://issues.apache.org/jira/browse/XERCESC-1585
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM
> Affects Versions: 2.6.0
> Environment: Win XP, VS.NET 2k3
> Reporter: Vit Ondruch
>
> Hi,
> I wanted to use xerces and DOMDocument as kind of dynamical XML fragments container. I want to add new and remove old unused XML elements, but i have encountered that the memory usage is increasing without any apparent reason. If i want to remove the element i wanted to use following code:
> DOMNode* pNode = pParent->removeChild(pElement);
> pNode->release();
> By the documentation, all the memory should be marked as usable for feature use, but that is not true, because the attributes are not released and memory usage is increasing. So I modified the code as follows:
> DOMNode* pNode = pParent->removeChild(pElement);
> DOMNamedNodeMap* pAttributes = pElement->getAttributes();
> while(pAttributes->getLength() != 0)
> {
> DOMAttr* pAttr = pElement->removeAttributeNode((DOMAttr*) pAttributes->item(0));
> pAttr->release();
> }
> pNode->release();
> This code will release the node with its attributes, but still the memory usage is increasing. I have traced the xerces code and found where the problem lies. Its in the method void DOMBuffer::expandCapacity(const unsigned int extraNeeded) which is leaking. The easy solution could be to use the DOMBuffer* DOMDocumentImpl::popBuffer() in a way where the necessary buffer size will be specified and it will return sufficient buffer from fRecycleBufferPtr used or null to create new large enough buffer? I propose something like
> DOMBuffer* DOMDocumentImpl::popBuffer(int nMinLength)
> {
> if (!fRecycleBufferPtr || fRecycleBufferPtr->empty())
> return 0;
> DOMBuffer* first = fRecycleBufferPtr->pop();
> DOMBuffer* buffer = first;
> do
> {
> if (buffer->getLen() >= nMinLength) return buffer;
> else
> {
> fRecycleBufferPtr->push(buffer);
> buffer = fRecycleBufferPtr->pop();
> }
> }
> while(buffer != first);
> return 0;
> }
> By this code you can avoid the void DOMBuffer::expandCapacity(const unsigned int extraNeeded) call and the memory leaks. What do you think about it?
> Sincerely,
> Vit Ondruch
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org