Start SIGSEGV debugging by reproducing the crash with symbols enabled, then catch the exact faulting line with a debugger. A segmentation fault is not a mysterious Linux mood swing. It is your program touching memory it should not touch: a null pointer, freed object, bad array index, corrupted stack, or invalid cast. The tools differ, but the goal is always the same: find the illegal memory access before it turns into a vague “Segmentation fault (core dumped)”.
TLDR: SIGSEGV means the operating system stopped your program because it accessed invalid memory. On Linux, gdb, Valgrind, AddressSanitizer, coredumpctl, and dmesg give deep evidence, while IDEs make breakpoints, variables, and call stacks easier to inspect. For example, a C++ service crashing 17 times per day might be traced in 10 minutes with AddressSanitizer if the bug is a use after free, while plain log reading could waste hours. Use Linux tools for accuracy and IDE tools for speed.
What SIGSEGV really means
SIGSEGV stands for signal segmentation violation. It is usually signal number 11 on Linux. The kernel sends it when a process tries to read, write, or execute memory outside its allowed address space.
Common causes include:
- Null pointer dereference: calling
ptr->valuewhenptrisNULL. - Use after free: accessing memory after
free()ordelete. - Buffer overflow: writing past the end of an array.
- Stack overflow: often caused by infinite recursion or huge local arrays.
- Bad casts: treating memory as the wrong type.
- Uninitialized pointers: using junk addresses as if they were valid.
Linux tools: blunt, powerful, and very honest
Linux diagnostic tools are excellent because they sit close to the process and the kernel. They expose details an IDE may hide. The tradeoff is that some output looks like it was designed to punish tired engineers at 1:30 a.m.
1. Compile with debug symbols
Before using serious tools, build your program with symbols:
gcc -g -O0 app.c -o app
For C++:
g++ -g -O0 main.cpp -o app
The -g flag keeps line numbers and variable names. The -O0 flag disables optimization, which makes debugging less confusing. Optimized builds can move code around, inline functions, and make variables appear “missing.” It drives me crazy that one missing flag can turn a clear crash into a guessing game.
2. Use gdb for the exact crash point
gdb is the classic Linux debugger. Run:
gdb ./app
Then inside gdb:
run
When the program crashes, use:
bt
This prints a backtrace. It shows the function call chain that led to the crash. You can inspect variables with:
print variableName
You can move between stack frames with:
frame 1
If the crash line is *ptr = 5; and print ptr shows 0x0, you found a null pointer dereference. No drama. Just bad memory.
3. Check core dumps
If your program already crashed, you may not need to reproduce it right away. Linux can save a core dump, which is a snapshot of the process at death.
On many systemd based systems:
coredumpctl list
Then:
coredumpctl gdb
This opens the crash dump in gdb. It is very useful for production crashes, especially when the issue happens at random.
4. Use AddressSanitizer for memory bugs
AddressSanitizer, often called ASan, is one of the fastest ways to catch memory errors during testing.
Build with:
gcc -g -fsanitize=address -fno-omit-frame-pointer app.c -o app
ASan catches bugs such as:
- Use after free
- Heap buffer overflow
- Stack buffer overflow
- Double free
- Invalid pointer access
Its reports are direct. They show the bad access, allocation site, and free site. Expect the program to run slower, often around 2x, but that cost is worth it in test builds.
5. Use Valgrind when you need patience and proof
Valgrind is slower than ASan but still valuable. It finds invalid reads, invalid writes, memory leaks, and use of uninitialized memory.
Run:
valgrind --track-origins=yes --leak-check=full ./app
Honestly, it feels like Valgrind adds a coffee break to every run. A task that takes 3 seconds can take 40. Still, when it catches an invalid read from a freed block, the wait becomes easier to forgive.
IDE diagnostic tools: faster eyes, less typing
IDEs do not replace Linux tools. They wrap many of them in a cleaner workflow. For many teams, that means fewer missed breakpoints and less time staring at stack traces in plain text.
Popular IDE options include:
- Visual Studio Code: flexible, requires setup through launch files and extensions.
- CLion: strong C and C++ debugging, CMake support, built in sanitizers.
- Eclipse CDT: older feel, but still useful for large C and C++ projects.
- Visual Studio on Linux targets: useful for remote debugging from Windows.
IDE debuggers help with:
- Breakpoints: stop before the crash and inspect state.
- Watch windows: track suspicious pointers and counters.
- Call stack panels: see the path to failure quickly.
- Memory views: inspect raw addresses and bytes.
- Thread views: spot race conditions and crashes in worker threads.
The best part is speed. Clicking a stack frame is faster than typing frame 7, especially when you are jumping through callbacks. The annoying part is setup. A broken launch configuration can waste 20 minutes before your actual debugging even starts.
Debugging workflow that works
Use this order when SIGSEGV appears:
- Reproduce the crash. Get the smallest input or action that triggers it.
- Build with symbols. Use
-gand reduce optimization. - Run under gdb or your IDE debugger. Capture the exact crash line.
- Inspect the backtrace. Find who passed the bad pointer or size.
- Run ASan. Check for use after free or buffer overflow.
- Run Valgrind if needed. Confirm deeper heap errors or uninitialized reads.
- Fix the ownership rule. Do not just add a null check and walk away.
The last step matters. Many SIGSEGV fixes fail because the patch hides the symptom. If a pointer is null, ask why. If an index is out of bounds, ask where the size came from. If memory was freed too early, fix ownership, not just the crash site.
Linux tools vs IDE tools: which should you choose?
Use Linux command line tools when you need raw detail, production crash analysis, automation, or container debugging. They are also better for headless servers and CI pipelines.
Use IDE tools when you need quick inspection, visual call stacks, breakpoint control, or help understanding unfamiliar code. They are great during active development.
A practical split works best:
- gdb for precise crash location.
- ASan for fast memory bug detection.
- Valgrind for deeper memory checks.
- coredumpctl for post crash analysis.
- IDE debugger for interactive investigation.
Final takeaway
SIGSEGV is a memory crime scene. Linux tools give you the forensic report. IDEs give you a cleaner control room. The strongest workflow uses both: reproduce the crash, capture the faulting line, inspect the stack, then verify the fix with sanitizers. If you only remember one rule, remember this: the crash line is where the program died, not always where the bug was born.