Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Duplicate
-
3.1.0
-
None
-
None
-
all
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 )
// store new stuff
fBuffer = newBuf;
fCapacity = newCap;