GCJ 3.4.3 and 3.3 classloading problem

David Daney ddaney@caviumnetworks.com
Fri Sep 11 17:08:00 GMT 2009


Andrew Haley wrote:
> Craig Vanderborgh wrote:
>> Hello Hans, thanks for helping us out with this..
>>
>>> 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.
>>>
>> Yes, this is what I'm trying to say.
>>
>>> What happens if you set the GC_IGNORE_GCJ_INFO environment variable set?  Can you run far enough with GC_DONT_GC?
>> With GC_IGNORE_GCJ_INFO set, the application runs until about 3
>> garbage collection cycles occur, then it crashes with a
>> STATUS_ILLEGAL_INSTRUCTION exception (0xc000001d).   Running with
>> GC_DONT_GC, the application runs for a long time without any trouble
>> at all, until it can't expand the heap anymore.
>>
>> I should mention that I retrofitted boehm-gc 6.2.6 from our port of
>> gcj-3.3 to our port of gcj 3.4.3.  Recall that gc 6.3.1 is the version
>> used "out of the box" for libgcj 3.4.1, 3.4.3, 3.4.4, 3.4.5, 3.4.6,
>> and for the 3.5 snapshots.  The reason I did this was it seemed like a
>> lot less work if I could reuse our gc 6.2.6 port.  But maybe this was
>> not the best choice, since both our gcj 3.3 and 3.4.3 ports exhibit
>> this problem (although to a much less degree in 3.3).  And maybe
>> something was "lost in translation" when I made the needed changes to
>> put gc 6.2.6 into gcj 3.4.3.  Regardless, it is clear that gc 6.3.1 is
>> probably the "most tested" version in gcj 3.x series.
> 
> Are you absolutely sure that you're marking instances of class Class
> correctly?  An error would there cause exactly this behaviour.
> 

On the off chance that you are using WeakReference, there were bugs in 
3.3 that we fixed that can lead to trying access objects that have 
already been GCed and had their memory reused.  When this happens you 
can end up dispatching a method call through a bogus vtable and end up 
executing garbage.

David Daney



More information about the Java mailing list