[GRADLE-3172] Build is reported as successful even if some tests fail before calling System.exit(0) in a subsequent test Created: 18/Sep/14  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 0


 Description   

Sorry, the buffer of my terminal got lost, and I only have this left. The rest can be found here: [1]https://twitter.com/epragt/status/512...

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

8 tests completed, 1 failed
:check
:build

BUILD SUCCESSFUL

This happened while running a test, the test executor stopped, giving the above stacktrace. When doing another 'gradlew build', the execution was immediately successful, even though I have one failing test case, which showed up again after doing a 'gradlw clean build'.
----------------------------------------------------------------------------------------
[1] https://twitter.com/epragt/status/512163337430638592



 Comments   
Comment by Gradle Forums [ 18/Sep/14 ]

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.

Comment by Gradle Forums [ 18/Sep/14 ]

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

Comment by Gradle Forums [ 18/Sep/14 ]

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.

Comment by Gradle Forums [ 18/Sep/14 ]

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

Comment by Gradle Forums [ 18/Sep/14 ]

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.

Comment by Gradle Forums [ 18/Sep/14 ]

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.

Comment by Gradle Forums [ 18/Sep/14 ]

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.

Comment by Gradle Forums [ 18/Sep/14 ]

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.

Comment by Gradle Forums [ 18/Sep/14 ]

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

Comment by Gradle Forums [ 18/Sep/14 ]

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

Comment by Gradle Forums [ 18/Sep/14 ]

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.

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Benjamin Muschko [ 10/Feb/17 ]

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.

Generated at Wed Jun 30 12:41:51 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.