Segmentation Fault¶

A synchronous protection fault reported when an executing thread references a virtual address that is unmapped or uses a mapped address contrary to its access permissions.

Version: v2 · 2026-09-06 · History
Domain-specific #: 2740
Origin domain: computer science
Subdomain: operating systems and systems programming
Aliases: Segfault, Segmentation violation

Core Idea¶

A segmentation fault is a synchronous protection failure that occurs when an executing thread attempts a memory reference the system's virtual-memory rules do not permit. The target address may have no mapping in the process address space, or a mapping may exist but forbid the attempted operation—for example, writing a read-only page or executing a non-executable page. Hardware detects the faulting access, transfers control to privileged fault-handling code, and the operating system converts an unresolvable user-mode violation into a process-visible event.

On POSIX systems, the conventional manifestation is SIGSEGV, whose standard description is “invalid memory reference.”^[1] siginfo_t.si_code can distinguish an unmapped address (SEGV_MAPERR) from invalid permissions on a mapped object (SEGV_ACCERR), and si_addr identifies the reported faulting address^[1]. The default action is abnormal process termination, commonly with a core dump. Windows reports the analogous EXCEPTION_ACCESS_VIOLATION or STATUS_ACCESS_VIOLATION when a thread reads, writes, or executes a virtual address without the required access^[2].

The abstraction is the protection event, not the source-code defect that eventually provoked it. A null dereference, dangling pointer, buffer overrun, stack exhaustion, use-after-free, corrupted return address, or deliberate guard-page probe can all lead to the same event. Conversely, those defects do not guarantee a segmentation fault: an invalid language-level access may happen to touch mapped and permitted memory, may be optimized away, or may corrupt data silently. The node therefore connects a dynamic address-and-permission check to an OS-visible fault without equating that check with any one bug class.

Structural Signature¶

The mandatory roles are:

an executing thread issuing a read, write, instruction fetch, or other memory access;
a process virtual address space divided into mapped and unmapped regions;
per-mapping permissions such as readable, writable, executable, user-accessible, or protection-key constrained;
processor translation and protection hardware evaluating the address and access type;
a violated predicate: no usable translation exists, or the translation exists but denies the requested operation;
a synchronous trap into the operating-system kernel, attributable to the faulting instruction;
kernel policy that either resolves the underlying page fault or classifies it as an invalid user access;
a process-visible signal or exception carrying at least a fault class and usually an address;
a disposition such as debugger interception, handler invocation, abnormal termination, and optional core dump; and
platform-specific naming that must not be mistaken for a universal hardware exception code.

The signature is:

executed memory reference + virtual mapping and permission check + unresolvable mapping or access violation → synchronous process protection fault.

The key invariant is enforcement. The attempted operation does not complete as an ordinary authorized memory access. Control transfers through hardware and kernel layers before the process can continue, terminate, or be inspected.

What It Is Not¶

A segmentation fault is not synonymous with null dereference. Null dereference is a program operation applied to an absent reference; it is one common cause. If the null address is mapped or the operation is optimized away, no segmentation fault need appear. A segmentation fault can also arise at non-null addresses and from valid mappings with the wrong permissions.

It is not identical to a page fault. A page fault is a processor-level event raised during address translation or permission checking. Many page faults are expected and resolvable: the kernel may demand-load a page, grow a stack, or perform copy-on-write, then restart the instruction^[3]. A segmentation fault is the process-level outcome when the attempted access is invalid under the operating system's policy and cannot be resolved normally.

It is not necessarily a bus error. POSIX distinguishes invalid virtual-memory references from access to an undefined portion of a memory object or alignment/physical-address failures, though exact signal mapping varies by architecture^[1].

It is not the same as a program crash. A crash can result from aborts, illegal instructions, arithmetic traps, uncaught exceptions, resource exhaustion, or explicit termination. Segmentation faults often crash a process because termination is the default action, but handlers and debuggers may intercept the signal or exception.

It is not a proof of exploitability, nor merely a C-language rule. Memory-corruption defects can create security vulnerabilities, but a particular fault may be harmless, intentionally generated, or fail closed. The mechanism arises at the hardware/OS protection boundary across languages.

Scope of Application¶

