Memory leak in DOMBuffer::expandCapacity

[James Williams - Sun East Coast IR Development <ja...@sun.com>]

I've got a use case where the memory leak found in DOMBuffer::expandCapacity
is causing me a problem.  The source for this method states it is causing a
leak. From xercesc/dom/impl/DOMStringPool.cpp:


void DOMBuffer::expandCapacity(const unsigned int extraNeeded)
{
    //not enough room. Calc new capacity and allocate new buffer
    const unsigned int newCap = (unsigned int)((fIndex + extraNeeded) * 
1.25);
    XMLCh* newBuf = (XMLCh*) fDoc->allocate((newCap+1)*sizeof(XMLCh));

    // Copy over the old stuff
    memcpy(newBuf, fBuffer, fCapacity * sizeof(XMLCh));

    // revisit: Leave the old buffer in document heap, yes, this is a 
leak, but live with it!
    // store new stuff
    fBuffer = newBuf;
    fCapacity = newCap;
}


The leak in this method is due to the fact that if the buffer retrieved 
from the
stack of recycled DOMBuffers is not large enough to hold the new string,
a new block of memory is allocated and the old buffer is NOT put back
on the block of recycled buffers, nor is it deleted.

My first thought for fixing this would be to search the recycled list for
a buffer that is large enough, and only allocate new memory if there isn't
one available. Just wondering if this has been done and rejected because
it was too slow?

I would be interested in any other ideas to plug this leak .
I can fix it and offer the code back, just looking for suggestions.

Thanks,
Jim Williams


---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org