Stack and Heap

Where a running program keeps its data: the fast, automatic call stack and the flexible, longer-lived heap.

Level: intermediate

What is it?

A process keeps data in several regions. The call stack holds one frame per active function call — parameters, locals, and a return address — allocated and freed automatically as calls begin and end. The heap holds objects whose size or lifetime is not known at compile time; someone must decide when to free them: you, a garbage collector, or a smart pointer. Code and static data live in their own regions.

Why does it matter?

'Segmentation fault', 'stack overflow', 'memory leak', and 'use after free' are all questions about these regions. The split also explains performance: stack access is cache-friendly and allocation is nearly free, while heap allocation costs more and can fragment.

Mental model

The stack is a pile of cafeteria plates: you only touch the top, and it is always tidy. The heap is a warehouse: you can store anything as long as you like, but you need a ledger to know what is where and when to clear it out.

How it works

Stack: LIFO, fixed maximum size, freed automatically on return. Locals and call frames live here.
Heap: allocated on request (malloc, new, object creation), freed manually, by a garbage collector, or by ownership rules.
A pointer or reference on the stack can point to an object on the heap. The reference dies with the frame; the object does not.
Returning a pointer to a local variable is a bug: the frame is gone, so the address is dangling.
In managed languages (Java, Python, JavaScript) objects live on the heap and the runtime reclaims them; the stack still holds frames and references.

Steps

Call pushes a frame
Locals live in the frame
Allocation reserves heap memory
Return pops the frame
Heap object lives until freed

Code example: One value in a frame, one on the heap

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int on_stack = 7;                        /* lives in main's frame */
    int *on_heap = malloc(sizeof *on_heap);
    *on_heap = 42;                           /* lives until we free it */
    printf("%d %d\n", on_stack, *on_heap);
    free(on_heap);                           /* forget this and it leaks */
    return 0;
}

Real-world usage

Diagnosing crashes: stack overflow versus heap corruption
Choosing between value types and heap-allocated objects
Understanding memory profiler output and leak reports

Common mistakes

Returning the address of a local variable.
Assuming garbage collection means memory cannot leak; holding references keeps objects alive.
Allocating large arrays as locals and overflowing the stack.

Interview questions

What is the difference between the stack and the heap?

The stack stores call frames and locals with automatic, LIFO lifetime and very cheap allocation. The heap stores objects with flexible size and lifetime that must be freed explicitly or by a collector, at higher cost.

What causes a stack overflow?

Too many nested calls (usually unbounded recursion) or very large local arrays exhaust the fixed-size stack, and the runtime terminates the program.

What is a dangling pointer?

A pointer to memory that has been freed or whose stack frame has returned. Dereferencing it is undefined behavior: it may read garbage, crash, or appear to work.