The Process Memory Layout

Reading from the low addresses up: the text segment holds machine code, mapped from the executable. Read-only data holds string literals and constants. Data holds initialised globals and statics (int limit = 100;), copied from the file at load. BSS holds zero-initialised globals and statics (static char buf[65536];); it occupies no bytes in the file — the loader just maps zero pages. Above that the heap begins and grows upward on demand. Far above, near the top of the user-space range, the stack starts and grows downward as functions are called. The gap in between is free virtual space, mostly used for memory-mapped files and shared libraries.

The two growing regions face each other on purpose: heap up, stack down, so neither needs a fixed size chosen at link time. On a 64-bit system the gap is enormous (Linux x86-64 gives user space 128 TiB with 4-level page tables), so "the heap ran into the stack" is not a real failure mode any more; on 32-bit systems with 2–3 GB it was.

Each region is mapped with page-level permissions and the MMU enforces them on every access. Text is readable and executable but not writable, so a stray write into code faults immediately instead of silently patching the program. Data, BSS, heap and stack are readable and writable but not executable (W^X), so a buffer overflow that lands attacker bytes on the stack cannot simply jump to them. Read-only data is exactly that: writing to a string literal in C is undefined behaviour precisely because it is mapped r-- and the write raises SIGSEGV.

The stack additionally has a guard page below it — an unmapped page that turns runaway recursion into a clean segmentation fault rather than silent corruption of whatever was mapped below (see Stack Overflow). Thread stacks get their own guard pages. The heap has no such guard; overrunning a heap buffer corrupts the neighbouring allocation and the symptom appears somewhere else, later, which is why heap corruption is the hardest class of memory bug to localise.

The picture is a model. A real process differs in several ways, and most of them are deliberate. ASLR randomises the base of the executable (if it is position-independent), the libraries, the heap and the stack on every launch so that an attacker cannot predict addresses. Shared libraries are mapped in the gap, each with its own text/data/BSS, so there are many small "layouts" inside the one process. `mmap` regions appear anywhere in the gap: large mallocs (above ~128 kB in glibc) become private anonymous mappings rather than heap growth, and memory-mapped files sit there too. Every thread gets its own stack, allocated with mmap in the gap, not below the main stack.

Language runtimes add their own structure on top. A JavaScript engine or a JVM reserves a large region and runs its own allocator and garbage collector inside it; from the kernel’s point of view that is one big anonymous mapping, and "the heap" the runtime reports is not the C heap. The kernel also maps a small page of its own — the vDSO — into every process so that gettimeofday and clock_gettime need no system call.

The practical rule: use the classic picture to reason about lifetime and permissions; use /proc/<pid>/maps (Linux), vmmap (macOS) or VMMap (Windows) to see what is actually there.

Linux exposes every mapping of a process as one line: address range, permissions, offset into the backing file, device and inode, and the path (or a bracketed name for anonymous regions). Below is a trimmed excerpt for a small dynamically linked server. Note the separate r--p, r-xp, r--p, rw-p mappings for the executable and again for libc — the linker splits each object into segments by permission — and the p (private, copy-on-write) versus s (shared) flag.