Compiling a method expression can occasionally give rise to a VerifyError being notified for execute0, the compiled method which implements the rule body. This is because the method's declared stack height is smaller than the height attained during execution. The problem only happens when a method call which attains the high-water mark for the stack height during the execute0 call results in a higher stack height after the call than before the call.

For example, instance method Thread.getId() will pop a thread instance and push a long, the former taking two slots and the latter taking only one. So, when executing the call to getId the stack height is higher after the call. In the following rule this call also happens to attain the maximum stack height for all the bytecode generated to implement execute0:

RULE example
CLASS foo
METHOD bar()
BIND id : "" + Thread.currentThread.getId()
IF TRUE
DO traceln(id);
ENDRULE

The problem is that the Byteman bytecode compiler inserts a call to static methods Rule.enableTriggersInternal()Z and Rule.disableTriggersInternal()Z around the call which implements the method expression. Each of these calls adds a boolean return value to the stack which is popped because it is not used. The extra stack slot used by the return value from the first call is allowed for when calculating the maximum stack height. However, the current code incorrectly assumes that the stack will be lower after the method expression has been executed than before, hence that there is no need to make allowance for the slot used by return value from the second call when calculating the stack maximum.

The fix simply requires bumping up and then decrementing the stack height around the second call and ensuring the stack maximum is updated if the height exceeds the previous high-water mark.