Buffer underflow within Gradle masks build errors

Old Forum Archive
1

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
2

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

3

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.

4

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