Bugzilla – Full Text Bug Listing
| Summary: | [compiler] compiling this code can end up with looping subroutines | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Olivier Thomann <Olivier_Thomann> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.1 | ||
| Target Milestone: | 3.2 M5 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
*** Bug 87425 has been marked as a duplicate of this bug. *** This class inlines using Sun's preverify.exe 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. Works fine in latest. We did make changes to computation of exception handler ranges to better deal with nesting scenarii. Added TryStatementTest#test038. |
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.