Community
Participate
Working Groups
Build ID: I20070323-1616 Steps To Reproduce: This bug appears to be unreproducable. It belongs to a class of increasingly rare bugs related to JDT builds. They commonly manifest themselves as exceptions (see below) on line 0 of a recently modified java file, or a file imported by another file which has beeen recently modified. I submit this in the general hope of helping someone track down these issues, as I cannot, in general, reproduce any of them. More information: Internal compiler error java.lang.ArrayIndexOutOfBoundsException: 2 at org.eclipse.jdt.internal.compiler.lookup.Scope.lowerUpperBound(Scope.java:2942) at org.eclipse.jdt.internal.compiler.lookup.Scope.lowerUpperBound(Scope.java:2876) at org.eclipse.jdt.internal.compiler.ast.ConditionalExpression.resolveType(ConditionalExpression.java:454) at org.eclipse.jdt.internal.compiler.ast.Assignment.resolveType(Assignment.java:184) at org.eclipse.jdt.internal.compiler.ast.Expression.resolve(Expression.java:883) at org.eclipse.jdt.internal.compiler.ast.Block.resolve(Block.java:101) at org.eclipse.jdt.internal.compiler.ast.IfStatement.resolve(IfStatement.java:233) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolveStatements(AbstractMethodDeclaration.java:432) at org.eclipse.jdt.internal.compiler.ast.MethodDeclaration.resolveStatements(MethodDeclaration.java:195) at org.eclipse.jdt.internal.compiler.ast.AbstractMethodDeclaration.resolve(AbstractMethodDeclaration.java:403) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1086) at org.eclipse.jdt.internal.compiler.ast.TypeDeclaration.resolve(TypeDeclaration.java:1164) at org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration.resolve(CompilationUnitDeclaration.java:359) at org.eclipse.jdt.internal.compiler.Compiler.process(Compiler.java:618) at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:391) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:356) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.compile(IncrementalImageBuilder.java:302) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:293) at org.eclipse.jdt.internal.core.builder.IncrementalImageBuilder.build(IncrementalImageBuilder.java:130) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildDeltas(JavaBuilder.java:265) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:192) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:163) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:248) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:251) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:307) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:339) at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:137) at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
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.
