Dealing with Try/Catch Exceptions in Java bytecode? (“stack height inconsistent”)

Question

I am trying to do some error handling in java bytecode. I first tried to implement some catch-like subroutines, where I would check for the error condition, and jump to the appropriate subroutine, a little like:

  iconst_1
  iconst_0
  dup
  ifeq calldiverr
  goto enddivtest
calldiverr:
  jsr divError
enddivtest:
  idiv

...More instructions...

divError:
  getstatic java/lang/System/out Ljava/io/PrintStream;
  ldc "Oh dear you divided by 0!"
  invokevirtual java/io/PrintStream/print(Ljava/lang/String;)V

The problem with the above is that when I have multiple instructions that jump to this subroutine, I get an error message when running the bytecode, saying that the stack height is inconsistent.

Perhaps using exceptions is the best way to get around this?

From some googling I have found that you can create instances of Exception classes and initialise them with something like:

new java/lang/Exception
dup
ldc "exception message!"
invokespecial java/lang/Exception/<init>(Ljava/lang/String;)V

I have also found that you can throw them with athrow and this seems ok.

What is confusing me however is exactly how exceptions are caught. There seems to be a magical "Exception table" which glues the throwing and catching of exceptions together, but I do not know how to define one of these when writing bytecode from scratch (and assembling using Jasmin). Can somebody tell me the secret of creating an exception table? And possibly give me an example of exception handling that will assemble with jasmin?

Answer 1

In the end I came up with a better solution than jsr - defining a method using .method in Jasmin. I just used invokestatic to call my error handler once I had detected the error.

For those looking for actual exception handling - I think that defining the exception table in Jasmin may be done using .catch, but I haven't looked into it as the method definition solved my problem.

Edit:

I did have to look at .catch in the end, and found it is really easy to use. It's documented here.

Answer 2

First off its worth pointing out that class files from version 51.0 may not contain the jsr instruction. Repeat the code or use a method.

At every point in bytecode, the static type of every element in the frame must be known. Each frame is not a call stack.

Generally you don't want to play around with huge big stacks. Store temporaries in local variables to keep things simple.

If an exception is thrown then obviously the frame might have had the contents from any place the exception could have thrown. So the contents are discarded and replaced by the exception. You wouldn't be able to go back and resume to use the frame contents anyway.

Answer 3

The rules for verifying jsr are pretty complicated, and as Tom indicated the opcode is deprecated. So it's best avoided.

My memory on jsr is a bit fuzzy, but ...

(Updated) There is a rule in Java bytecode verification that wherever two control flows join together the stack depth must be identical along both branches. jsr subroutines are exempted from this rule to a point -- multiple exception points with different stack depths can "reach" the same jsr routine, but the net change in stack depth from jsr routine entry to subsequent ret must be zero (or actually minus 1, since the exception cause is always pushed on entry to the routine).

Further, while a jsr routine can "escape" and branch back into regular control flow, if it does so the jsr is not exempted from the stack depth rule for join points. This severely limits the situations where you can do this, since a jsr routine can potentially be entered with different stack depths.

(And I've no doubt still got some of that wrong, but it's the best I can do.)

(I don't quite understand how you're planning to "get around" your jsr problem with exceptions.)

(Also, Sun made bytecode writing much more complicated with 4 or 5 (can't remember which), making it pretty much impossible to hand-code bytecodes. They did this because they didn't know how to do verification fast enough to beat IBM's verifier otherwise, but that's another matter.)