fixes for memory leak xerces 1_4_2

[Jeremy Carroll <jj...@hplb.hpl.hp.com>]

Hello

I have only been lurking on this list a couple of days, so I haven't yet
seen the process for submitting fixes. So please bear with me, 'cos I am
sure I won't do it quite how you like.

I have found two distinct leaks, one minor, one major (fixing bug no
897).

I thought I would give a bit of background, and then the two fixes in
two separate e-mails.

I was worried about the memory leak (bug no 897)
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=897

So I downloaded the latest tar-ball 
(xml-xerces_20010803161801.tar.gz)
and a java memory leak detecter
http://www.geocities.com/moellep/debug/HeapInspector.html

When I ran this on my test case (an 800MB RDF/XML file, a cleaned up
version of http://dmoz.org/rdf/content.rdf.u8.gz ).
I interrupted it after just a little and I could see:

+ a chain of CharDataChunk's hanging off a ChunkyCharArray hanging off
the fLiteral field of a XMLDocumentScanner hanging indirectly off a
SAXParser hanging off the fgFreeReaders field in StringReader.

If I waited longer before interrupting to inspect the heap, the chain
was longer. So the gradual leak, impacting big XML files as described in
the bug report, appearred to be this chain of CharDataChunk's.

Moreover, even after the parse was over, the whole thing was not garbage
collectable because of the static reference from StringReader.

The next message gives a fix that removes that spurious static
reference.

The one after shows how to stop the chain building up in the first
place.

With both of them in place, I quite happily parse the 800MB file,
keeping my java process under 10MB.


Please give me feedback about the process for updating the repository.


Thanks

Jeremy Carroll
HP Labs, Bristol.

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