Bug 24315 - Verification failure when nested finally blocks
Summary: Verification failure when nested finally blocks
Status: RESOLVED FIXED
Alias: None
Product: BCEL - Now in Jira
Classification: Unclassified
Component: Main (show other bugs)
Version: 5.1
Hardware: All All
: P3 major
Target Milestone: ---
Assignee: issues@commons.apache.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-01 02:19 UTC by David Foster
Modified: 2004-11-16 19:05 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Foster 2003-11-01 02:19:34 UTC
The following code will not pass that JustIce verifier. Code was compiled with Sun's standard 
compiler (v 1.4.1).

SOURCE CODE:
public class Test55 {
	public void foo(int arg0, int arg1) {
		try {
			try {
				arg0 /= arg1;
			} finally {
				arg0 = arg0;
			}
		} finally {
			arg1 = arg1;
		}
	}
}

OUTPUT:
Verifying: Test55

Verification Errors:
#0:
    Constraint violated in method 'public void foo(int arg1, int arg2)':
    Subroutine instruction '  16: astore[58](2) 4' is protected by an exception handler, 
'CodeExceptionGen(   0: iload_1[27](1),   22: jsr[168](3) -> astore 6,   28: astore[58](2) 5)'. This is 
forbidden by the JustIce verifier due to its clear definition of subroutines.

Verification failed
Comment 1 Enver Haase 2003-11-02 19:31:57 UTC
This is *NOT* a bug. It's an intended incompatibility with Sun's verifier
that will be present as long as Sun does not correctly specify what exactly
the verifier should do in this situation.
Remember JustIce is a cleanroom implementation, so I will not look into
Sun's code to find out what *they* do. They should update their "vmspec2" book.
Please read my paper on JustIce for details - this incompatibility is sort
of a "core" of the 'subroutine' definition I made up on my own since Sun did not.
Enver