[jdom-interest] memory leak in 1.1.8 version of org.jdom.input.SAXHandler.flushCh aracters at line 724

Tom Oke tomo at elluminate.com
Mon Apr 8 14:43:50 PDT 2002

In the b8 build of SAXHandler for 1.1.8 the routine flushCharacters creates
the String data from textBuffer.toString(), where in the 1.2+ versions the
code simply does a substring to data from textBuffer.

        String data = textBuffer.toString();

The unfortunate side effect of the 1.1.8 version of the code is that the
characters allocated to the StringBuffer in its declaration, are tied up and
left as a memory leak whenever data is kept, due to the writing action of

This is due to the fact that StringBuffer has its shared (java.lang internal
boolean flag) flag set, to indicate that it is to do a copy on write, when 
toString is called on textBuffer.

This causes the setLength(0) call to duplicate the total storage allocated
to textBuffer, bleeding 4096 byte (or more if textBuffer has eaten anything 
large enough to grow it bigger).

The following correction doubles the copying, but only locks down the
used length of textBuffer, allocating it to String data, and then copying

        StringBuffer dummy = new StringBuffer(textBuffer.toString());
        String data = dummy.toString();

The end effect is that on a large XML, in which the application hit a high
watermark of heap of 184M, the corrected code kep the heap allocation
down to 15M.

The full routine now looks like:

     * <p>
     * This will flush any characters from SAX character calls we've
     * been buffering.
     * </p>
     * @throws SAXException when things go wrong
    protected void flushCharacters() throws SAXException {

        if (textBuffer.length() == 0) {
            previousCDATA = inCDATA;

         * Note: When we stop supporting JDK1.1, use substring instead
        String data = textBuffer.substring(0);
//        String data = textBuffer.toString();
        StringBuffer dummy = new StringBuffer(textBuffer.toString());
        String data = dummy.toString();

 * This is commented out because of some problems with
 * the inline DTDs that Xerces seems to have.
if (!inDTD) {
  if (inEntity) {
  } else {

        if (previousCDATA) {
        else {

        previousCDATA = inCDATA;

Tom Oke

More information about the jdom-interest mailing list