Summary: | JDT Throws ArrayIndexOutOfBounds on incremental build | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Greg Gibeling <gdgib> |
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> |
Status: | RESOLVED WORKSFORME | QA Contact: | |
Severity: | minor | ||
Priority: | P5 | ||
Version: | 3.3 | ||
Target Milestone: | 3.3 RC4 | ||
Hardware: | PC | ||
OS: | Windows Server 2003 | ||
Whiteboard: |
Description
Greg Gibeling
2007-03-29 12:29:41 EDT
Can you provide the source code for the offending compilation unit ? The offending unit is the one carrying the internal error marker on line 0. I suspect that it wont help you much, but I have attached the source to a private e-mail. Below you can find the steps which produced the original exception. Repeating them does NOT cause the exception again. Performing a clean before a build is what resovled the exception initially. 1) Modified line 732 of AbstractRADService.java to reference "UnboundedCollection.defaultAttributes" rather than "HashSet.defaultAttributes". 2) Imported UnboundedCollection using ctrl+shift+M. 3) Changed line 84 of UnboundedCollection.java to give "defaultAttributes" type "CollectionAttributes" instead of "ImmutableCollectionAttributes". 3a) This was to fix a compiler error on line 732 of AbstractRADService.java If you really want, I can give you a gigantic tarball of code including everything. It's big and quite complex, but if it'll help you... I should have mentioned that the files I sent you appear as they do AFTER the changes I listed, just to be clear. This may very well be related to Bug 180030, which is now fixed. Excuse me, I meant Bug 180109 in my previous comment. The stacktrace is different, this isn't the same problem. Olivier - pls try to work with Greg on providing reproducable steps. I think you will need the entire tarball. The problem would be located in Scope#lowerUpperBound, in this loop: TypeBinding[] otherBounds = new TypeBinding[count - 1]; int rank = 0; for (int i = 0; i < count; i++) { TypeBinding mec = commonDim == 0 ? mecs[i] : mecs[i].leafComponentType(); if (mec.isInterface()) { otherBounds[rank++] = mec; // AAIOOBE } } But the situation would have to be that 'mecs' only contains interfaces, which cannot occur in theory (first is always a class). Greg, Can we find a way to get the tarball? I'll investigate as soon as I get it. I just about have a zipfile, but it'll be about 4MB and I'd really rather not post it to bugzilla since the licenses in the code are not finalized. Can I just e-mail it to you? Sure. I might need the Temp project as well in order to reproduce. I played a bit with the project you sent, but so far I cannot reproduce the failure. Would it be possible to send me the Temp project as well? Thanks. I'll e-mail you the "Temp" project very shortly. (Maybe 30min) However, it is quite unlikely that you will actually be able to reproduce this bug through any set of modifications you make. Like the vast majority of incremental build bugs, it was highly transient. For example, undoing and redoing the steps which caused it in the first place, did not cause it again. I suspect you'll have to examine the JDT code by hand to figure this out, since I've never seen this bug before or since. I tried for a good half an hour to nail down a set of steps to reproduce before giving up. Of course the combination of the infrequency of the bug, the difficulty to reproduce and the simple work-around (full build) is why I marked it as "minor". I could not reproduce this failure. If you ever get a chance to find a more "reproducable" test case, let us know. I have not seen this bug in a long time, and I was never able to reproduce it. I'm currently using I20070503-1400 (3.3M7) and I suspect it's been fixed, though I have no proof. Closing as WORKSFORME then for now. Reopen if you get it again. Thanks. |