Re: GC leaks debugging

[Andrew Haley <aph@redhat.com>]

On 04/06/2011 03:29 PM, Erik Groeneveld wrote:
>>> The tests work fine on OpenJDK.  What could cause GCJ to grow the heap
>>> infinitely?
>>
>> I don't know because you won't show me the tests.
> 
> Yeah, of course, sorry.  I forgot to tell a few things.
> 
> This problem has been bothering me quite some time now, and I decided
> to solve it once and forever.  I have written many different test, but
> I am still not able to pinpoint a simple program to demonstrate the
> results.  The problem occurred initially while using Lucene, but later
> on also with Owlim.  Having written all kinds of test programs with
> Lucene, from doing almost nothing to fully fletched indexing, I can
> make no definite conclusions yet.
> 
> I am now circling around the problem, trying to enclose it from
> different sides and I seek your help for giving me hints on what to
> look for.  It is not lightly that I decided to bring it into this
> mailing-list, knowing that it would claim many peoples time.
> 
> Now the test I am running is attached.  It indexes a very simple
> document with a unique id each, first assuring is it deleted.  And
> each loop, it reopens the index-reader and searcher.  This test starts
> to get in trouble above 10,000,000 loops (documents).  The problem is
> that when I remove code (I tested systematically), it only takes
> longer for the heap to explode. The only test that ran properly was
> when I only created Documents and not index them.  So perhaps it has
> to do something with I/O.

Just as a clue: there are thousands of unclosed FileInputStreams and
FileDescriptors.  At a mad guess, someone is not closing their files but
hoping that finalization will do it instead.

I was using:

	gnu::gcj::util::GCInfo::enumerate(JvNewStringUTF("LuceneDump"));

and

 /usr/local/bin/gc-analyze  TestDump001

Eventually, I get a

Exception in thread "main" java.lang.IndexOutOfBoundsException
   at java.nio.Buffer.checkIndex(Buffer.java:331)

from gc-analyze.  I may be able to find out what is causing that.

Andrew.