Gradle hangs indefinately after finishing tests run in parallel

I have almost 4000 tests run by Gradle’s parallel threads test run functionality.

When the tests have finished running, the execution (in Jenkins) hangs for a long while. At the moment, I have a build hanging from last night, so it’s been hanging for more than eight hours. There’s no activity, and no db-connections.

We run exactly the same tests through ant, with no hanging or other problems.

If we kill the process manually, the following is written to the Jenkins log file. Are you able to deduce anything from this information?

Stacktraces from both parent and child processes:

Regards /Jesper Thuun-Petersen

We may be seeing the same thing. The tests run fine under ant, but when we run them under Gradle they appear to run for awhile and then the process just hangs. I haven’t had time to investigate further, but it sounds like the same issue.

Does anyone know anything more about this?

Yes, in the past I have encountered this problem before. I found that it is caused by not closing objects correctly at the end of tests. In other words, a object that was instantiated during a test is remaining open and so Gradle wont finish until you mark/delete it properly so it can be garbage collected.

We’ve sort of fixed this issue. As I’ve reported earlier, we have problems with gradle throwing stackOverflowExceptions when certain exceptions escape our tests:

Apparently, we had a part of our testcode not wrapped in the harness the Gradle folks recommended to work around the overflow-bug, and when we safe guarded this piece of code as well, the hanging problem went away!

@Jesper: I don’t quite understand what’s happened here as it’s spread over several topics.

Do you think there is something for us to “fix” for this particular issue?

@Luke: understandable - I don’t understand much of this behavior either. I have linked the issues, because I felt they might be related.

In this issue, we had eight processes running tests i parallel. Each process worked on it’s own database. One of these db’s had failed the create script, however, and some kind of exception were thrown. This probably went out to the Gradle test control process.

As we have seen in the related issue, db-exceptions can cause gradle to throw stackOverflows. We tried wrapping the exception in a RuntimeException like we do for all our other testcases (recommended by Peter N). This made the testcase fail normally and not freeze!

I hope this makes more sense now?

Regards /Jesper

I’m going to mark this down as a duplicate of

The symptom may not be the same, but I think it’s the same root cause.