How to fix Segmentation fault (core dumped) in Node.js

Node.jsADVANCEDCRITICALUpdated Dec 9, 2025· 245 views

A segmentation fault occurs when Node.js or a native addon attempts to access memory it is not permitted to access, causing the process to crash with a "Segmentation fault (core dumped)" message. This typically indicates a bug in native C/C++ modules rather than JavaScript code.

Quick fix

Fixes SIGSEGV

# List all native modules
find node_modules -name "*.node" -type f | head -20

# Or use npm to list packages with native addons
npm list --depth=0 | grep -E '(node-gyp|native|addon)'
  1. Identify native modules in your project
  2. Rebuild all native modules for your Node.js version
  3. Update native modules to the latest version
  4. Test by removing suspicious native modules
node.js — error
# List all native modules
find node_modules -name "*.node" -type f | head -20
# Or use npm to list packages with native addons
npm list --depth=0 | grep -E '(node-gyp|native|addon)'
Segmentation fault (core dumped)

What this error means

A segmentation fault (often abbreviated as "segfault" or "SIGSEGV") is a critical error that happens when a program tries to access a memory location that is either: - Not allocated for its use - Already freed or deallocated - Protected by the operating system - Beyond the bounds of an allocated memory region In Node.js, segmentation faults are serious because they cause the entire process to crash immediately without a proper JavaScript stack trace. Unlike other JavaScript errors that can be caught and handled, a segfault terminates Node completely. The error message "Segmentation fault (core dumped)" means the OS has forcibly terminated the process. The core dump is a memory image that can be analyzed by debuggers to identify the crash location.

Typical symptoms

  • Process terminates unexpectedly with "Segmentation fault (core dumped)" message
  • No JavaScript error stack trace is printed
  • Application crashes silently without error handling
  • Crash occurs when using specific native modules or addons
  • Issue appears after upgrading Node.js to a newer version
  • Crash is inconsistent or happens under specific conditions
  • Docker container exits with exit code 139 (SIGSEGV)
  • Core dump file is created in the current directory (core)

Common causes

  1. Bug in a native Node.js addon (C/C++ module) causing memory corruption
  2. Native addon compiled against wrong Node.js ABI version
  3. Native addon using deprecated V8 APIs that changed in newer Node.js versions
  4. Memory leak or buffer overflow in native code called by your application
  5. Incompatible native module version after Node.js major version upgrade
  6. Malformed or corrupted native module file
  7. Out of memory conditions triggering internal Node.js native code bugs
  8. Race condition in multi-threaded native code
  9. Direct use of unsafe syscalls or unvalidated memory access

How to fix "Segmentation fault (core dumped)"

1Identify native modules in your project

Find all native modules by searching for compiled .node files:

bash
# List all native modules
find node_modules -name "*.node" -type f | head -20

# Or use npm to list packages with native addons
npm list --depth=0 | grep -E '(node-gyp|native|addon)'

Native modules are the primary cause of segmentation faults. Identify which modules are present in your project.

2Rebuild all native modules for your Node.js version

Rebuild native modules to ensure they are compiled against your current Node.js version:

bash
# Clear npm cache
npm cache clean --force

# Rebuild all native modules
npm rebuild

# Or rebuild a specific module
npm rebuild module-name

This recompiles native code against your current Node.js ABI (Application Binary Interface). Version mismatches are a common cause of segfaults.

3Update native modules to the latest version

Update packages that contain native addons:

bash
# Update all packages
npm update

# Or update a specific native module
npm install module-name@latest

# Check outdated packages
npm outdated

Newer versions often fix bugs in native code that cause crashes. If you recently upgraded Node.js, ensure all native modules are updated too.

4Test by removing suspicious native modules

Isolate the problematic module by temporarily removing native packages:

bash
# List your dependencies
npm list --depth=0

# Remove suspicious modules one at a time
npm uninstall problematic-module

# Run your app and test
node your-app.js

If the segfault disappears after removing a module, that module is the culprit. Then you can:
- Update it to a newer version
- Find an alternative package
- File a bug report with the maintainer

5Enable core dump collection for debugging

Enable core dumps to capture detailed crash information:

bash
# On Linux, increase core dump limit
ulimit -c unlimited

