Community
Participate
Working Groups
I have discovered a very special case while compiling a large project. When the stars are aligned just right, the byte code generated by Eclipse is invalid. This causes JVM to throw ClassFormatError. At the bottom of this post, there is a listing of the code that creates the problem. I have verified that this problem exists in the latest build and in the last stable build. To Recreate the problem: 1) Turn on all debugging information within Workbench->Preferences->Java->Compiler->ClassFileGeneration. 2) Compile the following code within eclipse. 3) Run the following code within eclipse or stand alone. Note: Same code compiled with JDK 1.3.1, 1.4.0 with -g options does not create ClassFormatError. ----Test.java---- import java.util.Enumeration; import java.util.Vector; public class Test { private void test(Vector v) { // value must NOT be initialized here. String value; // For loop with enumeration must be used. for (Enumeration e = v.elements(); e.hasMoreElements();) { try { //value must be INITIALIZED and USED here. value = "x"; //value must be used within this block System.out.println(value); } catch (RuntimeException re) { // Continue must be present here. continue; } } } public static void main(String[] arguments) { System.out.println("done"); } } -----END-----
"Jay Patel" <jpatel@getthere.com> wrote in message news:a8j7b8$hin$1@rogue.oti.com... > I have verified that this problem exists in the latest build and in the > last stable build. Verified on 20020402, so its not just you: Exception in thread "main" java.lang.ClassFormatError: Test (Invalid start_pc/length in local var table) at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:509) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:123) at java.net.URLClassLoader.defineClass(URLClassLoader.java:246) at java.net.URLClassLoader.access$100(URLClassLoader.java:54) at java.net.URLClassLoader$1.run(URLClassLoader.java:193) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:262) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:322)
Original defect was reported on newsgroup.
I am surprised our sanity check did not capture this one scenario...
The sanity check only ensures that local variable attributes with endPC equals to -1 are not generated. In the above test case we had a range for which the startPC was greater than the endPC (startPC = 25 and endPC = 22). The reason of this was the optimization of the gotos. We looked first if the endPC was at old_position and if true, we check also that startPC was at old_position. The bug was that this two tests should be independant. Changing this in the gotos optimization fixed the VerifyError, because instead of having (25, 22) we had (22, 22) and before generating local variable attributes, we check that startPC is different from endPC. We might want to change this test for startPC > endPC. But if we do that we might hidden bugs like this one. I will run more tests to ensure I don't break anything else.
Fixed and released in HEAD.
