Linux system errors
Linux 11 SIGSEGV signal 11
Reviewed for reference consistency: April 11, 2026
SIGSEGV signal 11 — the process attempted invalid memory access
What 11 Means
The 11 error on the Linux system errors indicates sigsegv signal 11 — the process attempted invalid memory access. This typically occurs due to dereferencing a null or uninitialized pointer in compiled code.
Signal 11 is the numeric Linux signal for SIGSEGV, the segmentation fault event. It describes the signal delivered to the process, while exit code 139 is the shell-facing status produced from the same event by adding 128 to the signal number.
How to fix 11
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.
Read the crash as a memory-access fault
Signal 11 (SIGSEGV) means the process touched memory it was not allowed to. Confirm it in the kernel log and note the faulting address reported for the process.
dmesg -T | grep -i segfaultCapture a backtrace with a debugger
Run the program under gdb and print the backtrace after it crashes to identify the exact call path that dereferenced invalid memory.
gdb --args ./your_program run btEnable a core dump for post-mortem analysis
Allowing core dumps lets you inspect the process state at the moment of the crash without having to reproduce it live, which is useful for intermittent faults.
ulimit -c unlimited coredumpctl gdbRebuild native libraries with AddressSanitizer
When the crash comes from a library loaded by Python, Java, or Node, rebuilding that native extension with AddressSanitizer pinpoints the faulting access.
gcc -g -fsanitize=address -o app app.c && ./app
Technical Background
SIGSEGV is the named signal behind Linux signal 11. It is raised when a process reaches memory that is not mapped for it, no longer belongs to it, or is not permitted for the access type being attempted.
The important distinction is reporting layer. Low-level logs and signal tables often show signal 11 or SIGSEGV, while shells, CI systems, and container runtimes commonly surface the same termination as exit code 139. Those labels point to one crash event from different viewpoints.
This makes signal 11 most useful as a classification clue: it separates memory-access termination from other signal exits such as SIGKILL-based 137 or user-interrupt 130.
Common Causes
- Dereferencing a null or uninitialized pointer in compiled code
- Buffer overflow writing past the end of an allocated memory block
- Accessing freed or unmapped memory regions
Typical Scenarios
- A C application crashes because it dereferences a pointer that was never initialized
- A native library loaded by a Python or Java application triggers a segfault due to memory corruption
What to Know
A SIGSEGV reading should be interpreted as a memory-access termination, not as a generic command failure. When paired with exit code 139, both values describe the same signal-based outcome rather than two independent errors.
Frequently Asked Questions
Common questions about Linux 11 error
They represent the same event. Signal 11 (SIGSEGV) is the kernel notification to the process. When the shell reports the result, it adds 128 to the signal number, producing exit code 139.