Debugging May 17, 2026 7 min read

Deep Dive into Segmentation Fault

A segmentation fault (often called _segfault_) occurs when a program attempts to access a memory address that it is not allowed to read or write. The operating system detects the invalid access and terminates the process

View source on GitHub →

Note: This document is educational. It explains segmentation faults (SIGSEGV) using text diagrams and safe, non‑exploit demonstrations. Do not use the visualisations to attack systems — they are for learning, debugging, and defensive purposes only.

1. Quick summary

A segmentation fault (often called segfault) occurs when a program attempts to access a memory address that it is not allowed to read or write. The operating system detects the invalid access and terminates the process, typically sending it SIGSEGV (on Unix‑like systems). Segfaults indicate bugs such as null pointer dereferences, use‑after‑free errors, and out‑of‑bounds accesses.

2. High‑level conceptual flow (text diagram)

This short diagram shows the interaction that leads from a program action to the OS killing the process:

Program issues memory access (load/store)
            |
            v
      CPU/MMU performs address translation
            |
    Permission check & page present?
        /            \
       yes            no/violation
       |               |
       v               v
   Memory read/    Trap to kernel -> Kernel sends SIGSEGV to process
   write returns

If the address translation or permission check fails, the kernel intervenes and the process receives a signal (or exception) that typically causes termination.

3. Textual memory map — where programs live

A simplified typical layout of a user process in virtual memory (top = high addresses):

+----------------------+  0xFFFFFFFF (high)
|  stack (grows down)  |  <-- local variables, return addresses
|                      |
+----------------------+  <-- stack base
|  (unused / heap gap)  |
+----------------------+  <-- heap grows up
|  heap (malloc/new)    |  <-- dynamic allocations
+----------------------+
|  bss / data segment   |  <-- global/static vars
+----------------------+
|  read-only code/text  |  <-- program instructions
+----------------------+  0x00000000 (low)

Key point: a program is only allowed to access addresses mapped into its virtual address space. Accessing unmapped addresses or violating permissions leads to faults.

4. Stack frame (function call) — ASCII visual

Visualizing a single function call’s stack frame (high addresses at top):

           +----------------------+  <-- stack top (higher addresses)
           |  return address (RET) |  <-- critical control information
           +----------------------+
           |  saved frame pointer  |
           +----------------------+
           |  local buffer / vars  |  <-- buffer vulnerable to overflow
           +----------------------+
           |  function arguments   |
           +----------------------+  <-- stack base (lower addresses)

When a function returns, the CPU uses the saved RET value to continue execution. Overwriting the RET value can redirect control flow or cause an invalid jump (crash).

5. Common segfault causes (conceptual with text visuals)

5.1 Null pointer dereference

ptr = 0x0
*ptr -> access at 0x0 -> invalid
Kernel: SIGSEGV

Behavior: trying to dereference NULL (address 0x0) — often immediate and reproducible.

5.2 Use‑after‑free (dangling pointer)

heap: [ object A ]
free(object A)  -> memory returned to allocator (may be reused)
ptr still points to A
*ptr -> could be garbage or unmapped -> SIGSEGV or weird behavior

Behavior: intermittent crashes depending on heap reuse.

5.3 Out‑of‑bounds array access

array[0..9]
access array[12] -> steps into adjacent memory (maybe RET or SFP) -> corrupt or crash

Behavior: can corrupt adjacent memory (leading to segfaults or subtle data corruption).

6. What the OS does (simplified)

The CPU issues a load/store for virtual address VA.
The MMU/translation hardware consults page tables to map VA → PA (physical address).
If page is present and permissions allow access, operation proceeds.
If page is not present or permission denies access → hardware raises fault and the kernel handles the exception.
Kernel typically sends SIGSEGV to the process (or invokes a platform‑specific exception handler).

7. Defender view — logs and artifacts (safe, fabricated examples)

System log (stylized) — fake values

