THE Stack vs. your stacks

An interactive tour of process memory on x86-64 Linux — with real-looking addresses. All addresses below are typical values you would see in gdb (ASLR changes them each run, but the shape is always this).

0Your three questions, answered first

💭 "I can write many stack data structures in C… so are there many stacks in memory?"

Yes and no. A Stack you write with malloc is just bytes in the heap — you can make 1000 of them. But THE stack is one special region the kernel creates per thread, and the CPU itself helps manage it: the RSP register and the push / pop / call / ret instructions are hardware support for exactly one stack at a time. See section 4.

💭 "How will my multi-threaded app look?"

One stack per thread. Thread stacks are just mmap'd blocks in the middle of the address space. All threads share the heap, globals and code — each thread only gets a private stack + private registers. See section 3.

💭 "How can ONE stack hold all my functions and all my data?!"

It doesn't — that's the trick. Functions live in the code segment, not the stack. The stack only holds the frames of calls that haven't returned yet — usually a chain of 5–50 frames, a few KB. Every ret frees a frame instantly, and the same bytes get reused by the next call. Big data goes to the heap. Watch it happen in section 2.

1The whole picture: one process's virtual address space

This is the "ultimate shape" you asked for. Hover / tap each segment. High addresses on top, like in your slide.

0xFFFFFFFFFFFFFFFF
🚫 Kernel spaceyour code can never touch this
0xFFFF800000000000+
0x00007FFFFFFFFFFF  ← top of user space (~128 TiB)
▼ Main thread stack (8 MiB) argv & envp sit at the very top; grows DOWN
0x00007FFFFFFFF000 0x00007FFFFFFDE000
📚 mmap region shared libs (libc.so, ld.so), mmap'd files… and thread stacks!
≈ 0x00007FFFF7D8A000 (libc.so lands here)
…an astronomically huge unmapped gap…~127 TiB of nothing — it's virtual, it costs zero RAM
▲ Heap malloc / free live here; grows UP
0x000055555555A000 →
🌐 Globals — .data & .bss global / static variables
0x0000555555558000
⚙️ Code — .text the machine instructions of main, add, printf… functions LIVE here
0x0000555555554000
unmapped — this is why NULL dereference crashes
0x0000000000000000

👆 Hover a segment

  • Every process gets its own private address space like this — your program thinks it owns all 128 TiB.
  • It's virtual: the 8 MiB stack is only a reservation; physical RAM pages appear the first time you touch them.
  • ASLR slides the segments to random bases each run — the order never changes.

2Watch ONE stack run a whole program

main() calls square_sum(3,4) which calls add(3,4). Step through and watch frames get pushed, used, and recycled. Keys: ← →

C source

x86-64 assembly (gcc -O0 style)

THE stack  ·  grows downward ⬇ (each row = 8 bytes)

libc main frame square_sum frame add frame RSP (top of stack) RBP (frame base)

CPU registers

2½So what if the calls never return? → stack overflow

The stack survives because frames are constantly freed by ret. Break that contract with infinite recursion and 8 MiB fills up:

void boom(int n) { boom(n + 1); }  // no base case, ~48 bytes per frame
depth = 0 calls  ·  stack used = 0 KiB / 8192 KiB
SIGSEGV — Segmentation fault (stack overflow)
RSP walked past the bottom of the stack region and touched the guard page — an intentionally unmapped page the kernel places below every stack. The CPU faulted, the kernel killed the process. ~174,000 frames deep. Normal programs are 10–50 frames deep — that's why 8 MiB is plenty.

3Multi-threading: one stack per thread, everything else shared

Click pthread_create() and watch new stacks appear in the mmap region. Each thread runs a different call chain at the same time — that's only possible because each has a private RSP.

threads: 1 (just main)
Main thread stack (8 MiB)
RSP = 0x00007FFFFFFFDF38 · running: main → square_sum → add
0x00007FFFFFFFF000 0x00007FFFFFFDE000
📚 shared libraries (libc.so …)
≈ 0x00007FFFF7D8A000
…huge unmapped gap…
🤝 Heap — SHARED by all threads
0x000055555555A000
🤝 Globals (.data/.bss) — SHARED
0x0000555555558000
🤝 Code (.text) — SHARED (all threads run the same functions)
0x0000555555554000

What this means

  • Private per thread: stack + registers (RSP, RIP, …). So local variables are naturally thread-safe.
  • Shared: heap, globals, code. So two threads touching one global/heap object need a mutex.
  • Thread stacks are created by pthread_create with plain mmap() — they're ordinary memory, just used as a stack because the new thread's RSP points into them.
  • Each stack has a guard page below it, so overflowing one thread's stack faults instead of silently smashing its neighbor.

4Your Stack struct vs. THE stack

The word "stack" is overloaded — this is the root of your confusion. Both of these exist at the same time, in different places:

your C code

typedef struct {
long data[8];
int top;
} Stack;
Stack *s1 = malloc(sizeof *s1); // heap!
Stack *s2 = malloc(sizeof *s2); // heap!
// make 1000 more if you want — they are
// just bytes YOU interpret as a stack.
// push() = data[++top] = v (your code)
// push = CPU instruction (THE stack)

s1 → lives in the HEAP at 0x000055555555A2A0

s2 → another one, also HEAP, at 0x000055555555A310

7+0x00
99+0x08
as many of these as malloc allows — millions

vs. THE stack

Created by the kernel (not by you) · one per thread · managed by the CPU's RSP register and push/pop/call/ret instructions · used automatically for every function call, local variable, and return address. You never malloc it and never free it.

5Recap — the mental model to keep

🧠 Functions don't live on the stack

Machine code sits in .text forever. A function only borrows stack space (a frame) while a call to it is in flight, and gives it back at ret. 10,000 functions in your app ≠ 10,000 frames — only the current call chain exists.

♻️ The stack is a recycler, not a warehouse

You saw the same addresses (0x7FFFFFFFDF38…) reused by add's dead frame, then overwritten later. That reuse is why one small region handles millions of calls — and why reading uninitialized locals gives garbage.

🗺️ The ultimate shape

Per process: code + globals + one heap + mmap area. Per thread: one stack + one register set. Your 1000 Stack structs? All just heap bytes. THE stack is the one with hardware and kernel support.

Offsets and frame sizes here follow the shape of gcc -O0 output but are simplified (real compilers pick different offsets, keep 16-byte alignment, and at -O2 may not use RBP or frames at all). Verify on your machine: gcc -O0 -g demo.c && gdb ./a.out, then b add, run, bt, info frame, x/16gx $rsp — you'll see addresses just like these.