I will try to reproduce the problem on the simplest setup: gradle + java-app + junit.
Then we go step by step to isolating the problem.

I created the simplest project, allowing to test gradle + junit:
[1]https://github.com/akhikhl/testtest

Please do:

• `git clone [2]https://github.com/akhikhl/testtest.git`
• `cd testtest`
• `gradle build`

Does it show "BUILD FAILED" for you?
----------------------------------------------------------------------------------------
[1] https://github.com/akhikhl/testtest
[2] https://github.com/akhikhl/testtest.git

Erik,

Is your code public? If not, would it be possible to make it public? We will need to have a look at it to be able to investigate.

Based on what information is available in the stacktrace I can tell that the buffer underflow you're seeing is some kind of a problem with communication between the build process and the worker process running the tests. Having a look at the code will probably reveal more.

Does com.esotericsoftware.kryo.io.Input communicate to gradle classes? If not, maybe it is using the same ports?

Hi guys, I'm actually able to reproduce it, in a very nasty way.

I have a project with a failing test. What I also have, is another test, with a Thread.sleep(10000) in it, which first opens a Swing console, and then starts waiting. I forgot that the code was there, and thought my system was hanging or something. So what I did was:

1) ./gradlew build
2) the first test fails
3) the second test seems to hang, so I pressed CMD+Q
4) result:

nl.jworks.color.DominantColorFinderTest > testTwoColors FAILED
java.lang.AssertionError at DominantColorFinderTest.java:27

8 tests completed, 1 failed

BUILD SUCCESSFUL

I can share the code, but I rather not put it on Github, because right now it's not hubworthy.

Do you get the same stacktrace from above? The one with the org.gradle.messaging.remote stuff in it?
I bet what's happening is the worker running the tests is dying before it sends the results back to the main thread. That's then getting interpreted as 'no errors' which is marking the build as success.

Hi John,

Also thanks for the reply! Yes, I get indeed the same error. It makes sense that it works like that, but from a user perspective, it's a bit weird. I mean, I assume the build systems knows that it kicked off the test to start with, and interpreting 'no results' as 'everything is fine' is a bit unexpected, but I might be totally having the wrong idea here. Anyway, it's not so important, though I'm curious if there are other scenarios where this might be a problem. If not, then just close this issue, I'd say.

I agree that that is odd and if that is in fact what is happening, it's probably a bug that should be fixed.
The more curious question is why you're test seems to be killing the worker.

I think that's because I am not killing my Swing UI, which is popping up, but instead it seems I'm killing GradleWorkerMain.

You doing a System.exit(0) or something like that?

Something like that. Cmd+Q, which I think is (almost?) equal to System.exit(). I did it because I thought my test was hanging, then this happened.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.