The abstraction belongs to operating systems, computer architecture, systems programming, native-code debugging, runtime implementation, and software security. Kernel developers use it to classify the terminal branch of virtual-memory fault handling. Debuggers use the synchronous event to stop at the faulting instruction, inspect registers, mappings, stack state, and the fault address, and recover a causal chain.

Systems programmers use the category to separate root cause from manifestation. A write to a read-only mapping points toward permission misuse; an access just beyond a guard page may indicate stack overflow; a fault at a small address often suggests a null base plus field offset; a changing address across runs can suggest lifetime corruption. These are heuristics, not definitions.

Runtime implementers may intentionally use protected pages and fault handling for stack guards, write barriers, lazy commitment, sandbox boundaries, just-in-time compilation transitions, or emulated memory. In those cases the hardware event is expected and the runtime or kernel may handle it. “Segmentation fault” ordinarily names the invalid process-visible outcome rather than every internal page fault.

Security analysis treats the event as a detection surface. Memory-safe languages and hardening mechanisms aim to prevent or contain the invalid references that lead to faults, while non-executable mappings, guard pages, address-space layout randomization, and protection keys change which corrupt operations complete^[4]. A segfault establishes a failed access, not why the invalid state arose or whether an attacker controls it.

Clarity¶

A segmentation-fault report should answer:

Which platform, architecture, process, and thread produced the event?
What signal or exception code was reported?
What instruction faulted and what operation did it attempt?
What virtual address was referenced?
Was the address unmapped, or did a mapping deny read, write, or execute access?
Could the underlying page fault have been resolved, and why was it not?
What were the relevant page-table, mapping, stack, and register states?
Did a handler or debugger intercept the event, or did default termination occur?
Is the suspected source defect a null dereference, bounds error, lifetime error, stack exhaustion, code injection, or something else?
Is the failure reproducible, or sensitive to layout and scheduling?

The most important distinction is between the proximate protection violation and the root software cause. SIGSEGV identifies the former. A stack trace, memory map, sanitizer report, and program history are needed to establish the latter.

Manages Complexity¶

The concept compresses many low-level translation and protection states into a stable diagnostic branch: the instruction attempted an address operation; hardware checked a mapping and permissions; the kernel could not legitimize the access; the process received a synchronous protection event. This is more informative than undifferentiated “crash” while remaining independent of the many possible source defects.

It also separates three investigation layers. At the language layer, an operation may have undefined behavior or violate a runtime rule. At the architecture layer, a concrete instruction and address trigger translation or protection machinery. At the OS layer, the kernel resolves a valid fault or emits a signal/exception. Mapping evidence to the correct layer prevents mistaken deductions—for example, concluding that every C out-of-bounds access must immediately fault.

The standardized POSIX split between SEGV_MAPERR and SEGV_ACCERR further reduces the search space. Unmapped-address faults direct attention toward invalid pointer values, released mappings, or guard regions. Permission faults direct attention toward write protection, executable permissions, protection keys, or incorrectly classified mappings. Platform tools can add finer detail without changing the abstraction.

Abstract Reasoning¶

Let an access request be a=(v,o,m): virtual address v, operation o, and current machine/process context m. Translation and protection define a predicate P(a) that is true only if a present mapping covers v and grants o in context m. If P(a) is true, the access proceeds. If false, hardware traps.

The kernel then applies a resolution predicate R(a,s) against virtual-memory state s. A missing resident page may be populated; a copy-on-write operation may create a writable private page; a legitimate stack-growth fault may extend a mapping. If R succeeds, state changes and the instruction can restart. If R fails for a user-mode access, the kernel reports an invalid reference through the platform's process-event mechanism. This second branch, not the initial page fault alone, is the segmentation-fault identity.

This supports several falsifiers. A process terminated by SIGABRT without an invalid memory reference did not segfault. A demand page loaded and retried successfully was a page fault but not a process-visible segmentation fault. A source-level null dereference that never executes or that silently reads mapped memory is a defect but not an observed segmentation fault.

It also supports cautious reverse inference. A permission-denied fault narrows the proximate condition but does not uniquely determine the bug. Multiple causal histories can produce the same (instruction,address,operation) triple.

Knowledge Transfer¶

