Why use a guard page at the end of a stack?

A strong answer

A strong candidate frames Why use a guard page at the end of a stack? around the exact memory layout, compiler semantics, and hardware execution model covered in Stack Allocation, Alignment, and Guard Pages with mmap and mprotect. Explain stack overflow detection: accessing the guard page triggers SIGSEGV instead of silent corruption.

When developers first build a toy user-space coroutine or green-thread scheduler, they often allocate fiber stacks using standard heap allocation:

While this appears to work in simple tests, it introduces a severe reliability and security flaw: Silent Heap Corruption on Stack Overflow.

In a production interview, always connect the specification rule to its concrete runtime consequence: state what lives on the stack versus the heap or static storage segment, how the compiler or operating system validates alignments, lifetimes, and error codes, and what happens under adversarial or boundary inputs (such as zero-length buffers, integer overflow, concurrent mutation, or partial I/O). Backing your explanation with a small trace of register/memory state transitions immediately separates senior systems engineers from candidates who only memorized syntax.

What the interviewer is listening for

• Mastery of core invariant: Allocate page-aligned virtual memory ranges using mmap with MAP_ANONYMOUS and MAP_STACK.
• Mastery of core invariant: Arm an inaccessible bottom guard page using mprotect(PROT_NONE) to trap stack overflows deterministically.
• Mastery of core invariant: Compute top-of-stack initial pointers conforming to downward growth and 16-byte System V ABI alignment.
• Hardware and ABI awareness: Explaining how sizes, alignments, calling conventions, or kernel boundaries behave on real 64-bit targets rather than relying on implementation-defined assumptions.
• Defensive engineering: Naming the exact compiler flags (-Wall -Wextra -Werror), static analyzers, or runtime sanitizers (-fsanitize=address,undefined,thread) that verify correctness in CI.

Common mistakes

• Explaining only surface syntax without tracing the underlying memory addresses, ownership lifetime, or kernel/user-space state transitions.
• Assuming undefined behavior (such as signed overflow, uninitialized reads, strict-aliasing violations, or dangling pointers) will "just work" because it passed an unoptimized -O0 debug build.
• Ignoring return codes, partial reads/writes, alignment padding, or cleanup paths when an allocation or syscall fails midway through a function.