Node "Segmentation fault" During Build/Test - Fix Crashing Native Code in CI

A segmentation fault is a hard native crash (SIGSEGV) - Node’s process touched memory it should not. It comes from native code: a mismatched native addon, a corrupt binary, or memory pressure, not from your JS logic directly.

What this error means

A build or test step dies with just Segmentation fault (sometimes "Segmentation fault (core dumped)") and a non-zero exit, with little JS stack. It can be intermittent under memory pressure or consistent for a specific native module.

> jest

Segmentation fault (core dumped)
# exit code 139 (128 + SIGSEGV 11)

Common causes

A native addon built against a different Node ABI

A prebuilt or cached native module compiled for a different Node version/arch can crash the process when loaded under the runner’s Node.

Memory pressure or a corrupt binary

A low-memory runner, or a truncated/corrupt native binary from a flaky download or restored cache, can trigger a segfault during execution.

How to fix it

Rebuild natives and clear caches

Reinstall and rebuild native modules against the active Node, on a clean cache.

rm -rf node_modules
npm cache clean --force
npm ci
npm rebuild        # rebuild native addons for this Node/arch

Match Node and reduce pressure

1. Pin the runner Node to the version the native modules were built for.
2. Lower parallelism (e.g. Jest --maxWorkers=2) or raise runner memory.
3. Bust the node_modules/native cache if it predates a Node upgrade.

How to prevent it

• Rebuild native modules when the Node version changes.
• Cache native modules keyed on Node version + platform.
• Give memory-heavy builds/tests enough RAM and modest parallelism.

Related guides