Oct 10 12:34:56 host demo_app[12345]: segfault at 0x00000000 ip 0x00401234 sp 0x7fffd1234560 error 4
Oct 10 12:34:56 host kernel: demo_app[12345]: segfault at 0x00000000 ip 0x401234 sp 0x7fffd1234560

Core dump (what to collect)

Core image (if enabled) — snapshot of process memory
dmesg or kernel log line with faulting IP and address
Application logs around the timestamp
Repro steps (if safe) — input used (redacted if sensitive)

Tip: Produce fake/test inputs and reproduce in an isolated lab; never reproduce crashes on production systems without authorization.

8. Debugging workflow (step‑by‑step, safe)

Preserve evidence: collect logs, note timestamps, and snapshot the system if possible. Avoid rebooting until you’ve captured necessary artifacts.
Obtain core / diagnostic output: enable core dumps in a test environment and capture one for analysis. Use ulimit -c (or platform equivalent) in labs only.
Reproduce safely: create a minimized, isolated test that reproduces the crash with synthetic inputs. Don’t run destructive tests on production.
Symbolicate / inspect: use gdb or equivalent to examine the backtrace and inspect the faulting instruction & stack frame.
Identify root cause: determine whether it’s null deref, use‑after‑free, buffer overrun, or other memory issue.
Fix & harden: patch code, add bounds checks, replace unsafe APIs, enable sanitizers for CI (ASan, Valgrind), and add unit tests.
Deploy & monitor: roll out the fix to staging, observe metrics, then deploy to production with rollback plans.

9. Prevention checklist (concise)

Validate all inputs and check bounds.
Use safe/bounded APIs (e.g., strncpy with limits, or safer higher‑level abstractions).
Employ compiler defenses: stack canaries, DEP/NX, PIE/ASLR.
Run sanitizers (AddressSanitizer, MemorySanitizer) during testing.
Fuzz suspicious code paths in CI.
Enable robust monitoring and core collection in debug/test environments.

10. Text‑based visual examples (mini scenarios)

Scenario A — Null dereference (short script concept)

1) App log: "Received request id 42"
2) App attempts to use pointer 'resp' which was not initialized
3) Kernel log: "segfault at 0x0 ip 0x401020"
4) Dev: add initialization and null checks -> verified in lab

Scenario B — Buffer overrun (conceptual, safe)

1) App allocates buffer[32]
2) Input length 80 arrives (simulated/redacted)
3) Overflow writes into saved frame / RET -> crash
4) Fix: validate length and use bounded copy -> crash gone

In both scenarios, the specifics of the input should be recreated only in an isolated test lab with consent.

11. Safe demo ideas (to show in video without enabling misuse)

Simulated terminal output: print typed command and a [PAYLOAD REDACTED] line followed by Segmentation fault (simulated) — use the fake_demo.py approach.
Animated memory diagrams: show bytes filling a buffer and spilling into adjacent blocks using colored rectangles or ASCII animations.
Redacted traces: show a sanitized backtrace (no real addresses) and highlight the function name and line number in source code where the fault occurred.
Instrumented test harness: run benign inputs that exercise the code paths and visualize boundary conditions crossing — no real exploit strings.

12. Glossary (quick)

SEGFAULT / SIGSEGV: OS signal indicating invalid memory access.
MMU: Memory Management Unit — hardware that translates virtual addresses to physical addresses.
ASLR: Address Space Layout Randomization — moves memory regions to make fixed-address attacks harder.
DEP / NX: Data Execution Prevention / No Execute — prevents executing code from data pages.
ASan: AddressSanitizer — runtime tool that detects memory errors in tests.

13. Further reading & tools (safe resources)

AddressSanitizer (ASan) documentation — for detecting memory errors in testing.
Valgrind — memory debugging in test environments.
gdb manuals — for post‑mortem debugging using core dumps.
Official OS kernel docs on signals/exceptions for platform‑specific details.

End of document

By End Of File

← Back to all posts