Linux system errors
Linux 139 Exit code 139
Reviewed for reference consistency: April 11, 2026
Exit code 139 — shell status for a SIGSEGV termination
What 139 Means
The 139 error on the Linux system errors indicates exit code 139 — shell status for a sigsegv termination. This typically occurs due to null pointer dereference in a compiled binary.
Exit code 139 is the shell-level representation of a SIGSEGV termination. It comes from the Linux convention of reporting signal exits as 128 plus the signal number: 128 + signal 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 log for the termination reason. A 'segfault' line confirms SIGSEGV, while an 'Out of memory' line means the process was OOM-killed and should be treated as exit code 137 instead.
dmesg -T | grep -iE 'segfault|out of memory|killed'Reproduce under a debugger to find the crash location
Run the failing program inside gdb, let it crash, then print the backtrace to see the exact function and line that triggered the invalid memory access.
gdb --args ./your_program arg1 run btRebuild with AddressSanitizer to catch the bad access
Compiling with AddressSanitizer instruments memory operations and reports the precise location of a use-after-free, buffer overflow, or null dereference when it happens.
gcc -g -fsanitize=address -o app app.c && ./appIn Docker or CI, rule out a memory limit or library mismatch
Containers often surface 139 when a native library was built against a different libc or when the process is starved of memory. Raise the limit and confirm the runtime matches the build environment.
docker run --memory=2g your-image
Technical Background
Exit code 139 is not a separate Linux error number. It is the shell status created after a process terminates because of signal 11, also known as SIGSEGV.
That makes 139 different from ordinary application exit codes such as 1, 2, or 3. Those values usually mean the program chose to exit with a non-zero status. Code 139 usually means the process was stopped by the operating system's signal handling path.
The same event may be described as `segfault`, `SIGSEGV`, `signal 11`, `return code 139`, or `exit code 139` depending on whether the message comes from a kernel log, shell, test runner, container runtime, or CI interface.
Common Causes
- Null pointer dereference in a compiled binary
- Stack overflow from excessive recursion depth
- Use-after-free or double-free memory corruption
Typical Scenarios
- A CI pipeline reports exit code 139 after a test binary crashes during execution
- A Docker container terminates with code 139 because the application inside had a memory access violation
What to Know
A 139 status is best read as a signal-encoded crash result. Its closest sibling is signal 11, while 137 shows the same 128-plus-signal convention for SIGKILL rather than SIGSEGV.
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.