Bug 155887 - Breakpoint in 'finally' not hit - test suite failing
Summary: Breakpoint in 'finally' not hit - test suite failing
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: 3.2.1   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-31 15:14 EDT by Darin Wright CLA
Modified: 2006-09-18 10:12 EDT (History)
1 user (show)

See Also:


Attachments
Proposed fix (1.41 KB, patch)
2006-08-31 16:34 EDT, Olivier Thomann CLA
no flags Details | Diff
Proposed fix for 3.2 maintenance branch (1.42 KB, patch)
2006-08-31 18:08 EDT, Olivier Thomann CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Wright CLA 2006-08-31 15:14:08 EDT
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

}
Comment 1 Darin Wright CLA 2006-08-31 15:15:30 EDT
Note, this only seems to happen on Linux.
Comment 2 Darin Wright CLA 2006-08-31 15:35:12 EDT
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.

Comment 3 Darin Wright CLA 2006-08-31 15:38:58 EDT
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.
Comment 4 Olivier Thomann CLA 2006-08-31 15:47:59 EDT
I'll investigate.
Comment 5 Olivier Thomann CLA 2006-08-31 15:54:58 EDT
Indeed the line number for bytecode 44 looks suspicious. I am investigating.
Comment 6 Olivier Thomann CLA 2006-08-31 16:34:13 EDT
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.
Comment 7 Olivier Thomann CLA 2006-08-31 16:35:59 EDT
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.
Comment 8 Olivier Thomann CLA 2006-08-31 18:08:14 EDT
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.
Comment 9 Olivier Thomann CLA 2006-08-31 18:08:32 EDT
Created attachment 49227 [details]
Proposed fix for 3.2 maintenance branch
Comment 10 Philipe Mulet CLA 2006-09-01 06:35:14 EDT
+1 for 3.2.1. Indeed, we did not associate the #goto opcode as we should have.
Comment 11 Philipe Mulet CLA 2006-09-01 06:35:37 EDT
pls release in 3.2.1
Comment 12 Olivier Thomann CLA 2006-09-01 08:02:28 EDT
Released for 3.2.1.
Existing tests have been updated.
Comment 13 David Audel CLA 2006-09-12 04:30:22 EDT
Verified for 3.2.1 using build M20060908-1655
Comment 14 Maxime Daniel CLA 2006-09-18 10:12:58 EDT
Verified for 3.3 M2 using build I20060918-0010.