How Is Memory Organized — Stack, Heap, and Beyond?

After this lesson, you will be able to:

• Identify the five segments of a C program’s memory layout (text, data, BSS, heap, stack)
• Determine which memory segment a given variable resides in
• Explain how the stack grows and shrinks with function calls
• Compare stack and heap memory in terms of lifetime, size, and risks

Where Does Your Data Actually Live?

When you write int x = 42;, where does x exist? “In memory” is technically correct but not helpful. Your program’s memory is divided into distinct regions, each with different properties. Understanding which region holds what — and what happens when each region runs out — is the foundation for dynamic memory allocation.

The Memory Map

Program Memory Layout

When your compiled C program runs, the OS divides its memory into segments:

High addresses
┌──────────────────┐
│      Stack       │ ← Local variables, function calls
│        ↓         │   Grows DOWN
│                  │
│    (free space)  │
│                  │
│        ↑         │
│       Heap       │ ← Dynamic allocation (calloc/malloc)
│                  │   Grows UP
├──────────────────┤
│       BSS        │ ← Uninitialized globals (zeroed)
├──────────────────┤
│       Data       │ ← Initialized globals/statics
├──────────────────┤
│       Text       │ ← Your compiled code (read-only)
Low addresses
└──────────────────┘

The Stack

The stack holds:

• Local variables
• Function parameters
• Return addresses

void function_b(int y)
{
    int local_b = y * 2;    // On the stack
}

void function_a(void)
{
    int local_a = 5;         // On the stack
    function_b(local_a);
}

int main(void)
{
    int x = 42;              // On the stack
    function_a();
    return 0;
}

Each function call creates a stack frame — a block of memory containing its parameters and local variables. When the function returns, its frame is destroyed:

During function_b:          After function_b returns:
┌──────────────┐           ┌──────────────┐
│ function_b   │           │              │
│  y = 5       │           │ (reclaimed)  │
│  local_b = 10│           │              │
├──────────────┤           ├──────────────┤
│ function_a   │           │ function_a   │
│  local_a = 5 │           │  local_a = 5 │
├──────────────┤           ├──────────────┤
│ main         │           │ main         │
│  x = 42      │           │  x = 42      │
└──────────────┘           └──────────────┘

Key Insight: This is why you can’t return a pointer to a local variable — the stack frame is destroyed when the function returns. The pointer would point to reclaimed memory. Dynamic allocation (heap memory) solves this: heap memory persists until you explicitly free it.

The Heap

The heap holds dynamically allocated memory — memory you request at runtime with calloc/malloc and release with free:

int *arr = calloc(100, sizeof(int));    // 400 bytes on the heap
// ... use arr ...
free(arr);                               // Release back to the heap

Unlike stack memory, heap memory:

• Persists until you explicitly free it (or the program exits)
• Can be returned from functions safely
• Must be manually managed (no garbage collector)

The Data and BSS Segments

int global_init = 42;        // Data segment (initialized)
int global_uninit;           // BSS segment (zeroed by OS)
static int static_var = 10;  // Data segment (initialized)

These live for the entire program lifetime.

The Text Segment

Your compiled machine code lives here. It’s read-only — the OS prevents you from modifying it (which would corrupt your program).

Stack vs. Heap Summary

From Java: In Java, all objects live on the heap, and the garbage collector frees them automatically. Local primitives live on the stack. C gives you the same two regions — but you manually choose where data goes and when it’s released. The stack is automatic; the heap is manual.

You Now See the Machine

Understanding the memory layout means you can predict where variables live, why stack overflow happens (too many recursive calls), and why memory leaks occur (forgot to free heap memory). This mental model is the foundation for the next four lessons.

Next: dynamic memory allocation with calloc, malloc, and free. You’ll finally be able to create arrays whose size is determined at runtime — something Java’s new does behind the scenes.

Big Picture: The memory map is the mental model that ties everything together. When you debug a segfault, you’re asking “which segment did this pointer land in?” When you choose between a local array and calloc, you’re choosing between stack and heap. When you wonder why a server process uses 2 GB of RAM, you’re looking at heap growth. This diagram is the map you’ll reference for the rest of the course.