Re: GCJ 3.4.3 and 3.3 classloading problem

[Andrew Haley <aph at redhat dot com>]

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.

Andrew.