Uploaded image for project: 'Xerces-C++'
  1. Xerces-C++
  2. XERCESC-1988

memory leak DOMBuffer::expandCapacity

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Duplicate
    • 3.1.0
    • None
    • DOM
    • 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 )

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

      Attachments

        Activity

          People

            Unassigned Unassigned
            reiniervos Reinier vos
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: