Strange exception thrown running unit tests

Old Forum
1

I am encountering a “strange” (strange to me) error when running my build, specifically when running unit tests (junit). At the end of running the tests, the following is output:

Process ‘Gradle Worker 3’ finished with exit value 1 (state: FAILED) Unexpected exception thrown. org.gradle.messaging.remote.internal.MessageIOException: Could not read message from ‘/0:0:0:0:0:0:0:1:33922’.

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.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:722) 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 :source:test FAILED

FAILURE: Build failed with an exception.

  • What went wrong: Execution failed for task ‘:source:test’. > Process ‘Gradle Worker 3’ finished with non-zero exit value 1

This occurs only on linux – on windows, the tests complete just fine without any errors.

I don’t know if this is any clue – but there is now output in the testResultsDir directory even though gradle seems to have run through all the tests.

Any thoughts?

Thanks!

2

Is it predictably reproducible?

3

yes, it happens every time.

4

I’m sorry, I should have mentioned, I am using gradle 1.5

5

Is there any chance you could send us a sample build that reproduces the problem? It’s going to be tricky to track down without that.

6

Hmm… Its a rather large build file in a multi project build. Would it be enough to provide the test task configuration?

7

We can start there, but it’s like a specific test.

Something else to try would be running with ‘-i’ or ‘-d’ to try and work out if it’s a specific test case that is triggering this. Try ‘-i’ first as ‘-d’ produces a lot of output.

8

Ok, after several hours of debugging I found the cause of the error. But I still wonder if there is an issue.

it seems that in one of the tests, a runtime exception was thrown in an inner class. The test would cease, but without a failure message. The exception seems to have been swallowed.

I’d like to think a better error message is possible.

9

Sorry – correction. A subclass of java.lang.Error was thrown by the inner class

10

Was this with TestNG?

Also, could you provide a sample test class that we can use?

11

It is with junit. I will see if I can come up with a sample class. Our test case involves several layers of code so I’ll see if I can replicate it in a smaller sample

12

Thanks, that will make implementing a fix much quicker. It will be greatly appreciated.

13

Raised as GRADLE-2759.

If you can provide a sample that reproduces the problem it would be much appreciated.

14

My apologies for leaving this hanging for a few days. I traced the issue a little more carefully and discovered it does not seem to be caused by the inner class throwing a java.lang.Error.

Rather, the inner class terminates suddenly upon the exception. I had seen posts detailing how gradle does not handle System.exit calls gracefully during test execution, so I did a code scan for System.exit, but did not find any usages. However, this particular inner class calls Runtime.halt which also initiates a sudden termination of the JVM, and explains the lack of useful log message in this case.

So, now that we have found the cause, and it seems to be a known issue, is there anything we can do (besides removing the call to Runtime.halt as that is not really an option in our code base).

Thanks!

15

I had the same error, because a test was launching an System.exit 1

the stacktrace is a bit misleading.

16

I had this issue; turns out my system didn’t trust the JDK I was using (1.7.0_21). Changing ‘JAVA_HOME’ to ‘1.7.0_25’ (or whatever’s current today) did the trick.

17

This bug should really be re-opened. The error message is very misleading and is entirely an artifact of how Gradle runs unit tests. Couldn’t Gradle detect this condition and print a more friendly error?

18

Hi, Im receiving the same stacktrace after adding one test that uses mockito’s thenThrow method. Maybe related?

If I comment out the tests where I test runtime exception behaviour it does not crash.

Unexpected exception thrown. org.gradle.messaging.remote.internal.MessageIOException: Could not read message from ‘/0:0:0:0:0:0:0:1:52107’.

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:64)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NullPointerException

at java.lang.Throwable.setStackTrace(Throwable.java:864)

at org.gradle.messaging.remote.internal.Message$ExceptionPlaceholder.read(Message.java:173)

at org.gradle.messaging.remote.internal.Message$ExceptionReplacingObjectInputStream.resolveObject(Message.java:215)

at java.io.ObjectInputStream.checkResolve(ObjectInputStream.java:1398)

at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)

at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)

at org.gradle.messaging.remote.internal.Message.receive(Message.java:57)

at org.gradle.api.internal.tasks.testing.worker.TestEventSerializer$ThrowableSerializer.read(TestEventSerializer.java:113)

at org.gradle.api.internal.tasks.testing.worker.TestEventSerializer$ThrowableSerializer.read(TestEventSerializer.java:111)

at org.gradle.messaging.serialize.DefaultSerializerRegistry$TaggedTypeSerializer.read(DefaultSerializerRegistry.java:72)

at org.gradle.api.internal.tasks.testing.worker.TestEventSerializer$1.read(TestEventSerializer.java:52)

at org.gradle.api.internal.tasks.testing.worker.TestEventSerializer$1.read(TestEventSerializer.java:47)

at org.gradle.messaging.remote.internal.hub.MethodInvocationSerializer$MethodInvocationReader.readArguments(MethodInvocationSerializer.java:113)

at org.gradle.messaging.remote.internal.hub.MethodInvocationSerializer$MethodInvocationReader.read(MethodInvocationSerializer.java:108)

at org.gradle.messaging.remote.internal.hub.MethodInvocationSerializer$MethodInvocationReader.read(MethodInvocationSerializer.java:88)

at org.gradle.messaging.serialize.kryo.TypeSafeSerializer$1.read(TypeSafeSerializer.java:37)

at org.gradle.messaging.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:72)

at org.gradle.messaging.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:58)

at org.gradle.messaging.remote.internal.inet.SocketConnection.receive(SocketConnection.java:83)

… 5 more