Community
Participate
Working Groups
This may duplicate bug 196823, but as far as I can tell, there is nothing wrong with the class file in this case, which is from the runtime distribution. C:\>"\Program Files\Java\jre1.5.0\bin\java.exe" -version java version "1.5.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-b64) Java HotSpot(TM) Client VM (build 1.5.0-b64, mixed mode, sharing) -- Error Log -- Date: Fri Oct 05 13:02:23 EDT 2007 Message: ClassFormatException in C:/Program Files/Java/jre1.5.0/lib/ext/sunjce_provider.jar|com/sun/crypto/provider/SunJCE_am.class. Please report this issue to JDT/Core including the problematic document Severity: Error Plugin ID: org.eclipse.jdt.core Stack Trace: org.eclipse.jdt.internal.compiler.classfmt.ClassFormatException at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:342) at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:121) at org.eclipse.jdt.internal.core.search.indexing.BinaryIndexer.indexDocument(BinaryIndexer.java:622) at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.indexDocument(JavaSearchParticipant.java:74) at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexDocument(IndexManager.java:314) at org.eclipse.jdt.internal.core.search.indexing.AddJarFileToIndex.execute(AddJarFileToIndex.java:197) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:392) at java.lang.Thread.run(Unknown Source)
Created attachment 79822 [details] com/sun/crypto/provider/SunJCE_am.class
Sorry, I meant bug 195823.
I am investigating it.
This doesn't look like a dup of bug 195823. The class file reader is failing during the EnclosingMethod attribute decoding.
This .class file has been obfuscated and it appears that the resulting .class file doesn't follow the JVM spec anymore. The EnclosingMethod attribute is supposed to be formed like this: u2 attribute_name u4 attribute_length u2 class_index u2 method_index The class index is supposed to correspond to an CONSTANT_Class entry in the constant pool. In this case the entry at the specified index is a CONSTANT_UTF8 entry. This is illegal and the class file reader doesn't handle it. javap doesn't check this constraints: Compiled from DashoA6275 class com.sun.crypto.provider.SunJCE_am extends java.lang.Object SourceFile: DashoA6275 Synthetic: length = 0x EnclosingMethod: length = 0x4 00 07 00 00 InnerClass: #10 of #12; //class com/sun/crypto/provider/SunJCE_am of class com/sun/crypto/provider/JceKeyStore minor version: 0 major version: 48 Constant pool: const #1 = Asciz DashoA6275; const #2 = Asciz EnclosingMethod; const #3 = Asciz InnerClasses; const #4 = Asciz SourceFile; const #5 = Asciz SunJCE: Sun Microsystems, Inc.; const #6 = Asciz Synthetic; const #7 = Asciz com/sun/crypto/provider/JceKeyStore; const #8 = Asciz com/sun/crypto/provider/SunJCE_am; const #9 = Asciz java/lang/Object; const #10 = class #8; // com/sun/crypto/provider/SunJCE_am const #11 = class #9; // java/lang/Object const #12 = class #7; // com/sun/crypto/provider/JceKeyStore { } You can see that the "00 07" which corresponds to the class index is indeed an CONSTANT_UTF8 entry in the constant pool. The more I look at this, the more I believe that we should silently ignore these errors. I wanted to log them in case we were hiding a real bug inside the classfile reader, but each bug report we got so far related to this logging appears to be due to real corrupted or malformed .class files. Philippe, should we report this error only in debug mode ? This is what I would propose otherwise we will keep getting new bug reports when the class file reader is right to reject the .class files. I could also add error handling inside the class file reader in order to be able to "read" as much as possible. In this case, we would not set the enclosing type name, but we would still be able to read the remaining part of the .class file. Let me know what solution you prefer.
If I manually replace "00 07" with "00 0C", then it can be successfully read by the class file reader. So we either make the class file reader more resilient to invalid class files, or we simply "ignore" the invalid class file and we don't report the error in the .log anymore. I would prefer the second approach and report it only in debug mode if the debug mode is on for the JavaCore plugin.
Closing as a dup of bug 195823. Even if the problem is not located in the same part of the .class file, the corresponding .class file is corrupted. So the class file indexer is right to reject it. *** This bug has been marked as a duplicate of bug 195823 ***
Verified for 3.4M3 using I20071029-0010
