Memory Errors and Their Diagnosis

1The five classes

What unites them is action at a distance. The line that does the damage and the line that fails are usually far apart, often in unrelated code. A program can write past a buffer for months before a slightly different allocation pattern makes the corruption land somewhere fatal.

This is why debugging memory errors by reading code and adding printf is so unproductive, and why the tools in section 3 are not optional extras.

2Each class in detail

Leak

void process(void)
{
    char *buffer = malloc(1024);
    if (something_failed()) {
        return;                    /* leaked: early return skips the free */
    }
    free(buffer);
}

Leaks on the error path are by far the most common kind, because the happy path gets tested and the error path does not. A short-lived program can survive leaking — the operating system reclaims everything at exit — but a server or a long-running tool cannot. Week 27's goto cleanup idiom exists precisely to give every path one exit.

Use after free

free(node);
printf("%d\n", node->value);       /* the block may already be reused */

After free, the block belongs to the allocator, which may hand it to the next malloc. Reading gives stale or foreign data; writing corrupts whatever now lives there. It frequently appears to work, because the allocator has not yet reused the block — which is why it survives testing.

The defence is a habit: set the pointer to NULL immediately after freeing. A later use then crashes instantly at the guilty line instead of corrupting something.

Double free

free(p);
…
free(p);                           /* corrupts the allocator's bookkeeping */

Usually arises when two pieces of code each believe they own a block — the ownership question from week 19, left unanswered. Modern allocators detect the simple case and abort with a message; the subtle cases silently corrupt the heap. The NULL habit fixes this too, since free(NULL) is defined to do nothing.

Overrun

int *a = malloc(10 * sizeof *a);
a[10] = 0;                         /* one past the end */

Identical in nature to week 12's array overflow, but on the heap the neighbour is usually the allocator's own metadata — the block header recording sizes and links. Corrupting it means the next unrelated malloc or free crashes, with a backtrace pointing at innocent code.

Invalid free

int local = 5;
free(&local);                      /* not from malloc */

char *p = malloc(100);
free(p + 10);                      /* not the start of the block */

Only a pointer returned by malloc, calloc, or realloc may be freed, and only the exact value returned. Keep the original pointer; walk a copy.

3The tools

AddressSanitizer

gcc -std=c17 -Wall -Wextra -g -fsanitize=address -o prog prog.c
./prog

A compiler instrumentation that checks every memory access. It catches overruns, use-after-free, double free, invalid free, and — with LeakSanitizer, which is on by default on Linux — leaks at exit. Costs roughly 2× in speed and 3× in memory, which is irrelevant during development.

Use it for every build while you are writing code. It is the single highest-value flag in this course.

Valgrind

valgrind --leak-check=full --track-origins=yes ./prog

Runs an unmodified binary under emulation, so no recompilation is needed — which matters when you did not build the program. It also detects uninitialized reads, which AddressSanitizer does not; --track-origins=yes then tells you where the uninitialized value came from. The cost is 10–50× slowdown.

They are complements. Develop under AddressSanitizer; run Valgrind before a release, and when you need to inspect a binary you cannot rebuild.

4Reading a report

==12345==ERROR: AddressSanitizer: heap-use-after-free on address 0x602000000010
READ of size 4 at 0x602000000010 thread T0
    #0 0x55e in main leaky.c:42                     <- where it was USED
    #1 0x7f2 in __libc_start_main

0x602000000010 is located 0 bytes inside of 40-byte region
freed by thread T0 here:
    #0 0x7f8 in free
    #1 0x55d in main leaky.c:40                     <- where it was FREED

previously allocated by thread T0 here:
    #0 0x7f9 in malloc
    #1 0x55c in main leaky.c:36                     <- where it was ALLOCATED

Read it in four parts:

1. The error type. heap-use-after-free, heap-buffer-overflow, stack-buffer-overflow, double-free — each names the class from section 1.
2. The access. READ of size 4 tells you what the program was doing.
3. Three stack traces. Where it was used, where it was freed, where it was allocated. Those three lines are usually the entire diagnosis.
4. The offset. 0 bytes inside of 40-byte region, or 4 bytes to the right of, which pinpoints an off-by-one immediately.

5Worked example: five bugs, seeded and found

This takes the growable array from week 19 and introduces each defect behind a compile-time switch, so you can enable exactly one and watch the tool describe it.

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

/* Build with -DBUG=1 … -DBUG=5 to enable one defect at a time.
   Build with no -DBUG for the clean version. */
#ifndef BUG
#define BUG 0
#endif

typedef struct {
    int    *data;
    size_t  count;
    size_t  capacity;
} IntArray;

static bool array_init(IntArray *a, size_t capacity)
{
    a->data = malloc(capacity * sizeof *a->data);
    if (a->data == NULL) {
        return false;
    }
    a->count = 0;
    a->capacity = capacity;
    return true;
}

static void array_destroy(IntArray *a)
{
    free(a->data);
    a->data = NULL;            /* the habit that prevents bugs 2 and 3 */
    a->count = a->capacity = 0;
}

