[XERCESC-1988] memory leak DOMBuffer::expandCapacity

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 3.1.0
• Component/s: DOM
• Environment: all
• Assignee: Unassigned
• Reporter: Reinier vos
• Created: 07/Jun/12 13:22
• Updated: 03/Oct/13 14:50
• Resolved: 03/Oct/13 14:50

Description

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.

I poked a little change in the mentioned function which by no means is a neat way but for this application it does the trick (and it describes the issue):

// 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;