GC leaks debugging

Wed Apr 6 18:39:00 GMT 2011

On 04/06/2011 11:33 AM, Andrew Haley wrote:
> 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.
>
:-(

Sorry about that. It shouldn't crash, but unfortunately I don't have 
the time to fix it right now.
David Daney.