[
https://issues.apache.org/jira/browse/XERCESC-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinier vos updated XERCESC-1988:
---------------------------------
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;
was:
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):
memcpy(newBuf, fBuffer, fCapacity * sizeof(XMLCh));
//buffers are allocated with a header that points to the previous buffer
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));
fBuffer = newBuf;
fCapacity = newCap;
> 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.
> 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;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
