JVM exceptions are weird: a decompiler perspective

Some time ago, I attempted to decompile Java class files in a more efficient way than traditional solutions like Vineflower. Eventually, I wrote an article on my approach to decomposing control flow, which ended up giving a great performance boost to my prototype.

At the time, I believed that this method could be directly extended to handle exceptional control flow, i.e. decompiling. try,catch Block. Looking back, I should have known it wouldn’t be that easy. This shows that there are many strange cases ranging from strange to strange. javac The behavior results from the JVM design and class file format, which makes it quite complex. In this post, I’ll cover the details of why simple solutions don’t work, and which approach I ultimately decided on.

JVM is a stack-based language. Most instructions interact specifically with the stack, for example iadd Remove two integers from the top of the stack and push their sum back. Like, a handful of instructions if_icmpeqTransfer control to a given address based on some primitive condition (for example). value1 == value2 In this case). It is enough to implement if, whileAnd many other explicit control flow constructs.

However, there is exceptional control flow underlying it, so it cannot be controlled in the same way. even one try The block must catch all exceptions raised within its scope, regardless of whether they are exceptions forwarded from a method call. invokevirtualDivision by zero idivor in void pointer dereference getfieldSuch relations cannot be efficiently encoded in bytecode, so they are stored separately, exception table,

Each entry in the exception table specifies which area of ​​the instruction is associated with which exception handler. If an exception is raised in such a field, the stack is cleared, the exception object is pushed onto the stack, and control is transferred to the first instruction of the handler.

For example, here’s what the bytecode and exception table looks like for a simple method try,catch block (built with) javap -c,

static void method() {
    try {
        System.out.println("Hello, world!");
    } catch (Exception ex) {
        System.out.println("Oops, an error happened");
    }
}

Code:
   
   0: getstatic     #7                  
   3: ldc           #13                 
   5: invokevirtual #15                 
   
   8: goto          20
   
   
  11: astore_0
   
  12: getstatic     #7                  
  15: ldc           #23                 
  17: invokevirtual #15                 
   
  20: return
Exception table:
   from    to  target type
   
   
       0     8    11   Class java/lang/Exception

If there are multiple rows in the exceptions table, the first matching row is used. For example, if nested try block, inner try The block will be listed first, followed by the outer block.

Note that the exceptions table is just a list of fields. The JVM does not impose any requirements on the nesting structure of those fields: for example, it is possible for two ranges to intersect without being nested in each other, and it is possible target to be first from or even in from,to Category.

As we will see shortly, this is not a hypothetical, and real-world layer files often violate these “obvious” assumptions. This makes it important to handle the problem well, not only if you are building an unconditionally perfect decompiler, as I am trying to do, but building any decompiler.

Before we tackle this, we need to discuss how javac handles this try,finally Block. body of finally Must be executed regardless of whether an exception is thrown, but where control is transferred after it terminates finally The presence of the exception depends on:

It is not clear how finally The block must know where to move the control next. One option is to store the potential exception in a hidden variable to rethrow and treat. null as a sign that try The block completed without any exceptions, but this is not enough. A try Blocks may have exit points in addition to fallthrough: continue, breakand even return There may be exit points, each requiring a separate post-finally Target. Handling this properly would require a jump table, which is likely to be slow, not to mention confusing JIT compilers and static analyzers, which also involves verifying in the JVM that uninitialized variables are not accessed.

instead, javac The cursed and the genius do something together: it imitates finally Body at each exit path. Let’s consider the following snippet:

static void method() {
    try {
        try_body();
    } catch (Exception ex) {
        throw ex;
    } finally {
        finally_body();
    }
}

Code:
   0: invokestatic  #7                  
   3: invokestatic  #12                 
   6: goto          18
   9: astore_0
  10: aload_0
  11: athrow
  12: astore_1
  13: invokestatic  #12                 
  16: aload_1
  17: athrow
  18: return
Exception table:
   from    to  target type
       0     3     9   Class java/lang/Exception
       0     3    12   any
       9    13    12   any

First, javac believes that try The body may fall, so it adds a call finally_body right after try body, followed for a leap return, catch The body cannot fall, therefore finally_body is not inserted after 11: athrow,

other thing, javac believes that try The body may throw, so it wraps it in a catch-all handler (0 3 12 any in the table) which saves the thrown exception, call finally_bodyAnd then re-throws the saved exception. Similarly, catch The body can throw, so it’s also wrapped in a catch-all handler (9 13 12 any on the table).

For whatever reason, the scope of this last catch-all handler additionally covers the handler’s first instruction as well. I’ve narrowed it down to one suspicious line javac code, but it’s been there for so long, I doubt anyone will want to touch it. Even if this is fixed at some point, older category files will still suffer from this problem, so it’s not like we can expect to forget about it.

Now, it may seem that astore_1 Can’t throw instructions, so this should be easy to fix during parsing – just reduce to To target If there is no instruction in the range target,to Can throw. But the implications of this decision are broader than it seems.

for one thing, Any JVM can throw instructionsThe JVM specification is very clear about this: VirtualMachineError ,[…] “May be thrown at any time during the operation of the Java Virtual Machine”. VirtualMachineError Like there’s a superclass of bangers OutOfMemoryError And StackOverflowErrorAnd I don’t think it’s hard to imagine a JVM interpreter that throws StackOverflowError When a JVM-internal function runs out of stack, or OutOfMemoryError If any ad-hoc allotment fails. even astore_1 This can be a real throw off if the array of locals is allocated on demand. At least we won’t have to deal with it Thread.stop Throwing arbitrary exceptions at arbitrary points since Java 20.

But a false positive (ie catching an exception when it shouldn’t be caught) is just part of the problem. A false negative can also occur under certain conditions. consider the following:

static int method(boolean condition) {
    try {
        if (condition) {
            return 1;
        }
    } finally {
        finally_body();
    }
    return 2;
}

The main goal here is to make return statement within one try,finally block. When if (condition) parts and initialization 1 will be covered by try Area, return Self must be preceded by a call finally_bodywhich should be located outside tryso where is it return Do the instructions run on their own? it turns out that javac Generates out of try block:

try {
    if (condition) {
        return 1;
    } else {
        return 2;
    }
} finally {
    finally_body();
}

try {
    if (condition) {
        return 1;
    } else {
        return 2;
    }
} catch (Exception ex) {
    return 3;
}

Code:
   0: iload_0
   1: ifeq          6
   4: iconst_1
   5: ireturn 
   6: iconst_2
   7: ireturn
   8: astore_1
   9: iconst_3
  10: ireturn
Exception table:
   from    to  target type
       0     5     8   Class java/lang/Exception
       6     7     8   Class java/lang/Exception

try #1 {
    if (condition) {
        int tmp = 1;
        exempt #1 {
            return tmp;
        }
    } else {
        int tmp = 2;
        exempt #1 {
            return tmp;
        }
    }
} catch (Exception ex) {
}
return 3;