Linux system errors
Linux 139 Exit code 139
Reviewed for reference consistency: April 11, 2026
Exit code 139 — a segmentation fault (SIGSEGV, signal 11) killed the process
What 139 Means
The 139 error on the Linux system errors indicates exit code 139 — a segmentation fault (sigsegv, signal 11) killed the process. This typically occurs due to null pointer dereference — the program reads or writes through a pointer that is null or was never initialized.
Exit code 139 is the shell-level representation of a process terminated by signal 11 (SIGSEGV). Linux shells and container runtimes follow the convention 128 + signal_number for killed processes, so 128 + 11 = 139. A segmentation fault occurs when the CPU's memory management unit detects an invalid memory access. The kernel delivers SIGSEGV, terminating the process immediately, often with a core dump.
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 is not a separate Linux error number or an errno value. It is the exit status that a shell, container runtime, or CI runner reports when a process is killed by signal 11 (SIGSEGV). The convention is 128 + signal_number, so 128 + 11 = 139. This makes 139 fundamentally different from ordinary application exit codes like 1, 2, or 3, which a program sets deliberately. Code 139 means the operating system's signal handling path terminated the process because the CPU raised a memory-access fault.
A segmentation fault occurs at the hardware level. Every process gets its own virtual address space, enforced by the Memory Management Unit (MMU). When a process reads or writes an address that is not mapped, or that it lacks permission for, the MMU raises a hardware exception. The kernel translates this into SIGSEGV and terminates the process, optionally writing a core dump — a safety mechanism that prevents the process from corrupting other memory.
The same event appears under different names depending on where you see it. The kernel log (dmesg) prints 'segfault at <addr> ip <ip> sp <sp> error <mask> in <library>'. A shell prints 'Segmentation fault' or 'Segmentation fault (core dumped)'. A CI pipeline reports 'exit code 139'. A container runtime or Kubernetes shows Exit Code 139 in the container's Last State. All describe the same event: a memory-access violation that triggered SIGSEGV.
Exit code 139 is closely related to 137 (SIGKILL, 128 + 9). Both use the 128 + signal convention but mean different things: SIGSEGV (139) is a bug in the process's own code or a linked library, while SIGKILL (137) is usually the OOM killer or an external kill -9. In a crash loop, distinguishing between the two is critical — 139 means debug the segfault, 137 means check the memory limit.
Common Causes
- Null pointer dereference — the program reads or writes through a pointer that is NULL or was never initialized
- Use-after-free or double-free — accessing heap memory after it was freed, so the allocator may have reused or corrupted the block
- Buffer overflow — writing past the end of a stack or heap array, corrupting adjacent memory or hitting an unmapped page
- ABI mismatch — a binary or native extension linked against one version of a shared library runs against an incompatible version at runtime
- Stack exhaustion — unbounded recursion or very large stack-allocated buffers overflow the guard page below the stack
Typical Scenarios
- A C or C++ program dereferences a null pointer and the shell reports 'Segmentation fault (core dumped)' with exit status 139
- A CI pipeline (GitHub Actions, GitLab CI, Jenkins) fails with exit code 139 when a native test binary crashes during the test step
- A Docker container terminates with code 139 because the application accessed memory through a dangling pointer or a shared library was built against a different libc
- A Python script exits with code 139 because a C extension (NumPy, OpenCV, a Cython module, or a ctypes FFI call) performed an invalid memory access
What to Know
Treat a 139 exit code as a signal-encoded crash, not a recoverable error. Start by confirming the segfault in dmesg, then distinguish it from 137 (OOM kill). Capture a core dump and read the backtrace in GDB to find the exact faulting line. If you can rebuild, use AddressSanitizer for precise detection of use-after-free, buffer overflow, or null dereference. In containers, check for ABI and architecture mismatch before assuming a code bug. For intermittent crashes, make them deterministic with MALLOC_PERTURB_ or a sanitizer build.
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) memory fault or Errno 11 (EAGAIN / EWOULDBLOCK) resource unavailable
Terminated by User — the process was interrupted by a SIGINT signal
Invalid Exit Argument — script exited with an out-of-range status or terminated by a 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.