Linux system errors
Exit Code 139
Reviewed for reference consistency: August 11, 2026
process terminated by segmentation fault (Signal 11 / SIGSEGV)
What 139 Means
The 139 error on the Linux system errors indicates exit code 139 — process terminated by segmentation fault (signal 11 / sigsegv). This typically occurs due to null pointer dereference or accessing unmapped memory addresses.
Linux process exit code 139 indicates that an application was forcibly terminated by the operating system kernel due to a segmentation fault (Signal 11 / SIGSEGV). In Linux shell environments, fatal signal exit codes are calculated as 128 plus the signal number: 128 + 11 = 139.
How to fix 139
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Confirm it is a segfault, not an out-of-memory kill
Check the kernel ring buffer for the termination reason. A 'segfault at ...' line confirms SIGSEGV and exit code 139. An 'Out of memory: Killed process' line means the kernel's OOM killer chose the process, which is exit code 137 (SIGKILL), not 139. Distinguishing the two is the first step because they need opposite fixes.
dmesg -T | grep -iE 'segfault|out of memory|killed process'Decode the segfault line to identify the fault type
The kernel logs the faulting address, instruction pointer, and an error bitmask. 'at 0' means a null pointer dereference. A small offset like 'at 0x18' means a null struct pointer accessing a field. The instruction pointer (ip) maps to a source line with addr2line if the binary has debug symbols. The error field is a bitmask: bit 0 = page-not-present vs permission, bit 1 = read vs write, bit 2 = user-mode.
dmesg -T | grep -i segfault | tail -5 addr2line -e ./your_program 0x<ip_from_dmesg>Enable core dumps and reproduce the crash under GDB
Many distributions disable core dumps by default. Enable them with ulimit -c unlimited, reproduce the crash, then load the core in GDB to see the exact function and source line. Compile with -g for debug symbols. On systemd hosts, use coredumpctl list and coredumpctl gdb instead of looking for a core file.
ulimit -c unlimited gdb ./your_program core (gdb) bt full (gdb) frame 0 (gdb) listRebuild with AddressSanitizer for precise memory-error detection
AddressSanitizer (ASan) instruments every memory operation at compile time and reports the exact source line of a use-after-free, buffer overflow, or null dereference when it happens. It adds roughly 2x runtime overhead, making it suitable for development and CI. Combine with UndefinedBehaviorSanitizer to also catch integer overflow and other undefined behavior.
gcc -g -fsanitize=address,undefined -fno-omit-frame-pointer -o app app.c && ./appRun under Valgrind for deep analysis without recompiling
Valgrind runs the binary in a synthetic CPU that tracks every allocation and access. It catches invalid reads and writes, use-after-free, and uninitialized value use without requiring a rebuild. The trade-off is speed: Valgrind slows the program by 10-50x, so it is a development tool. Use --track-origins=yes to trace uninitialized values back to their source.
valgrind --leak-check=full --track-origins=yes ./your_programIn Docker or Kubernetes, verify architecture compatibility and library ABI
Containers frequently surface exit code 139 when an image built for one CPU architecture (e.g. linux/amd64) runs under QEMU emulation on a different host (e.g. linux/arm64), or when a native library was compiled against a different libc. Check the image platform, verify shared library compatibility with ldd, and read previous container logs in Kubernetes with kubectl logs POD --previous to distinguish 139 (segfault) from 137 (OOMKilled).
docker image inspect your-image --format '{{.Os}}/{{.Architecture}}' uname -m ldd ./your_program docker run --memory=2g your-image
Technical Background
Exit code 139 occurs when the CPU memory management unit (MMU) detects an illegal memory access and triggers a hardware page fault that the Linux kernel cannot resolve. The kernel responds by sending signal 11 (SIGSEGV) to the offending process, terminating it immediately.
Because the shell convention adds 128 to signal numbers for fatal terminations (128 + 11 = 139), exit code 139 directly mirrors Signal 11. Core dump files and GDB backtraces are commonly used by developers to pinpoint the exact instruction that triggered the violation.
Common Causes
- Null pointer dereference or accessing unmapped memory addresses
- Buffer overflow writing beyond allocated array or structure bounds
- Stack overflow caused by unbounded recursion or excessive stack allocations
- Use-after-free or double-free memory corruption in native C/C++/Rust code
Typical Scenarios
- A C++ or C application attempts to read from a null or corrupted memory pointer
- A Python or Node.js program crashes when a native C extension encounters a memory fault
- A compiled binary in a Docker container aborts with exit code 139 during automated CI tests
What to Know
Exit code 139 confirms a native memory access violation. Examining core dumps, compiler bounds checking, and memory sanitizers (like AddressSanitizer) identifies the invalid pointer or buffer access.
Frequently Asked Questions
Common questions about Linux 139 error
In practice, yes. Exit code 139 corresponds to signal 11 (SIGSEGV), which is the segmentation fault signal. It is extremely rare for a program to deliberately exit with code 139 for another reason. The 128 + signal convention is enforced by shells and container runtimes, so 139 unambiguously maps to SIGSEGV.
Exit code 139 is SIGSEGV (signal 11), meaning the process performed an invalid memory access — a bug in the code or a library. Exit code 137 is SIGKILL (signal 9), most commonly the OOM killer terminating a process that exceeded its memory limit. They look similar in a crash loop but need opposite fixes: 139 requires debugging the segfault, while 137 requires raising the memory limit or reducing usage.
Yes. Pure Python and JavaScript are memory-safe and normally raise exceptions rather than segfaulting. A real SIGSEGV in these runtimes almost always comes from a native C extension (e.g. NumPy, OpenCV, a Cython module, or a N-API addon), a ctypes or FFI misuse, or recursion deep enough to overflow the C-level stack. In Python, enable faulthandler (python -X faulthandler) to print a traceback when the crash happens.
A segfault is undefined behavior, which is allowed to appear to work. A use-after-free reads fine until the freed block is reused. ASLR randomizes addresses on each run, so a wild pointer may land on a mapped page one time and an unmapped one the next. Optimized release builds reorder code and reuse stack slots, so an uninitialized read that was harmless in debug may fault in release. Rebuild with AddressSanitizer to make the crash deterministic.
The kernel logs 'segfault at 0 ip 000055f6b2c0 sp 00007ffd1290 error 6 in app[556000+2000]'. The 'at' field is the faulting address — at 0 means a null dereference, a small value like 0x18 means a null struct pointer plus a field offset. The 'ip' maps to a source line with addr2line. The 'error' bitmask reveals read vs write and page-not-present vs permission violation.
The kernel writes cores using the host's core_pattern, not anything inside the container. Check cat /proc/sys/kernel/core_pattern on the node. On systemd hosts use coredumpctl list and coredumpctl gdb. For distroless images, attach an ephemeral debug container with kubectl debug --target. Keep the unstripped binary so the backtrace shows function names instead of question marks.
Related Error Codes
Process Killed — the process was terminated by a SIGKILL signal
Signal 11 (SIGSEGV) — kernel signal for invalid memory reference segmentation fault
Out of Memory (ENOMEM) — the kernel cannot allocate the requested amount of memory
Terminated by User — the process was interrupted by a SIGINT signal
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Git's internal object database is missing or corrupted.
The operating system denied Git's request for more RAM during a heavy operation.
Git detected corruption inside one of its compressed data bundles (packfiles).
An uncompressed file in Git's internal database has an invalid checksum or zero bytes.