Gradle "Daemon disappeared unexpectedly" (Test OOM) in CI

By Daniel Zoghalchali·Latchkey

When the Gradle daemon process is killed mid-build - most often OOM-killed by the kernel on a constrained runner during a heavy test or build phase - the client reports the daemon "disappeared unexpectedly" or crashed. It is an external termination, not a Gradle logic error.

What this error means

The build aborts with Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed), frequently right after a memory-heavy test or compilation task. The runner log may show an OOM kill.

gradle

> Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed)
----- Last  20 lines from daemon log file - daemon-1234.out.log -----
... process was terminated (exit code 137)

Common causes

Daemon JVM OOM-killed

The daemon's heap/Metaspace plus the work it drives exceeds runner memory, and the kernel kills it (exit 137). This is the transient capacity case.

Native crash in the daemon

A native library or JVM crash in the daemon process can also make it disappear; the daemon log's last lines identify which.

How to fix it

Give the daemon more heap (and keep tests forked)

Raise the daemon JVM heap and bound test worker memory so totals fit in RAM.

gradle.properties

# gradle.properties
org.gradle.jvmargs=-Xmx2g -XX:MaxMetaspaceSize=512m
# build.gradle: workers separate from the daemon
# test { maxHeapSize = '1g'; maxParallelForks = 1 }

Confirm OOM vs native crash

Read the printed daemon log tail: exit 137 = OOM kill; a JVM crash references an hs_err file.
Reduce concurrent work (parallel forks, --max-workers) if memory is the limit.
Use a larger runner for memory-heavy builds.

How to prevent it

Size org.gradle.jvmargs and test worker memory to the runner, avoid over-parallelism, and run heavy Gradle builds on larger runners.

Frequently asked questions

What causes ""Gradle build daemon disappeared unexpectedly""?