Summary: | [compiler] Wrong pc in the line number table attribute | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | GSMD <gsmd> | ||||||
Component: | Core | Assignee: | Olivier Thomann <Olivier_Thomann> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | cocoakevin, philippe_mulet | ||||||
Version: | 3.1 | ||||||||
Target Milestone: | 3.2 M5 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
GSMD
2005-12-03 11:25:30 EST
Looks more like a VM bug then a bug in the debugger. Does the VM crash always occur at the same place? What line are you stepping into/over when it crashes? Are you running Eclipse itself with 5.0 or just the target. I was able to successfully step through all of the code on my mac. This is a VM crash. You shuold file a bug with Sun. Created attachment 31206 [details]
code sample which runs into error
Comment on attachment 31206 [details]
code sample which runs into error
The sample code runs into error with breakpoint on line #15,
the same code runs smoothly under JBuilder and Idea.
Do you consider it to be JVM error?
Yes, it shows a crash in a VM dll. This is a VM bug. This may be a compiler bug. If I compile the sample coed with an Ant builder that uses javac, I can debug it normally, but if I use Eclipse's compiler, the VM exits when the breakpoint is hit. I tested it with Apple's 1.5 VM moving to jcore for comment. You should try to disable the JIT. I think I found the problem. One of the line number attribute is boggus. If the continue; statement is removed, everything works fine again. The generation of the continue optimizes a jump to the next bytecode, but the line number table is not updated and there is an invalid pc in the table. // Method descriptor #6 ()V // Stack: 2, Locals: 3 public void buggyMethod(); 0 new java.util.HashSet [17] 3 dup 4 invokespecial java.util.HashSet() [19] 7 invokevirtual java.util.HashSet.iterator() : java.util.Iterator [20] 10 astore_2 11 goto 28 14 aload_2 15 invokeinterface java.util.Iterator.next() : java.lang.Object [24] [nargs: 1] 20 astore_1 21 getstatic java.lang.System.out : java.io.PrintStream [30] 24 aload_1 25 invokevirtual java.io.PrintStream.println(java.lang.Object) : void [36] 28 aload_2 29 invokeinterface java.util.Iterator.hasNext() : boolean [42] [nargs: 1] 34 ifne 14 37 return Line numbers: [pc: 0, line: 12] [pc: 21, line: 14] [pc: 31, line: 12] [pc: 37, line: 17] pc 31 is not a valid target. Without the continue statement, we get: // Method descriptor #6 ()V // Stack: 2, Locals: 3 public void buggyMethod(); 0 new java.util.HashSet [17] 3 dup 4 invokespecial java.util.HashSet() [19] 7 invokevirtual java.util.HashSet.iterator() : java.util.Iterator [20] 10 astore_2 11 goto 28 14 aload_2 15 invokeinterface java.util.Iterator.next() : java.lang.Object [24] [nargs: 1] 20 astore_1 21 getstatic java.lang.System.out : java.io.PrintStream [30] 24 aload_1 25 invokevirtual java.io.PrintStream.println(java.lang.Object) : void [36] 28 aload_2 29 invokeinterface java.util.Iterator.hasNext() : boolean [42] [nargs: 1] 34 ifne 14 37 return Line numbers: [pc: 0, line: 12] [pc: 21, line: 14] [pc: 28, line: 12] [pc: 37, line: 17] and all pcs in the line number table are valid targets. I am investigating. Created attachment 31816 [details]
Proposed fix
The right workaround is to remove the continue statement that is useless anyway. I checked all the Eclipse jars and none of them contains such a boggus line number table entry. Fixed and released in HEAD. Regression test added in org.eclipse.jdt.core.tests.compiler.regression.ForeachStatementTest.test038. Verified for 3.2 M5 using build I20060215-0010. |