Bug 106402 - [1.4][compiler] Wrong code gen for finally block
Summary: [1.4][compiler] Wrong code gen for finally block
Status: RESOLVED INVALID
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: vm
: 115636 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-08-08 16:01 EDT by Olivier Thomann CLA
Modified: 2005-11-09 10:03 EST (History)
1 user (show)

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-08-08 16:01:47 EDT
Using latest in 1.4 compliance mode, the following code leads to a VerifyError.

public class X {
	int test(boolean b) {
		int i;
		try {
			if (b) {
				i = 1;
				return 1;
			}
			i = 2;
		} finally {
			if (b)
				i = 3;
		}
		return i;
	}

	public static void main(String[] args) {
		X t = new X();
		t.test(false);
	}
}
Comment 1 Olivier Thomann CLA 2005-08-08 16:10:40 EDT
I believe this is a bug in the bytecode verified when handling subroutines.
jikes also produces a .class file that fails to verify when using jsr/ret bytecodes.
javac 1.3.1 has the same bug.
If javac 1.5.0 is used. Subroutines are inlined and the error doesn't occur.

When using Eclipse compiler in 1.5 compliance mode, the subroutines are inlined
and the code doesn't fail anymore.
Using the 1.4 compliance mode with the -inlineJSR option fixes it.

I can successfully run a .class file that is using jsr/ret bytecodes using a J9 VM.

I don't see anything wrong with the bytecodes so I would be tempted to close as
a bytecode verifier problem.
Comment 2 Philipe Mulet CLA 2005-08-09 05:07:29 EDT
Also note that javac 1.4.2_08 is also performing JSR inlining, thus hiding this
issue.

When JSR opcodes are generated, we produce:

  // Method descriptor #15 (Z)I
  // Stack: 1, Locals: 5
  int test(boolean b);
     0  iload_1 [b]
     1  ifeq 11
     4  iconst_1
     5  istore_2 [i]
     6  jsr 24
     9  iconst_1
    10  ireturn
    11  iconst_2
    12  istore_2 [i]
    13  goto 33
    16  astore 4
    18  jsr 24
    21  aload 4
    23  athrow
    24  astore_3
    25  iload_1 [b]
    26  ifeq 31
    29  iconst_3
    30  istore_2
    31  ret 3
    33  jsr 24
    36  iload_2 [i]
    37  ireturn
      Exception Table:
        [pc: 0, pc: 9] -> 16 when : any
        [pc: 11, pc: 16] -> 16 when : any
        [pc: 33, pc: 36] -> 16 when : any
      Local variable table:
        [pc: 0, pc: 38] local: this index: 0 type: X
        [pc: 0, pc: 38] local: b index: 1 type: boolean
        [pc: 6, pc: 11] local: i index: 2 type: int
        [pc: 13, pc: 16] local: i index: 2 type: int
        [pc: 36, pc: 38] local: i index: 2 type: int

where javac [1.3.1] is producing 

  // Method descriptor #11 (Z)I
  // Stack: 1, Locals: 6
  int test(boolean arg);
     0  iload_1
     1  ifeq 13
     4  iconst_1
     5  istore_2
     6  iconst_1
     7  istore_3
     8  jsr 29
    11  iload_3
    12  ireturn
    13  iconst_2
    14  istore_2
    15  jsr 29
    18  goto 39
    21  astore 4
    23  jsr 29
    26  aload 4
    28  athrow
    29  astore 5
    31  iload_1
    32  ifeq 37
    35  iconst_3
    36  istore_2
    37  ret 5
    39  iload_2
    40  ireturn
      Exception Table:
        [pc: 0, pc: 21] -> 21 when : any
      Line numbers:
        [pc: 0, line: 5]
        [pc: 4, line: 6]
        [pc: 6, line: 7]
        [pc: 13, line: 9]
        [pc: 21, line: 11]
        [pc: 35, line: 12]
        [pc: 39, line: 14]

and both are rejected by a Sun 1.4.2 VM bytecode verifier.
Comment 3 Philipe Mulet CLA 2005-08-09 05:09:56 EDT
Both generated classfiles are flagged with following verify error:

Exception in thread "main" java.lang.VerifyError: (class: X, method: test
signature: (Z)I) Register 2 contains wrong type
Comment 4 Philipe Mulet CLA 2005-08-09 05:23:26 EDT
This is a known VM bug, also see:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4381996

Other VMs do not have this bug (like J9).
Comment 5 Olivier Thomann CLA 2005-11-09 10:03:33 EST
*** Bug 115636 has been marked as a duplicate of this bug. ***