Bugzilla – Full Text Bug Listing
| Summary: | [compiler] VerifyError: Inconsistent stackmap frames at branch target x in method y at offset z. | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Carsten Otto <eclipse> |
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
| Status: | VERIFIED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | amj87.iitr, eclipse, jarthana, remy.suen, srikanth_sankaran |
| Version: | 3.7.1 | ||
| Target Milestone: | 3.7.2 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
This seems to have been fixed. I'm trying to find the bug which fixed this. Full test case:
// ---
import java.util.LinkedHashSet;
public class X {
private static boolean foo() {
try {
for (final Object x : new LinkedHashSet<>()) {
if (x instanceof Object) {
return false;
}
}
return false;
} finally {
foo();
}
}
public static void main(String [] args) {
System.out.println("Done");
}
}
//---
This fails to verify on 3.7.1, but run alright with
3.7.2 RC2 Build id: M20120118-0800.
Several verify errors have been fixed in the interim, I'll
see if I dig up the duplicate.
Confirmed that fix for 359495 also fixes this *** This bug has been marked as a duplicate of bug 359495 *** Verified for 3.7.2RC2 using build M20120118-0800 This seem to have been missed out in our M5 verification. Marking it for M6. Verified for 3.8 M6 using build I20120312-0800. |
Build Identifier: Version: Indigo Service Release 1 Build id: 20110916-0149 The code compiled for the following method cannot be verified. Based on the created .class file the finally-block is reached with at least two paths: a) a local variable filled with "x" b) no local variable for "x" This seems to be the problem for the bytecode verifier. Oracle's compiler creates two versions of the finally block. private static boolean foo() { try { for (final Object x : new LinkedHashSet<>()) { if (x instanceof Object) { return false; } } return false; } finally { foo(); } } Reproducible: Always Steps to Reproduce: 1. Create a class containing the above code 2. Call the method from some (other?) class 3. At runtime see the VerifyError as soon as the invocation is executed