On 10/26/05, Mike Stump <[EMAIL PROTECTED]> wrote:
>
> > That array ("str") in "tree_string" is of variable length and
> > its length is indicated by the "length" field. So technically
> > at least it should be marked with a GTY((length(...)))
> > marker.
>
> I don't believe it is necessary.Just to confirm that I understand you properly, it is not necessary because that variable-length array merely contains chars, not pointers that the GC might need to follow. The size of the chunk would anyway be stored in the metadata for that chunk, so the GTY((length)) marker can't be for that. > > Well, the current compiler crashes building > > "java/lang/Character.java" where in the debugger I see the > > Tree-SSA operands processing code "going bonkers". So > > I am trying to figure out if this is because something was > > yanked from under its feet by the GC or because there > > is some bug in the relevant Tree-SSA code from the time > > of the merge or because somehow the GCJX front-end > > is not creating the trees properly or something else. > > Set a breakpoint on creation, and one of use, either, the data > matches, or it doesn't. If it doesn't set a watch point on the > changed data, and rerun. Careful to enable the breakpoint only after > creation, as watch doesn't like unmapped mempory (on darwin anyway). > You can also tell GC to never collect, and thus `know' if that is the > issue. Also, you can breakpoint the walker/freer and check if the > address that can't be freed is. Doing an up from that point tells > you the context it was in when freed. At times, collect isn't > allowed, and it might be one of those times. Breaking on freer is > easier to understand than breaking on a watch point. ggc_free might > be called on data that isn't totally free, just comment out the > ggc_free call to fix. Thanks a lot for your suggestions. I effected modify_stmt() for the statement and called get_stmt_operands() from within the debugger and followed the whole thing to find out that the USEs are indeed calculated correctly. I also disabled GC (by setting ggc-min-heapsize very high) and found that the problem still persists. I have a theory that the problem occurs because GCJX is sharing the ADDR_EXPR for the Jv_ThrowBadArrayIndex method across the CALL_EXPRs that call this method (unlike GCJ on mainline), but I unfortunately ran out of time before I could test this. Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