static bool array_push(IntArray *a, int value)
{
    if (a->count == a->capacity) {
        size_t bigger_capacity = a->capacity * 2;
        int *bigger = realloc(a->data, bigger_capacity * sizeof *bigger);
        if (bigger == NULL) {
            return false;
        }
        a->data = bigger;
        a->capacity = bigger_capacity;
    }
    a->data[a->count++] = value;
    return true;
}

int main(void)
{
    printf("built with BUG=%d\n\n", BUG);

    IntArray a;
    if (!array_init(&a, 4)) {
        return EXIT_FAILURE;
    }
    for (int i = 1; i <= 6; i++) {
        array_push(&a, i * 10);
    }
    printf("array holds %zu of %zu: ", a.count, a.capacity);
    for (size_t i = 0; i < a.count; i++) printf("%d ", a.data[i]);
    putchar('\n');

#if BUG == 1
    /* LEAK: allocate and forget. */
    char *forgotten = malloc(64);
    strcpy(forgotten, "nobody will free me");
    printf("leaked: %s\n", forgotten);
    /* no free */

#elif BUG == 2
    /* USE AFTER FREE. */
    free(a.data);
    printf("after free, a.data[0] = %d\n", a.data[0]);
    a.data = NULL;

#elif BUG == 3
    /* DOUBLE FREE. */
    free(a.data);
    free(a.data);
    a.data = NULL;

#elif BUG == 4
    /* HEAP OVERRUN: one element past the end. */
    printf("writing a.data[%zu] with capacity %zu\n", a.capacity, a.capacity);
    a.data[a.capacity] = 999;

#elif BUG == 5
    /* INVALID FREE: not the pointer malloc returned. */
    free(a.data + 1);
    a.data = NULL;
#endif

    array_destroy(&a);
    puts("finished");
    return EXIT_SUCCESS;
}

Run each one

for b in 0 1 2 3 4 5; do
  gcc -std=c17 -Wall -Wextra -g -fsanitize=address -DBUG=$b -o bug$b bugs.c
done

./bug0     # clean
./bug1     # leak
./bug2     # use after free
./bug3     # double free
./bug4     # overrun
./bug5     # invalid free

What each reports

BUG=1 — leak. The program finishes normally, then:

==1234==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 64 byte(s) in 1 object(s) allocated from:
    #1 0x... in main bugs.c:76
SUMMARY: AddressSanitizer: 64 byte(s) leaked in 1 allocation(s).

Note that the output appears only at exit and the exit status becomes non-zero — which is how a leak fails a build in week 35's continuous integration.

BUG=2 — use after free. Three traces: used at line 82, freed at line 81, allocated at line 22. Without the sanitizer this program prints 10 quite happily, because the block has not been reused yet.

BUG=3 — double free. attempting double-free on 0x..., with the free site and the original allocation both named. Without the sanitizer, glibc prints free(): double free detected in tcache 2 and aborts — useful, but with no indication of where.

BUG=4 — overrun. The most instructive one:

==1234==ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 4 at 0x602000000030 thread T0
    #0 0x... in main bugs.c:95
0x602000000030 is located 0 bytes to the right of 32-byte region
allocated by thread T0 here:
    #1 0x... in array_push bugs.c:44

"0 bytes to the right of a 32-byte region" is an off-by-one stated in the clearest possible terms. Compare with the unsanitized build, which prints finished and exits successfully while having corrupted the allocator's metadata.

BUG=5 — invalid free. attempting free on address which was not malloc()-ed, plus the allocation site of the real block.

The same bugs under Valgrind

gcc -std=c17 -Wall -Wextra -g -DBUG=2 -o bug2_plain bugs.c
valgrind --leak-check=full ./bug2_plain

==9876== Invalid read of size 4
==9876==    at 0x...: main (bugs.c:82)
==9876==  Address 0x4a4b040 is 0 bytes inside a block of size 32 free'd
==9876==    at 0x...: free
==9876==    by 0x...: main (bugs.c:81)
==9876==  Block was alloc'd at
==9876==    by 0x...: array_push (bugs.c:44)

The same three facts in different words — and obtained without rebuilding with a special flag, which is what makes Valgrind valuable on binaries you did not compile.

One Valgrind catches that AddressSanitizer does not

int *p = malloc(4 * sizeof *p);
printf("%d\n", p[0]);          /* reading uninitialized heap memory */
free(p);

==9876== Conditional jump or move depends on uninitialised value(s)
==9876==  Uninitialised value was created by a heap allocation
==9876==    at 0x...: malloc

AddressSanitizer reports nothing here — the memory is legitimately owned, merely unwritten. This is why the two tools are complements rather than alternatives, and why calloc is worth preferring when you cannot guarantee every byte gets written.

6Habits that prevent rather than detect

7Common mistakes

9Where this leads

Week 21 turns to structures, which let you group related data into one object — and which immediately raise a harder version of this week's question, because a structure can own allocations of its own. The create/destroy pattern from week 19 becomes the standard answer, and week 33 makes it an opaque handle where the caller cannot see, or corrupt, the internals at all.