Skip to content
Latchkey

sbt "ForkMain failed" / forked test OOM in CI

sbt runs tests in a forked JVM by default, and that forked process died. Exit code 137 means the OS killed it (usually the OOM killer), and an OutOfMemoryError means the fork's own heap was too small. This is controlled by Test / javaOptions, not SBT_OPTS.

What this error means

Tests fail with "sbt.ForkMain failed with exit code 137" or a forked "java.lang.OutOfMemoryError: Java heap space" while the sbt process itself keeps running.

sbt
[error] Uncaught exception when running tests: java.lang.OutOfMemoryError: Java heap space
[error] Failed tests:
[error] sbt.ForkMain failed with exit code 137

Common causes

The forked test JVM heap is too small

Forked tests get a default heap unless you set Test / javaOptions; a memory-heavy suite outgrows it and throws OutOfMemoryError.

The OS killed the fork (exit 137)

Exit code 137 (128 + SIGKILL) means the runner's OOM killer terminated the forked JVM because total container memory was exceeded.

How to fix it

Give the forked test JVM more heap

  1. Set Test / javaOptions with a larger -Xmx for the fork.
  2. Ensure the runner has more RAM than heap plus overhead.
  3. Re-run the tests.
build.sbt
Test / fork := true
Test / javaOptions ++= Seq("-Xmx2g")

Reduce fork parallelism so total memory fits

Limit how many forked test JVMs run at once so their combined heap stays under the runner limit and avoids the OOM killer.

build.sbt
Test / parallelExecution := false

How to prevent it

  • Set Test / javaOptions heap for forked tests, not just SBT_OPTS.
  • Keep forked parallelism within the runner's memory budget.
  • Provision runners with RAM above the sum of forked heaps.

Related guides

Run this faster and cheaper on Latchkey managed runners. Start free →