Community
Participate
Working Groups
When using GNU Classpath 0.95 built with ECJ 3.3 the error "java.lang.ClassFormatError: Invalid pc in LineNumberTable in class file java/util/zip/InflaterDynHeader" is reported by the HotSpot client JVM. The line number table for the static initializer of the class looks like: LineNumberTable: line 49: 0 line 50: 19 line 65: 38 line 64: 140 line 40: 143 but the static initializer has no bytecode index 50: static {}; Code: 0: iconst_3 ... 43: iconst_0 44: bipush 16 46: iastore 47: dup 48: iconst_1 49: bipush 17 51: iastore 52: dup 53: iconst_2 54: bipush 18 56: iastore ... It is incorrect for the HotSpot JVM to fail due to an incorrect line number table entry: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6361363 it is also incorrect of ECJ to generate an incorrect line number table. The bug causes builds of the Jikes RVM to fail when using ECJ 3.3 and the Hot Spot client JVM to build/boot strap it.
Created attachment 72990 [details] Javap disassembly for the class with the incorrect line number table.
Is this a regression over 3.2 ? Tagging for 3.3.1.
I am investigating.
Classpath 0.95 compiles fine with ECJ 3.2, so the Jikes RVM has reverted to using ECJ 3.2 currently. There's a Jikes RVM issue tracker here: http://jira.codehaus.org/browse/RVM-112
The problem doesn't come from the static initializer. The clinit is fine. It comes from the method public boolean decode(java.util.zip.StreamManipulator input) throws java.util.zip.DataFormatException; which has a line number entry beyond the code length. I am working on it.
A simpler test case is: public class X { public static void main(String[] args) { int mode = 1; loop: for (;;) { switch (mode) { case 2 : return; case 1: mode = 2; continue loop; } } } } // Method descriptor #15 ([Ljava/lang/String;)V // Stack: 1, Locals: 2 public static void main(String[] args); 0 iconst_1 1 istore_1 [mode] 2 iload_1 [mode] 3 tableswitch default: 27 case 1: 25 case 2: 24 24 return 25 iconst_2 26 istore_1 [mode] 27 goto 2 Line numbers: [pc: 0, line: 3] [pc: 2, line: 5] [pc: 24, line: 7] [pc: 25, line: 9] [pc: 27, line: 10] [pc: 30, line: 11] [pc: 27, line: 4] Local variable table: [pc: 0, pc: 30] local: args index: 0 type: String[] [pc: 2, pc: 30] local: mode index: 1 type: int as you can see, the line number entry for pc 30 is invalid. Removing the continue loop; statement fixes it.
Created attachment 73144 [details] Proposed fix When optimizing a jump to next bytecode, we need to remove entries in the pcToSourceMap table that exceeds the current code stream position.
Created attachment 73145 [details] Proposed fix + regression test Same fix + a regression test
Released for 3.4M1. Added regression test in org.eclipse.jdt.core.tests.compiler.regression.ForStatementTest#test005 Keep it open for release in 3.3.1.
Released for 3.3.1. Added regression test in org.eclipse.jdt.core.tests.compiler.regression.ForStatementTest#test005
Ian, it would be nice if you could confirm that this is fixed using the next 3.3 maintenance build (next Wednesday). Thanks.
Will do, thanks for all your efforts! Ian
*** Bug 196183 has been marked as a duplicate of this bug. ***
Downloaded: http://fullmoon.torolab.ibm.com/downloads/drops/M20070711-0800/ecj.jar and previous regressions have now disappeared. Thanks!
Verified for 3.4M1 using build I20070806-1800.
Verified for 3.3.1 using build M20070831-2000
*** Bug 202165 has been marked as a duplicate of this bug. ***
*** Bug 205046 has been marked as a duplicate of this bug. ***
