[jira] [Resolved] (XERCESC-1988) memory leak

[Alberto Massari (JIRA)]

[ https://issues.apache.org/jira/browse/XERCESC-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alberto Massari resolved XERCESC-1988.
--------------------------------------

Resolution: Duplicate

Duplicate of XERCESC-2019

memory leak DOMBuffer::expandCapacity
-------------------------------------
Key: XERCESC-1988
URL: https://issues.apache.org/jira/browse/XERCESC-1988
Project: Xerces-C++
Issue Type: Bug
Components: DOM
Affects Versions: 3.1.0
Environment: all
Reporter: Reinier vos
in src/xercesc/dom/impl/DOMStringPool.cpp
DOMBuffer::expandCapacity
a new buffer of the required size is created while leaving the original buffer in memory (comented as a know issue). This posses serious memory issues for large strings ( e.g. base64 strings). Creating a text node of 60MB requires like 600MB memory.
// Copy over the old stuff
memcpy(newBuf, fBuffer, fCapacity * sizeof(XMLCh));
// in DOMDocumentImpl::allocate a standard block (header+buffer[kHeapAllocSize]) is used for allocations <= kMaxSubAllocationSize
// Anything bigger is put into its own block (with its own buffer[cap])
// Check if the buffer we expaned was in its own block, this can be deleted safely after a reallocate
if ( fCapacity * sizeof(XMLCh) > 4096 )
{
size_t sizeOfHeader = XMLPlatformUtils::alignPointerForNewBlockAllocation(sizeof(void *));
//retrieve the location of the buffer preceding the one we're about to delete
//set this location in the new header
*(void **)( (char *)newBuf-sizeOfHeader )=*(void **)( (char *)fBuffer-sizeOfHeader );
delete(((char *)fBuffer-sizeOfHeader));
}
// store new stuff
fBuffer = newBuf;
fCapacity = newCap;

--
This message was sent by Atlassian JIRA
(v6.1#6144)