Community
Participate
Working Groups
I2004-06-16-20:00 1) Create a workspace with JUnit 2) search for all declarations of type * in the workspace (via the search dialog) 3) observe: you get an exception (after quite some time): An internal error occurred during: "Java Search". java.lang.StringIndexOutOfBoundsException at java.lang.Throwable.<init>(Throwable.java) at java.lang.String.substring(String.java) at org.eclipse.jdt.internal.core.SourceMapper.findSourceFileName(SourceMapper.java) at org.eclipse.jdt.internal.core.search.matching.PossibleMatch.getSourceFileName(PossibleMatch.java) at org.eclipse.jdt.internal.core.search.matching.PossibleMatch.getQualifiedName(PossibleMatch.java) at org.eclipse.jdt.internal.core.search.matching.PossibleMatch.<init>(PossibleMatch.java) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:872) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94) at org.eclipse.jdt.core.search.SearchEngine.findMatches(SearchEngine.java:468) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:757) at org.eclipse.jdt.internal.ui.search.JavaSearchQuery.run(JavaSearchQuery.java:125) at org.eclipse.search2.internal.ui.InternalSearchUI$InternalSearchJob.run(InternalSearchUI.java:83) at org.eclipse.core.internal.jobs.Worker.run(Worker.java)
Thomas, what JRE is on your classpath ?
Thomas is using an internal IBM VM whose class lib contains malformed .class files. They pretend that they are local classes when they are member classes, and vice versa.
*** Bug 58196 has been marked as a duplicate of this bug. ***
According to the JVM scpec $4.7.5, the outer_class_info_index of a .class file must be zero if the class is not a member. Some .class file in the mentioned class lib have a non-zero value for this attribute for anonymous class files.
Created attachment 12373 [details] Proposed patch Workaround malformed .class files
Note that the problem is reproduced with: java version "1.4.2" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2) Classic VM (build 1.4.2, J2RE 1.4.2 IBM Windows 32 build cndev-20040524 (JIT enabled: jitc))
+1
The following .class files have been identified has being malformed: a.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] b.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] d.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] f.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] g.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] h.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] DTDGrammar$1.class [in org.apache.xerces.impl.dtd [in .\jre\lib\xml.jar]] DTDGrammar$1.class [in org.apache.xerces.impl.dtd [in .\jre\lib\xml.jar]] SchemaGrammar$1.class [in org.apache.xerces.impl.xs [in .\jre\lib\xml.jar]]
Approved since this happens with JDK libraries.
Jerome - pls attach patch to PR, so Olivier can review it.
Please see patch in comment #5
The patch looks good. We should however report such problems to VM vendors. The VM specs are very clear on the shape of inner info for member, local and anonymous classes.
We have already done some similar changes for isAnonymous().
Thanks Olivier. Patch released.
The problem with these classes: a.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] b.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] d.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] f.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] g.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] h.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] don't have a '$' in the name. This is breaking the source mapper. The proposed patch is fixing this issue. The other issues with the xml classes remains. We added guards against malformed .class files. The outer name index should be 0 for the DTDGrammar$1.class inner class attribute.
The classes: a.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] b.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] d.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] f.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] g.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] h.class [in javax.crypto [in .\jre\lib\ibmjcefw.jar]] are anonymous classes that have been obfuscated. The names with '$' have been replaced with names without '$'. So they are fine from the JVM stand point, but they would not be usable in a debugger for source lookup, because it is not possible to get the name of the source file in which they were defined. The bug in Eclipse was that the assumption was made that the name always contains a '$' for anonymous or local classes.
Verified for 3.0RC3 I200406180800
