What is the meaning/cause of *** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed?

Question

When running my test with gradle I started getting output below on the console. This output is coming from the JVM not my code. Kotlin DSL is used to configure my gradle build.

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at  line: 873
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at  line: 873
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at  line: 873
*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at  line: 873

This is happening on Java 11

java --version
openjdk 11.0.6 2020-01-14
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.6+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.6+10, mixed mode)

This output is not from my code, it seems to be from the JVM. There is no filename listed previous versions of Java seemed to have a bug related to this https://bugs.openjdk.java.net/browse/JDK-8061621

JPLISAgent.c line 873 might be what is generating the message.

UPDATE:

I went through all my CI logs to pin down the commit that introduced this issue. Tracked it down to this code in a unit test, of a Json formatter utility based on Jackson.

    // try with a circular dependencies
    Node a = new Node("a");
    Node b = new Node("b");
    a.setChild(b);
    b.setParent(a);

    assertThatExceptionOfType(JsonUtilsException.class).isThrownBy(() -> JsonUtils.toJson(a));

In particular the circular dependency triggers the JVM output. I guess Jackson really gets tripped up by circular dependency but I don't understand why that causes a JVM assertion error.

Questions: - What is the meaning of this warning/error? - What is the typical cause of this error, assertion failure in the JVM?

Answer 1

Your test is generating a very large exception cause chain.

Here is some Scala code that generates a very long exception cause chain then throws it:

val iter = Iterator.from(0).map(_.toString).map(new Exception(_))
val es = iter.take(1024 * 1024).toSeq
for {
  (e0, e1) <- es.zip(es.tail)
} {
  e0.initCause(e1)
}
//es.last.initCause(es.head) //uncomment this line for extra fun
throw es.head

This produces the same

*** java.lang.instrument ASSERTION FAILED ***: "!errorOutstanding" with message transform method call failed at JPLISAgent.c line: 844

Answer 2

The message is indeed from JPLISAgent.c:873.

It means your JVM has an agent implementing java.lang.instrument.ClassFileTransformer, and method transform(java.lang.Module, java.lang.ClassLoader, java.lang.String, java.lang.Class<?>, java.security.ProtectionDomain, byte[]) has thrown an exception.

In my case, I had both BlockHound and ByteBuddy (loaded by BlockHound). A StackOverflowError in my code triggered the loading of a new class, then both agents also threw StackOverflowError and didn't catch it. I created an issue for ByteBuddy, but I'm starting to think only the error reporting in the JDK needs to change.

Since the source of the exception is in Java code, you can attach a debugger and set a breakpoint on thrown StackOverflowError. You're very likely to find a StackOverflowError in your code or in Jackson first, and you should fix/report that.

Answer 3

I got this when I made a recursive call (without being aware) AND in addition, this call had a try/catch where I caught Throwable (the highest possible exception type). My interpretation is that my catch caught StackOverflowException (and further worked on that), which made the whole thing go crazy! When I ran it in the IntelliJ debugger, I couldn't really stop the thread - somehow the new threads were being made. As soon as I removed the recursive call, all was fine.

Answer 4

This problem also occurs when I use spring to verify the circular dependency. My code should be the error reported in the JVM. Check your code. There must be a dead loop.