Every way a program can crash

Formal. The kernel's handler returns to the address the processor saved when the exception was taken:

• Fault (a page fault, x86-64 divide error, a general protection fault): the saved address is the faulting instruction itself, which had no effect; after the kernel fixes the cause, it runs again.
• Trap (a system call, an x86-64 int3 breakpoint): the event is reported after the instruction, and execution resumes at the next instruction. (RISC-V records the address of ecall itself, and the kernel adds 4 before returning.)
• Abort (a machine check, a double fault): the state can't be trusted, there is no restart, and the program or the machine stops.
• External interrupt: taken between two instructions, unrelated to either; the program resumes at the first instruction not yet done.

In plain English. A fault means "this instruction could not run", so once the problem is fixed the same instruction is tried again. A trap means "this instruction asked to stop here", so it carries on after it. An abort means something is too broken to carry on. An interrupt just slots in between two instructions and then lets the program carry on.

Example. A store to a page that hasn't been given memory yet faults; the kernel supplies the page and the same store runs again, this time successfully. A syscall instruction traps; the kernel does the work and returns to the instruction after syscall. An integer divide by zero also faults, but re-running the division would fault again, so instead the kernel reports it to the program (Linux and macOS send SIGFPE).

Why this rule exists. Restarting the exact instruction is what lets the operating system fill memory in lazily and invisibly, while continuing after a trap is what makes a system call behave like a function call.

The address a program tried to use when a page fault happened, which the processor records for the operating system.

A pointer that still holds the address of something that has already been freed or has gone out of scope.

A strip of forbidden addresses just past the end of the stack, placed there so running off the end is caught instead of silently trampling other memory.

The signal a program sends itself when a library check decides it must stop at once, for example a failed assert or a detected heap problem.

Formal. In a function compiled with a stack protector, the prologue copies a per-process random guard value G into a canary slot placed between the frame's local buffers (at lower addresses) and its saved registers and return address (at higher addresses). Before returning, the epilogue reloads the slot and compares it with G:

1. If slot = G, the function restores its saved registers and returns.
2. If slot ≠ G, a failure handler ends the process without returning (__stack_chk_fail on Linux and macOS; on Windows the comparison itself is a call to __security_check_cookie, which reports the failure).

Because the stack grows down and an overflow writes upward through consecutive addresses, any contiguous overflow of a local buffer that reaches the saved registers or the return address must overwrite the canary slot first, and is detected at step 2 unless it rewrote the slot with exactly G.

In plain English. The compiler puts a secret number between your arrays and the address the function will return to, and checks it on the way out. Writing far enough past an array to reach the return address means writing over the secret number, so the program notices and stops before the bad return happens.

Example. On Linux x86-64, clang -O1 -fstack-protector-strong compiles a function with a local char buf[16] into a prologue that loads the guard from fs:0x28 (thread-local storage) and stores it in a slot above buf, and an epilogue that compares that slot with fs:0x28 and calls __stack_chk_fail if they differ. A copy that runs far enough past the end of buf to reach the saved return address changes the slot on the way, so the process is ended at the check, with the C library's "stack smashing detected" message (SIGABRT), instead of returning to a damaged address.

Why this rule exists. It says exactly what the protection covers, and so what it doesn't: the check runs only at return, only catches contiguous overwrites that cross the slot, and says nothing about heap memory, out-of-bounds reads, or locals and pointers corrupted and used before the function returns.

A breakpoint made by temporarily writing a special trap instruction over the program's code at the chosen spot.