Community
Participate
Working Groups
I20060830 There have been 3 consistent test failures in the nightly and integration builds on linux for Java 5.0. The 3 failing tests are all attempting to hit a breakpoint in a finally block, but the breakpoint is never hit. The same thing happens when debugging the following code with project compiler settings set to 5.0. ------------------------ import java.util.Vector; public class Finally { public static void main(String[] args) { Vector v = new Vector(); try { v.get(24); } catch (ArrayIndexOutOfBoundsException e) { } finally { System.out.println("finally 1"); // BREAKPOINT } } } -------------------------- Notes: * It appears that the breakpoint gets installed properly: the line numbers from javap show to locations for line 13 (println above). We install breakpoint requests for each location. * When I compile the same class with Sun's javac, I get different line number mappings, but then the brealpoint *is* hit. It is expected that different compilers will have different line mappings, but since the breakpoint is hit using the javac result, I wonder if this is a compiler bug. ------------------------------------------- The line mappings when using the Eclispe compiler are: Compiled from "Finally.java" public class Finally extends java.lang.Object{ public Finally(); LineNumberTable: line 4: 0 LocalVariableTable: Start Length Slot Name Signature 0 5 0 this LFinally; public static void main(java.lang.String[]); LineNumberTable: line 7: 0 line 9: 8 line 10: 18 line 12: 22 line 13: 23 line 14: 31 line 13: 33 line 12: 44 line 15: 52 LocalVariableTable: Start Length Slot Name Signature 0 53 0 args [Ljava/lang/String; 8 45 1 v Ljava/util/Vector; } ------------------------------------------ The line mappings when using javac are: sh-3.00$ ~/jdk1.5.0_08/bin/javap -classpath . -l Finally Compiled from "Finally.java" public class Finally extends java.lang.Object{ public Finally(); LineNumberTable: line 4: 0 public static void main(java.lang.String[]); LineNumberTable: line 7: 0 line 9: 8 line 13: 15 line 14: 23 line 10: 26 line 13: 27 line 14: 35 line 13: 38 line 14: 47 line 15: 49 }
Note, this only seems to happen on Linux.
I was wrong, the same problem occurrs on Windows (with compiler options set to 5.0) - there are just no automated tests that show the failure for windows.
JCore, could you verify the line number attributes being set for this test case. It appears the debugger is retrieving the line number attributes as stored in the classfile, but that the debugger never hits the breakpoint with those attributes.
I'll investigate.
Indeed the line number for bytecode 44 looks suspicious. I am investigating.
Created attachment 49214 [details] Proposed fix The fix adds a line number entry for the goto between the two finally blocks. This forces the second finally block to add its own line numebr entry again on the right line. Darin confirmed that this is fixing the issue.
Philippe, I'll release for 3.2 maintenance and HEAD if you don't mind. Both streams have the same problem. Since Darin said this was intermittent for a long time, I believe we had a similar problem prior to the fix for the stack map table.
Fixed and released in HEAD. Released for 3.3M2. Philippe, +1 for 3.2.1? I'll attach the patch for the 3.2 maintenance stream.
Created attachment 49227 [details] Proposed fix for 3.2 maintenance branch
+1 for 3.2.1. Indeed, we did not associate the #goto opcode as we should have.
pls release in 3.2.1
Released for 3.2.1. Existing tests have been updated.
Verified for 3.2.1 using build M20060908-1655
Verified for 3.3 M2 using build I20060918-0010.