Travis CI: org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)

Help/Discuss
1

Hi,

in integration specs for a Gradle plugin, I use the Tooling API’s GradleConnection and Gradle TestKit’s GradleRunner (which internally uses the Tooling API), and while everythings run smoothly on my machine, it fails on Travis CI with a org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed) error.

Anyone has any idea why that happens and more importantly if there’s any workaround?

2

Increasing the testkit daemon’s max heap size helped in my case (though I don’t really understand why…).
See TestKit: How to turn off daemon?

3

Actually, the problem seems to be that on Travis the initial jvm heap size is nearly 1GB. Since Gradle forks quite a few JVMs by default (Compiler Daemons, Test Executors, TestKit Daemons), the memory pressure becomes too high and Travis begins to kill processes.

I solved it by controlling the number of forked JVMs (5) and reducing the initial heap size:

// build.gradle
if (System.env.TRAVIS == 'true') {
  allprojects {
    tasks.withType(GroovyCompile) {
      groovyOptions.fork = false
    }
    tasks.withType(Test) {
      // containers (currently) have 2 dedicated cores and 4GB of memory
      maxParallelForks = 2
      minHeapSize = '128m'
    }
  }
}

// .travis.yml
env:
  global:
    - GRADLE_OPTS="-Xms128m"
1 Like
4

FWIW, I workaround the issue by using one job per Gradle version to test with TestKit: https://github.com/tbroyer/gradle-apt-plugin/commit/53d2d8d5231b8626bceeac2c14e056832986dca5

5

For the record, all of these suggestions did not help in my case. But what did help was to put a simple sudo: required in .travis.yml to enforce running outside of a container and thus relax memory constraints.