Summary: | [compiler] java.lang.ClassFormatError: Invalid pc in LineNumberTable | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Ian Rogers# <ian.rogers> | ||||||||
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||||
Severity: | normal | ||||||||||
Priority: | P3 | CC: | bugs.eclipse.org, david_audel, mra, mronchi, philippe_mulet | ||||||||
Version: | 3.3 | ||||||||||
Target Milestone: | 3.3.1 | ||||||||||
Hardware: | PC | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Attachments: |
|
Description
Ian Rogers#
2007-07-03 18:31:36 EDT
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 196183 has been marked as a duplicate of this bug. *** *** Bug 202165 has been marked as a duplicate of this bug. *** *** Bug 205046 has been marked as a duplicate of this bug. *** |