Several errors have been noticed in the JBossTS unit tests when running with JDK7 bytecode on a JDK7 JVM. The errors do not manifest when running JDK6 bytecode on a JDK7 JVM.

It now appears that the first error is actually spurious and relates to a problem with the test case which raised it. The details have been retained for hysterical reasons, i.e.just in case something comes back to byte us.

In the first case the agent listener is blown away by an InternalError thrown under a call to Instrumentation.restranformClasses when it is trying to unload the test rules. This is bizarre as in this case the Byteman classfile transformer had successfully transformed the two classes when the rules were loaded. At unload time the transformer is called twice to retransform each of the modified classes. It finds no rules in its rule base and returns the bytecode it is handed. So, if the JVM then barfs this indicates that the bytecode handed to Byteman must have errors in it. Interestingly, the rules are being dynamically loaded by BMUnit after at least one of the affected classes is laoded. This means that the JVM will have had to reconstitute bytecode.

In the second case the same test was run by hand loading the transform rules at JVM startup (using options to -javaagent). In this case the JVM blew up during rule injection with a verify error. It claimed that the stack was invalid for one of the transformed methods. The location it identified is inside a handler block protecting injected code. The injected code can generate an ExecuteException, possibly either a ReturnException or a ThrowException which are subtypes of ExecuteException.

The injection region is at the start of the method and the corresponding block is at the end of the method after the main body of the method and the final return. The injected code is in the scope of a synchronized block so the handler executes an aload, a monitorExit and an athrow to rethrow the exception (n.b. using the correct aload slot for the monitor object). The verify error is indicated at this athrow.

The handler block region is itself mapped to 3 outer handlers which process the Byteman generated exceptions. These outer handlers directly follow the initial handler. The first one catches a rethrown ReturnException, prints a message to note that it has caught a return exception and returns (the message print is generated because Byteman verbose mode is on). The second one catches a rethrown ThrowException unpacks an exception embedded inside the ThrowException, prints a message and then rethrows the embedded exception. The third one just prints a message and rethrows the ExecuteException which is ok because it is a runtime exception.

Another piece of weirdness is that this verify error does not appear to occur in the first case even though the agent applies the exact same transformation. This is all very strange.