Within computing, the mechanism transfers across Unix-like signals, Windows structured exceptions, debugger stops, emulators, language runtimes, and sandboxed execution. The names and metadata differ, but the roles remain: attempted virtual-memory operation, mapping/permission predicate, hardware trap, kernel classification, and process disposition.

It transfers from debugging to security analysis. A reproducible crash input supplies a concrete failed access; exploitability analysis then asks whether the attacker controls the address, value, operation, or control flow and whether mitigations constrain them. The segmentation fault is evidence at the enforcement boundary, not the security conclusion itself.

Outside computing, “segmentation fault” is usually metaphor. A generic boundary violation followed by enforcement is structurally portable and already covered by Access Control, Constraint, Boundary, and Detection. The address translation, page permissions, synchronous trap, kernel, signal, and core-dump vocabulary does not travel. Cross-domain use should therefore route through those primes rather than promote this domain event to a universal abstraction.

Examples¶

Unmapped address. A native program computes a wild pointer and reads an address outside every valid mapping. Hardware raises a translation fault; the kernel finds no legitimate mapping to populate and delivers SIGSEGV with an unmapped-address code.

Permission violation. A thread writes to a page mapped read-only. Translation exists, but the access type violates the mapping's permissions. POSIX systems can report SEGV_ACCERR; Windows can report an access-violation exception.

Demand paging, not a segfault. A valid file-backed page is not resident. The processor faults, the kernel loads the page, updates the translation, and restarts the instruction. The program sees no SIGSEGV. This is the canonical boundary between a resolvable page fault and segmentation fault.

Null-derived address. Code dereferences a null pointer plus a field offset. If the resulting low address is unmapped, the process faults. The null dereference is the root program operation; the segmentation fault is the platform manifestation.

Stack guard. Unbounded recursion consumes the mapped stack until a write reaches a protected guard region. The protection event may be delivered as SIGSEGV or a platform-specific stack-overflow exception. Stack exhaustion is the cause; segmentation fault is one possible manifestation.

Intentional probe. A runtime protects a page and catches the resulting fault to implement a barrier or guarded region. The same hardware path occurs, but a deliberate handler may resolve or redirect it rather than accept the default crash.

Structural Tensions¶

Precise event versus ambiguous cause. The faulting instruction and address can be exact, while the corruption that produced them may have happened much earlier.

Protection success versus application failure. Terminating the process is operational failure for the application but successful enforcement of isolation for the system.

Uniform name versus platform variance. “Segfault” is conventional Unix language; Windows uses access violations, and architectures may map related hardware conditions to different signals.

Recoverable hardware fault versus terminal process fault. The same trap path handles normal demand paging and invalid access. Kernel resolution separates routine mechanism from failure outcome.

Fail-fast diagnosis versus availability. Immediate termination contains corruption and preserves evidence, while carefully designed handlers may support runtimes or recovery; unsafe continuation can compound damage.

Language defect versus concrete machine event. Undefined behavior permits many manifestations. A missing fault does not establish memory safety, and a fault does not identify the violated source rule uniquely.

Structural–Framed Character¶

Segmentation Fault is domain-specific and structural-leaning. It has a crisp causal sequence and objective recognition data: instruction, address, access type, mapping, permissions, trap, kernel decision, and process event. The mechanism transfers across several operating systems and architectures.

It nevertheless remains framed by computer architecture and OS institutions. Virtual addresses, page tables, privilege modes, kernels, POSIX signals, Windows exceptions, and core dumps are constitutive rather than incidental examples. The portable boundary-enforcement residue is already represented by existing primes, so the candidate does not clear the prime bar.

Structural Core vs. Domain Accent¶

The structural core is:

attempted operation + protected resource boundary + violated access predicate + enforcement transfer → denied operation and fault report.

The domain accent makes the attempted operation a memory read, write, or instruction fetch; the resource a virtual address mapping; the predicate a page/segment permission; the enforcement transfer a synchronous processor trap into a kernel; and the report SIGSEGV or an access-violation exception. It also supplies the resolution branch that distinguishes normal demand paging from an invalid access.

Without these commitments, the pattern reduces to access-control enforcement or constraint violation. That broader structure is useful, but it no longer identifies segmentation fault.

Access Control is the minimal prospective parent by composition. A segmentation fault presupposes an enforced authorization boundary over memory operations: a subject thread, an operation, a virtual-memory resource, permissions, and a reference monitor implemented jointly by hardware and kernel. The fault is the denial outcome, not a subtype of access control, so the edge is composition/presupposes/strict.

