Node.js "Segmentation fault" - Diagnose Native Crashes in CI

A segmentation fault is the OS killing Node for an illegal memory access. It comes from native code - a compiled addon, a V8 bug, or a corrupted binary - not from your JavaScript, so there is no JS stack trace.

What this error means

A step dies with Segmentation fault (or Segmentation fault (core dumped)) and exit code 139, with little or no JavaScript stack. It often appears right after loading a native module or under heavy load.

$ node app.mjs
Segmentation fault (core dumped)
$ echo $?
139

Common causes

A faulty or mismatched native addon

A native module compiled for a different Node ABI, architecture, or libc can crash on load or first use. This is the most common source of a SIGSEGV in Node.

A V8 or runtime bug under specific load

Rarely, a particular Node version segfaults under heavy concurrency or a specific code pattern. Upgrading or downgrading Node sidesteps it.

How to fix it

Isolate the offending native module

Get a native stack to identify the addon, then rebuild or pin it for the runner’s platform.

# print a native backtrace on crash
node --stack-trace-on-illegal app.mjs
# rebuild native addons against the current Node ABI
npm rebuild

Pin a known-good Node and addon version

1. Reproduce on a clean image to confirm it is the addon, not your code.
2. Pin the Node version and reinstall so prebuilt binaries match the ABI.
3. If a specific Node release is implicated, move up or down one minor and retest.

How to prevent it

• Rebuild native addons (npm rebuild) when changing Node version or architecture.
• Pin Node and native dependency versions so the ABI stays consistent.
• Capture core dumps in CI for native crashes so they can be triaged.

Related guides