Buffer underflow within Gradle masks build errors

The failure below occurs sometimes and fails the build. This seems to mask the actual failure, like a test, so we have to use debug mode to try to uncover the likely problem. This happens in both v1.6 and v1.7, and I think began around the time we started using Kryo in our application (v2.21) and perhaps that clashes somehow.

14:50:58.567 [ERROR] [org.gradle.messaging.remote.internal.hub.MessageHubBackedServer] Unexpected exception thrown.
org.gradle.messaging.remote.internal.MessageIOException: Could not read message from '/0:0:0:0:0:0:0:1:43185'.
    at org.gradle.messaging.remote.internal.inet.SocketConnection.receive(SocketConnection.java:88)
    at org.gradle.messaging.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:230)
    at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
    at java.lang.Thread.run(Thread.java:662)
Caused by: com.esotericsoftware.kryo.KryoException: Buffer underflow.
    at com.esotericsoftware.kryo.io.Input.require(Input.java:162)
    at com.esotericsoftware.kryo.io.Input.readByte(Input.java:255)
    at org.gradle.messaging.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:64)
    at org.gradle.messaging.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:53)
    at org.gradle.messaging.remote.internal.inet.SocketConnection.receive(SocketConnection.java:83)
    ... 5 more

What have the masked exceptions thrown by tests been like in such cases? Also something related to (your own code’s use of) kyro?

Nope, never a kryo related issue. Most often they’ve been due to an initialization error in the test class, e.g. a bad Guice binding. The TestNG @Guice annotation is used to inject into the class, but it doesn’t fail gracefully. Unfortunately I have a case that fails on Jenkins but not locally, which my only guess atm is it may be due to Jacoco byte code instrumentation.

Hey Benjamin, did you find out the real cause for this?