Bug 87423 - [compiler] compiling this code can end up with looping subroutines
Summary: [compiler] compiling this code can end up with looping subroutines
Status: RESOLVED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.2 M5   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 87425 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-03-08 14:34 EST by Olivier Thomann CLA
Modified: 2006-02-03 05:22 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thomann CLA 2005-03-08 14:36:05 EST
public class LoopJsr {

	int hasLoop() {
		int l, m, n;
		for (m = 0; m < 10; m++) {
			n = 2;
			try {
				n = 3;
				try {
					n = 4;
				} catch (java.lang.ArithmeticException e1) {
					n = 11;
				} finally {
					for (l = 0; l < 10; l++) {
						n++;
					}
					if (n == 12) {
						n = 13;
						break;
					}
					n = 15;
				}
			} catch (java.lang.OutOfMemoryError e2) {
				n = 18;
			}
		}
		return 0;
	}

	public static void main(String args[]) {
      System.out.println("Loaded fine");
   }
}

Compiling this code can lead to a looping call of subroutines.
The bytecode verifier doesn't find any problem with the generated code.

So this might be ok, but it is worth checking that our generated code is all right.
Comment 1 Olivier Thomann CLA 2005-03-08 15:01:17 EST
*** Bug 87425 has been marked as a duplicate of this bug. ***
Comment 2 Mark Bottomley CLA 2005-03-09 16:36:59 EST
This class inlines using Sun's preverify.exe
Comment 3 Mark Bottomley CLA 2005-03-14 12:00:27 EST
I have modified the J9 VM to handle the "looping" subroutine. A path through an 
exception (Where the exception can be reached outside the jsr) unofficially end 
the jsr. I make this as an observation, not something I can identify in the 
specification.
Comment 4 Philipe Mulet CLA 2006-02-03 05:22:04 EST
Works fine in latest. We did make changes to computation of exception handler ranges to better deal with nesting scenarii.
Added TryStatementTest#test038.