Boundary explains address-space separation. Constraint explains the admissible operation set. Detection explains fault recognition. Interruption and Exception Handling describe control transfer and disposition. Memory Management provides the virtual allocation and mapping context. Failure and Error are broader outcome categories.

Only Access Control is proposed as a DAG edge. The others are consequences, supporting mechanisms, or analytical neighbors.

Relationships to Other Abstractions¶

Current abstraction Segmentation Fault Domain-specific

Parents (1) — more general patterns this builds on

Segmentation Fault presupposes Access Control Prime

Access Control is the minimal prospective parent by composition.

Hierarchy paths (3) — routes to 3 parentless roots

Segmentation Fault → Access Control → Authority

Show alternative paths (2)

Neighborhood in Abstraction Space¶

Segmentation Fault sits in a sparse region of the domain-specific corpus (92^nd percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08

Not to Be Confused With¶

Null dereference: one root operation that may produce a segmentation fault, not the broader protection event.
Page fault: a hardware translation/protection event, often expected and resolved without notifying the process.
Bus error: commonly used for alignment, physical-address, or memory-object failures distinguished from SIGSEGV by POSIX, with architecture variance.
General protection fault: an x86 exception class whose OS handling may yield different process-visible outcomes.
Access violation: the Windows counterpart and a plausible cross-platform synonym only when scope is explicit.
Stack overflow: resource exhaustion that can manifest through a guard-page fault but may have a distinct exception.
Buffer overflow: an out-of-bounds access defect that can silently corrupt mapped memory rather than fault immediately.
Core dump: a diagnostic artifact that may be produced after termination, not the fault itself.
Crash: any abnormal program failure; segmentation fault is one specific cause.
Geological fault: an unrelated live catalog homonym concerning displaced rock.

References¶

[1] IEEE and The Open Group. The Open Group Base Specifications Issue 7, 2018 edition (IEEE Std 1003.1-2017, POSIX.1-2017). IEEE and The Open Group, 2018. The normative table in POSIX.1-2017 (Open Group Base Specifications Issue 7, 2018 edition), giving SIGSEGV the description 'Invalid memory reference' and the default action of abnormal termination; superseded by Issue 8 / IEEE Std 1003.1-2024. The normative POSIX.1-2017 definitions of SEGV_MAPERR ('Address not mapped to object'), SEGV_ACCERR ('Invalid permissions for mapped object') and si_addr ('Address of faulting memory reference'), which the standard itself notes 'may be inaccurate' on some implementations. POSIX.1-2017 (Open Group Base Specifications Issue 7, 2018 edition) separates SIGSEGV, 'Invalid memory reference', from SIGBUS, 'Access to an undefined portion of a memory object', with BUS_ADRALN and BUS_ADRERR for alignment and nonexistent-physical-address faults; the variation in how architectures map hardware faults to these signals is not something the standard states. registry ↩a ↩b ↩c

[2] Yosifovich, Pavel, et al. Windows Internals, Part 1: System architecture, processes, threads, memory management, and more, Seventh Edition. Microsoft Press, 2017. The Windows memory-management chapter covering page protection, Data Execution Prevention and page-fault handling — the path by which a reference the mapping does not permit becomes an access violation; Microsoft's own documentation supplies the constant names, defining EXCEPTION_ACCESS_VIOLATION as STATUS_ACCESS_VIOLATION. registry ↩

[3] Bovet, Daniel P. and Cesati, Marco. Understanding the Linux Kernel. O'Reilly Media, 2005. Bovet and Cesati's page-fault exception-handler section treats demand paging, stack-region expansion and copy-on-write in one place, distinguishing the faults the kernel resolves from the invalid accesses that terminate the process. registry ↩

[4] Szekeres, et al. “SoK: Eternal War in Memory”. 2013 IEEE Symposium on Security and Privacy, 2013. Szekeres et al. systematise memory-corruption defenses — type-safe languages, non-executable data and W⊕X, ASLR, and canary schemes — classifying each 'by the particular phase of exploit they try to inhibit'; the survey predates hardware protection keys, which are documented in the Intel architecture manuals instead. registry ↩