Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 190209

Summary: [compiler] Optimizing out exception handlers can lead to unreachable bytecodes
Product: [Eclipse Project] JDT Reporter: Olivier Thomann <Olivier_Thomann>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3    
Version: 3.3   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
Whiteboard: stalebug
Attachments:
Description Flags
Changes in progress none

Description Olivier Thomann CLA 2007-05-31 09:20:17 EDT
Using v_766, in some cases exception handlers are optimized out, but the corresponding finally or catch blocks are still generated.
This leads to dead bytecodes.

1) The following example leads to unreachable bytecodes from pc 10 to 17.

public class X {
	final int i;
	X() {
	    try {
			return; // intervening finally assigns i
	    } finally {
			i = 1;
	    }
	}
	public static void main(String[] args) { 
		System.out.println("OK"); 
	} 
}

  X();
     0  aload_0 [this]
     1  invokespecial Object() [10]
     4  aload_0 [this]
     5  iconst_1
     6  putfield X.i : int [12]
     9  return
    10  astore_1
    11  aload_0 [this]
    12  iconst_1
    13  putfield X.i : int [12]
    16  aload_1
    17  athrow
      Line numbers:
        [pc: 0, line: 3]
        [pc: 4, line: 7]
        [pc: 9, line: 5]
        [pc: 10, line: 6]
        [pc: 11, line: 7]
        [pc: 16, line: 8]
      Local variable table:
        [pc: 0, pc: 18] local: this index: 0 type: X
      Stack map table: number of frames 1
        [pc: 10, full, stack: {Throwable}, locals: {X}]

The finally block should not be generated or the exception handler should not be optimized out.

2) final public class X
{
    final class MyClass
    {
        void method1(final String s)
        {
        }
    }

    Object method1()
    {
        try
        {
            final MyClass myClass = null;

            try
            {
                return null;
            }
            catch (final Throwable ex)
            {
                myClass.method1(this == null ? "" : "");
            }

            return null;
        }
        finally
        {
            {
            }
        }
    }
    public static void main(String[] args) {
		System.out.print("SUCCESS");
	}
}

In this case the problem comes from the catch block.

  // Method descriptor #15 ()Ljava/lang/Object;
  // Stack: 2, Locals: 3
  Object method1();
     0  aconst_null
     1  astore_1 [myClass]
     2  aconst_null
     3  areturn
     4  pop
     5  aload_1 [myClass]
     6  aload_0 [this]
     7  ifnonnull 15
    10  ldc <String ""> [16]
    12  goto 17
    15  ldc <String ""> [16]
    17  invokevirtual X$MyClass.method1(String) : void [18]
    20  aconst_null
    21  areturn
    22  astore_2
    23  aload_2
    24  athrow
      Exception Table:
        [pc: 0, pc: 2] -> 22 when : any
        [pc: 4, pc: 20] -> 22 when : any
      Line numbers:
        [pc: 0, line: 14]
        [pc: 2, line: 18]
        [pc: 4, line: 20]
        [pc: 5, line: 22]
        [pc: 20, line: 25]
        [pc: 22, line: 28]
        [pc: 23, line: 31]
      Local variable table:
        [pc: 0, pc: 25] local: this index: 0 type: X
        [pc: 2, pc: 22] local: myClass index: 1 type: MyClass
      Stack map table: number of frames 5
        [pc: 4, full, stack: {Throwable}, locals: {X, X$MyClass}]
        [pc: 15, same_locals_1_stack_item, stack: {X$MyClass}]
        [pc: 17, full, stack: {X$MyClass, String}, locals: {X, X$MyClass}]
        [pc: 20, same]
        [pc: 22, full, stack: {Throwable}, locals: {X}]

Bytecodes from 4 to 21 are unreachable because the exception handler for the catch block has been optimized out.
Comment 1 Philipe Mulet CLA 2007-07-16 11:10:21 EDT
Created attachment 73850 [details]
Changes in progress

Mostly cleanup, and tests.
Comment 2 Olivier Thomann CLA 2007-08-31 17:18:09 EDT
The fix for bug 185350 added a check to optimize out the catch block generation when an exception handler is optimized out.
This should not be required. It is more a sanity check.
So some tests in TryStatementTests are expected to be updated once this is fixed.
Comment 3 Eclipse Genie CLA 2019-09-18 10:23:05 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.