# Run your Node.js app
node your-app.js

# A "core" file will be created if a crash occurs
# Analyze with gdb
gdb node core
# In gdb, type: backtrace
# This shows where in the native code the crash occurred

Core dumps provide detailed information that can be shared with module maintainers.

6Use segfault-handler for stack traces

Install the segfault-handler module to capture native stack traces:

bash
npm install segfault-handler

Then add to the start of your application:

javascript
import segfaultHandler from 'segfault-handler';

// Setup handler at the very beginning
segfaultHandler.registerHandler('crash.log');

// Rest of your app code
import express from 'express';
const app = express();
// ... your code

When a segfault occurs, a native stack trace is written to crash.log, helping identify the exact location of the crash in native code.

7Downgrade Node.js to a stable version

If segfaults started after upgrading Node.js, try reverting to a stable LTS version:

bash
# Check your current version
node --version

# Install a specific LTS version using nvm
nvm install 20  # Latest LTS

# Switch to it
nvm use 20

# Rebuild native modules for new version
npm rebuild

Node.js new releases sometimes have bugs. Using an LTS (Long-Term Support) version is safer for production.

8Check for known issues in GitHub

Search for the segfault in relevant repositories:

bash
# Get more details about the crash (if core dump is available)
# Search the affected module's GitHub issues
# Example: If crash is with 'sqlite3'
# Visit: https://github.com/mapbox/node-sqlite3/issues
# Search for "segmentation fault" or "SIGSEGV"

Often the issue is known and has a fix or workaround documented.

Advanced notes

Understanding Memory Safety in Node.js

Native modules are written in C/C++ without the memory safety protections of JavaScript. They have direct access to memory and can:
- Allocate and free memory
- Access pointers and memory addresses
- Call system-level functions

A single bug in native code—like writing past a buffer boundary or accessing freed memory—causes a segmentation fault that crashes the entire Node.js process.

Using GDB for Detailed Analysis

For deep debugging, compile Node.js with debug symbols and use GDB:

bash
# Run Node with gdb
gdb --args node your-app.js

# In gdb, start execution
(gdb) run

# After crash occurs
(gdb) backtrace

# See detailed local variables
(gdb) info locals

This reveals the exact function and line in native code where memory was accessed illegally.

Native Module Security Considerations

Native modules introduce security and stability risks:
- They can bypass JavaScript sandbox protections
- They have direct system access
- A bug can crash your entire application
- They may have different security update cycles than Node.js

Always use native modules only when necessary and from trusted maintainers.

Common Native Module Issues by Node.js Version

- Node.js 14+: Some older native modules break due to changes in the V8 engine
- Node.js 18: HTTP/2 had segfault issues in early releases
- Node.js 20+: Stricter memory management exposed bugs in poorly-written addons

After major Node.js upgrades, always test thoroughly with native modules.

Monitoring for Segfaults in Production

In production, segfaults are hard to debug because they crash with no warning. Use monitoring:

javascript
import segfaultHandler from 'segfault-handler';
import fs from 'fs';

segfaultHandler.registerHandler('/var/log/app-crash.log');

// Log process state before crash
setInterval(() => {
  console.log(`App running at ${new Date().toISOString()}`);
}, 60000);

This at least records what your app was doing before the crash.

Frequently asked questions

What does "SIGSEGV" mean?
js, segmentation faults are serious because they cause the entire process to crash immediately without a proper JavaScript stack trace. Unlike other JavaScript errors that can be caught and handled, a segfault terminates Node completely. The error message "Segmentation fault (core dumped)" means the OS has forcibly terminated the process.
How do I fix "SIGSEGV"?
A segmentation fault occurs when Node.js or a native addon attempts to access memory it is not permitted to access, causing the process to crash with a "Segmentation fault (core dumped)" message. This typically indicates a bug in native C/C++ modules rather than JavaScript code.
What causes "SIGSEGV"?
Bug in a native Node.js addon (C/C++ module) causing memory corruption Native addon compiled against wrong Node.js ABI version Native addon using deprecated V8 APIs that changed in newer Node.js versions
Is the "SIGSEGV" error serious?
Yes. This is a critical-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading