GCJ 3.4.3 and 3.3 classloading problem

Boehm, Hans hans.boehm@hp.com
Thu Sep 10 16:11:00 GMT 2009


 

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of Craig Vanderborgh
> Sent: Wednesday, September 09, 2009 8:53 PM
> To: java@gcc.gnu.org
> Subject: Re: GCJ 3.4.3 and 3.3 classloading problem
> 
> On Tue, Sep 8, 2009 at 10:50 PM, Tom Tromey <tromey@redhat.com> wrote:
> >>>>>> "Craig" == Craig Vanderborgh 
> <craigvanderborgh@gmail.com> writes:
> >
> >
> > Craig> The faults usually occur somewhere in string processing, 
> > Craig> typically in java::lang::String::getChars.
> >
> > I don't recall seeing any problems like this.  Of course, 
> since these 
> > releases were so long ago, I wouldn't really expect to remember...
> >
> > Did you search bugzilla for closed bugs along these lines?
> > That might yield something.
> >
> > The String thing is interesting.  We've had various bugs involving 
> > String.intern and also java.lang.ref that might cause inappropriate 
> > collection.
> >
> 
> Until you suggested that GC might be involved I did not 
> really think about that possibility.  Well, further testing 
> reveals that it is.
> The crash happens not when GC is invoked generally, but the 
> first time that GC is invoked AND the heap is expanded during 
> GC.  And this is absolutely consistent.  Is this what 
> "inappropriate collection" could look like?  Is it possible 
> that the classloaded objects are different in some 
> (incorrect) way, such that objects or parts of objects might 
> be getting garbage collected when they are still needed?  Is 
> this what you're suggesting?
> 
> If so, any suggestions on how I could constructively proceed 
> from here?
> 
You mean the crash happens in the same GC cycle in which the heap is grown?  Or in the next cycle after that?  Either way it sounds strange to me.  It may be that there is some large object allocation that causes the heap expansion and occurs near the failure.  But I'm not sure.

What happens if you set the GC_IGNORE_GCJ_INFO environment variable set?  Can you run far enough with GC_DONT_GC?

In the end, this may require brute force debugging.  Find the object that was corrupted/collected early, and then follow the chain of objects from a root checking which ones are marked, so that you can identify where a link wasn't followed correctly.  This is unfortunately much easier if you can get the process to loop at the point of failure, so that you can call GC_is_marked() from the debugger.

Hans



More information about the Java mailing list