From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17158 invoked by alias); 6 Apr 2011 18:39:09 -0000 Received: (qmail 17082 invoked by uid 22791); 6 Apr 2011 18:39:08 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail3.caviumnetworks.com (HELO mail3.caviumnetworks.com) (12.108.191.235) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Apr 2011 18:39:04 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by mail3.caviumnetworks.com with MailMarshal (v6,7,2,8378) id ; Wed, 06 Apr 2011 11:40:01 -0700 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 11:39:03 -0700 Received: from dd1.caveonetworks.com ([12.108.191.236]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 11:39:03 -0700 Message-ID: <4D9CB342.1070300@caviumnetworks.com> Date: Wed, 06 Apr 2011 18:39:00 -0000 From: David Daney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: Andrew Haley CC: Erik Groeneveld , java@gcc.gnu.org Subject: Re: GC leaks debugging References: <4D95909E.4060309@redhat.com> <4D959C24.8030408@redhat.com> <238A96A773B3934685A7269CC8A8D04272EFEFD5C3@GVW0436EXB.americas.hpqcorp.net> <4D997D8C.9060903@redhat.com> <4D9993D4.9040704@redhat.com> <4D9ADA89.8000307@redhat.com> <4D9B112B.6000408@redhat.com> <4D9CB200.2000103@redhat.com> In-Reply-To: <4D9CB200.2000103@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org X-SW-Source: 2011-04/txt/msg00034.txt.bz2 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.