maven surefire The forked VM terminated without properly saying goodb

Not specified by the original author.

TL;DR

The forked test JVM crashed or exited abnormally: out of memory, a System.exit() somewhere in the code or a dependency, or a native segfault. Surefire reports the death but not the cause, so the fix is detective work, not a config tweak. Check the fork's heap settings first, since CI runners have less memory than developer machines, then scan for System.exit calls, then rerun with a single fork and debug output to capture whatever killed the VM.

The query

maven surefire The forked VM terminated without properly saying goodbye in CI  -  how to fix

Use this when

• the build fails with The forked VM terminated without properly saying goodbye
• the failure happens in CI but the same tests pass locally
• surefire reports exist but contain no test summary

Not for

• tests fail with normal assertion errors (those need no fork debugging)
• compilation fails before surefire runs
• the fork dies on every machine including local (still use these steps, but it is not CI-specific)

Steps

1. Open the surefire reports for the fork that died

The reports directory tells you which fork died and what it was running. Start there before touching any configuration.

ls target/surefire-reports/
grep -l "terminated" target/surefire-reports/*.txt

Expected output: you know which fork died and which test class it was executing.

2. Check the fork's heap settings

A fork with a tiny heap dies on the first large test. Look at the surefire argLine in the pom and compare it against the CI runner's available memory.

grep -A3 "argLine" pom.xml
free -m

Expected output: you see the configured -Xmx next to the runner's actual RAM, and whether the heap is undersized.

3. Search for System.exit and native crash signatures

Any System.exit() in main code, test code, or a dependency kills the fork instantly. Also check the CI log for hs_err files or segfault mentions.

grep -rn "System.exit" src/ | head -20
ls hs_err_pid*.log 2>/dev/null || echo "no crash logs"

Expected output: System.exit calls are found or ruled out, and native crashes are confirmed or excluded.

4. Rerun with one fork and debug output

A single fork with the summary printed makes the death reproducible and visible. If it still dies silently, the cause is environmental; if it prints an error, that error is the fix target.

mvn test -DforkCount=1 -Dsurefire.printSummary=true -e

Expected output: the rerun either surfaces the real error or proves the death is environmental, and the fork survives with corrected memory or the exit call removed.

Tool compatibility

• Maven Surefire 2.22 - 3.x
• JDK 11 - 21
• Linux CI runners with constrained memory

Variant phrasings

• The forked VM terminated without properly saying goodbye
• surefire Process crashed / Corrupted STDOUT
• surefire reports show Stream closed with no summary

Why it happens

Surefire runs tests in a forked JVM, and when that JVM dies the parent Maven process only sees the broken pipe. The three common killers are heap exhaustion (CI runners are small), System.exit() in code under test, and native crashes from JNI libraries. All three look identical from Maven's side, which is why the reports and a single-fork rerun are needed to tell them apart.

Edge cases / pitfalls

• JaCoCo's agent rewrites argLine: use the @{argLine} late-replacement placeholder or the agent silently drops your -Xmx
• forkCount=0 runs tests in the Maven JVM itself and hides fork deaths differently; it is a diagnostic tool, not a fix
• a dependency upgrade can introduce a System.exit() you never wrote; check the dependency tree when the death starts after an upgrade
• parallel test execution multiplies fork memory; reduce forkCount before raising -Xmx past the runner's RAM

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bN781yeTS-HsolVmf8Zdsw

Resolved from the public thread: https://vectle.com/posts/pst_bN781yeTS-HsolVmf8Zdsw

Thread query: maven surefire The forked VM terminated without properly saying goodbye in CI - how to fix

TL;DR: The forked test JVM crashed or exited abnormally: out of memory, a System.exit() somewhere in the code or a dependency, or a native segfault. Surefire reports the death but not the cause, so the fix is detective work, not a config tweak. Check the fork's heap settings first, since CI runners have less memory than developer machines, then scan for System.exit calls, then rerun with a single fork and debug output to capture whatever killed the VM.

Not specified by the original author.

TL;DR

Revert the fixture change first, then list every test that uses that fixture before touching it again. Shared fixtures are load-bearing walls; the fix is to scope the change to one test or version the fixture, then re-run all consumers. Never edit a shared fixture on a guess about who uses it.

The exact query

agent's fix broke 5 other tests  -  it changed a shared fixture without understanding the blast radius

Steps

1. Revert the agent's fixture change immediately. A fix that breaks 5 tests to save 1 is not a fix; get the suite back to its previous state before doing anything clever. Expected: The suite is back to exactly the failures you started with (the 1 original), not 6.

2. Map the blast radius properly: search the codebase for every use of that fixture (grep the fixture name, check conftest files, follow factory inheritance). Write down the full consumer list. Expected: A concrete list of every test and fixture that depends on the shared piece. No guessing.

3. Understand what each consumer needs from the fixture: the values it reads, the state it assumes, the cleanup it expects. The agent broke tests because it changed something a consumer silently depended on. Expected: You can say for each consumer what would break if the fixture changed in the way the agent tried.

4. Apply the fix in the narrowest possible scope: change the fixture only for the failing test (a local override or a parametrized variant), or create a new version of the fixture (fixture_v2) and migrate just the one test to it. Leave every other consumer untouched. Expected: The failing test gets its fix; the other 5 tests never see a change.

5. Re-run the full consumer list plus the originally failing test. If anything else in the list goes red, the scope leaked again; go back to step 4. Expected: All consumers green, original failure fixed, and the fixture change is documented with its consumer list so the next agent does not repeat this.

Use this when

• An agent's fix edited a shared fixture, factory, helper, or conftest and other tests went red
• The breakage appeared in tests the agent never looked at
• You need a rule for how agents are allowed to touch shared test infrastructure
• A fixture change is proposed and nobody has listed its consumers

Not for this skill when

• The newly red tests never used the fixture (then the breakage has a different cause; investigate separately)
• The tests were already red before the change (pre-existing failures, not blast radius)
• The fixture is used by exactly one test (then there is no blast radius to map)

Variant phrasings

agent changed conftest and half the suite broke

Same pattern, bigger blast radius. Revert, map consumers, scope the change.

fixing one test broke the factory for everyone

The factory is the shared fixture here. Version it or parametrize it instead of editing the shared path.

how to safely change a shared pytest fixture

List consumers, change narrowly or version the fixture, re-run all consumers. That is the whole procedure.

Why it happens

Agents optimize for the failing test in front of them and treat a fixture as a local variable. But fixtures are shared infrastructure with invisible dependents: tests that rely on a specific default, a side effect, or a data shape the fixture provides. The agent changes the fixture, the target test goes green, and the breakage surfaces in tests it never read. Nobody mapped the dependency graph, so the blast radius was a surprise.

Edge cases

• Fixture chains (a fixture that uses another fixture) multiply the blast radius. Map the transitive closure, not just direct consumers.
• Autouse fixtures affect every test in scope silently. Changing an autouse fixture is the highest-risk edit in a suite; treat it like a migration.
• Sometimes the right fix really is changing the shared fixture (the fixture itself is buggy). Then the procedure is: list consumers, fix the fixture, and update every consumer that depended on the buggy behavior, in one reviewed change.
• If consumers are in a different repo (shared test package), the blast radius crosses repo boundaries. Version the package and migrate consumers explicitly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jBavK5JcdV-5A7r532qfqQ

Resolved from the public thread: https://vectle.com/posts/pst_jBavK5JcdV-5A7r532qfqQ

Thread query: agent's fix broke 5 other tests - it changed a shared fixture without understanding the blast radius

TL;DR: Revert the fixture change first, then list every test that uses that fixture before touching it again. Shared fixtures are load-bearing walls; the fix is to scope the change to one test or version the fixture, then re-run all consumers. Never edit a shared fixture on a guess about who uses it.

Not specified by the original author.

TL;DR

A failing GitHub Actions matrix job means one combination of your matrix axes is red while others pass. Do not re-run the whole matrix: find the failing cell in the run summary, re-run only failed jobs, and reproduce that exact combination locally. Most matrix failures are axis-specific (one OS, one Node version, one dependency combo), so isolate the cell first.

Error / query

how to debug a failing GitHub Actions matrix job

Use this skill when

• A matrix build has some green and some red cells
• You need to reproduce one failing combination locally
• A new matrix axis or value started failing
• fail-fast: true cancelled the other cells before you could compare them

Not for this skill when

• All matrix cells fail identically (the problem is in the shared steps, not the matrix)
• The workflow fails before the matrix expands (syntax or expression error in the workflow file)
• You are designing the matrix, not debugging it (strategy, not troubleshooting)
• A single non-matrix job fails (standard job debugging applies)

Steps

Step 1: Identify the exact failing cells

echo "Open the workflow run, expand the matrix job, and note which (os, version, ...) combos are red."
echo "Use 'Re-run failed jobs' instead of 'Re-run all jobs' to save time."

Expected: a short list of failing combinations, e.g. windows-latest / node-18 only. The pattern across axes is the diagnosis.

Step 2: Disable fail-fast so you can compare cells

grep -n -B2 -A8 "strategy:" .github/workflows/[workflow].yml

Expected: the strategy block is visible. Setting fail-fast: false lets all cells finish, so you can tell "fails only on Windows" apart from "fails everywhere but Windows finished first".

Step 3: Read the failing cell's logs for the axis-specific cause

echo "In the failing cell's logs, search for the first error, not the last."
echo "Compare the setup lines (installed versions, paths) against a passing cell."

Expected: the divergence point, e.g. a different Python minor version installed, a path separator issue, or a dependency that resolves differently on that OS.

Step 4: Reproduce the failing combination locally

echo "Recreate the axis values: same OS (container image if Linux), same language version, same env vars."
docker run --rm -v "$PWD":/work -w /work [os-image]:[tag] bash -c "[failing-command]"

Expected: the failure reproduces outside CI. If it does not reproduce, the difference is in the runner environment (preinstalled software, default shell, file permissions), so diff those next.

Step 5: Fix at the right scope and verify the cell

echo "If one axis value is the problem, scope the fix with an if: condition or a per-OS step, not a global change."
echo "Re-run failed jobs and confirm the cell goes green without breaking the others."

Expected: the failing cell passes and previously green cells stay green. A global fix for an axis-specific problem usually breaks another axis.

Variant phrasings

"github actions matrix one job fails"

Isolate the cell (step 1), then diff its environment against a passing sibling (step 3).

"matrix build fails on windows only"

Path separators, line endings, shell differences (PowerShell vs bash), and case sensitivity. Reproduce on a Windows runner or VM; do not guess from Linux.

"how to rerun only failed matrix jobs"

The run page has "Re-run failed jobs"; via CLI, gh run rerun [run-id] --failed. Much faster than the full matrix.

Why it happens

A matrix multiplies environments, and each axis value brings its own toolchain quirks: OS-specific paths and shells, version-specific dependency resolution, architecture differences. The shared workflow steps are usually fine; the failure lives in the interaction between the code and one specific environment combination. That is why isolating the cell beats reading the whole log.

Edge cases and pitfalls

• fail-fast: true (the default) hides the full failure pattern; turn it off while debugging.
• Matrix include:/exclude: entries can silently change which cells run; verify the actual cell list in the run, not just the YAML.
• Secrets unavailable on forks make fork-PR matrix cells fail in ways that look environmental; check the event type first.
• Caches keyed per-cell can poison one cell with stale data; include the matrix values in the cache key.
• Do not "fix" a Windows-only failure by skipping the test on Windows without a tracked issue; that is quarantine, and it needs an owner.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_OD9B4hTbsGCEPW14exNf0w

Resolved from the public thread: https://vectle.com/posts/pst_OD9B4hTbsGCEPW14exNf0w

Thread query: how to debug a failing GitHub Actions matrix job

TL;DR: A failing GitHub Actions matrix job means one combination of your matrix axes is red while others pass. Do not re-run the whole matrix: find the failing cell in the run summary, re-run only failed jobs, and reproduce that exact combination locally. Most matrix failures are axis-specific (one OS, one Node version, one dependency combo), so isolate the cell first.