Memory Errors and the Defensive Programmer

The four heap sins

In lesson 6 we listed them in a callout. Now let's meet each one properly — what it looks like in code, what actually happens at the machine level, and how to prevent it.

Sin 1 — Memory leak

void greet(const char *name) {
    char *msg = malloc(100);    // 100 bytes on the heap
    sprintf(msg, "Hello, %s!", name);
    printf("%s\n", msg);
    // function returns — msg goes out of scope
    // the 100 bytes are still claimed, but no pointer reaches them
}

/* printf  → writes to stdout (the screen) */
printf("Hello, %s!\n", name);

/* sprintf → writes to a char buffer */
sprintf(msg, "Hello, %s!", name);
// msg now contains "Hello, Wojtek!"

/* snprintf → same, but capped at n bytes (safer) */
snprintf(msg, 100, "Hello, %s!", name);

Every time greet is called, 100 bytes vanish. In a short-lived program, you'd never notice. In a server running for weeks, it slowly bleeds to death. The fix is trivial:

    free(msg);    // give it back before the pointer dies

Leak = lost pointer + surviving allocation. If the pointer is still in scope, it's not a leak yet — just sloppy. A leak happens the instant the last pointer to an allocation is gone without a free.

char *s = malloc(100);
s = "literal";     // old malloc'd block is now unreachable — leaked!

Sin 2 — Dangling pointer

int *p = malloc(sizeof(int));
*p = 42;
free(p);
// p still holds the address — but the heap has reclaimed it
printf("%d\n", *p);    // UB: use-after-free (sin 4)

After free(p), p is not set to NULL. C doesn't do that for you. The pointer still holds the old address. The heap allocator may reuse that address for the next malloc call — so reading through p might silently read someone else's data.

free(p);
p = NULL;    // always nullify after free

Sin 3 — Double free

int *p = malloc(sizeof(int));
free(p);
free(p);    // double free — UB

What actually happens? The heap allocator maintains an internal data structure (think of it as a list of free blocks). When you free(p) the first time, the block is added to the free list. The second free(p) tries to add the same block again — corrupting the list. Modern allocators detect this and abort, but you still have a bug.

That p = NULL; habit from sin 2 also prevents this one: free(NULL) is defined to be a no-op. So if you accidentally call free(p) twice and p is NULL, nothing bad happens.

free(p);
p = NULL;
// later:
free(p);     // no-op, totally safe

Sin 4 — Use-after-free

This is sin 2 + sin 3's evil cousin. Not only do you still have the pointer — you're using it.

char *s = malloc(10);
strcpy(s, "secret");
free(s);

char *t = malloc(10);       // allocator may reuse the same address!
strcpy(t, "other");

printf("%s\n", s);            // prints "other" — or "secret" — or crashes

This is the worst kind of memory bug because it might not crash. The program appears to work. The corrupted data propagates silently. In a real system, this is how passwords leak, databases corrupt, and security vulnerabilities are born.

Bonus: uninitialized memory

Not technically a heap sin — it happens on both stack and heap — but it's closely related:

int *arr = malloc(5 * sizeof(int));
printf("%d\n", arr[2]);    // whatever bytes were there before

malloc does not zero memory. You get whatever was in that region last — could be zeros (lucky), could be old data from a freed allocation, could be anything. If you need zeros, use calloc, or explicitly zero the memory yourself.

The ownership rule — one allocator, one freer

Here's the mental model that prevents most of these bugs:

For every allocation, ask: who owns this memory? The owner is responsible for calling free — exactly once, when done. If ownership is unclear, you get leaks (nobody freed) or double-frees (everybody freed).

Common ownership patterns:

int *bad(void) {
    int x = 42;
    return &x;      // x dies when the function returns — dangling pointer
}

Undefined behavior — what it really means

The book's table from chapter 26 is worth reproducing. Undefined behavior isn't "it crashes." It's "the compiler is allowed to assume you never did this, and may optimize accordingly."

Enter Valgrind — the memory debugger

You now have the theory. But how do you find these bugs in practice? Reading code carefully catches some. For the rest, there's Valgrind — a tool that runs your program in an instrumented environment and reports every memory error and leak it finds.

Basic usage:

$ gcc -g buggy.c -o buggy        # -g adds debug symbols (line numbers!)
$ valgrind ./buggy

Reading the output is a skill in itself. Here's the anatomy of a leak report:

==12345== HEAP SUMMARY:
==12345==     in use at exit: 400 bytes in 10 blocks
==12345==   total heap usage: 14 allocs, 4 frees, 1,200 bytes allocated
==12345==
==12345== LEAK SUMMARY:
==12345==     definitely lost: 400 bytes in 10 blocks
==12345==     indirectly lost: 0 bytes in 0 blocks
==12345==       possibly lost: 0 bytes in 0 blocks
==12345==     still reachable: 0 bytes in 0 blocks

The key line: "definitely lost: 400 bytes in 10 blocks". That's 10 mallocs that never got free'd. For the line numbers, run with --leak-check=full (which is actually the default):

==12345== 400 bytes in 10 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x483DA83: malloc (vg_replace_malloc.c:381)
==12345==    by 0x1091A7: create_array (buggy.c:15)
==12345==    by 0x109187: main (buggy.c:8)

There it is: buggy.c:15 inside create_array. You allocated something on line 15 that was never freed.

Alternative: AddressSanitizer

Valgrind is great but slow (~10-20× slowdown). For faster feedback during development, use AddressSanitizer (ASan) — it's built into GCC and Clang:

$ gcc -g -fsanitize=address buggy.c -o buggy
$ ./buggy

ASan catches the same errors but at near-native speed. It's the tool most C developers reach for first during active development. Use Valgrind for final verification or when ASan isn't available.

Check yourself

char *make_greeting(const char *name) {
    char *buf = malloc(100);
    sprintf(buf, "Hello, %s!", name);
    return buf;
}
  
Show answer
  The caller. The function returns the pointer, transferring ownership. The caller must free it when done. This is the same pattern as mystrdup from lesson 6. The function can't free it — the caller needs the data! Document this ownership transfer in a comment or in your head: "returns malloc'd memory; caller frees."
  

int *p = malloc(sizeof(int));
*p = 42;
free(p);
printf("%d\n", *p);
  
Show answer
  Undefined behavior. After free(p), the pointer p is dangling. Dereferencing it (the *p in printf) is use-after-free. It might print 42 (if the heap hasn't reused the memory yet), print garbage, or crash. On your machine today it probably prints 42 — which is the dangerous part. It looks correct but isn't.
  

void process(void) {
    int *a = malloc(100);
    int *b = malloc(200);
    a = b;
    free(a);
}
  
Show answer
  One leak — 100 bytes. a originally pointed to the 100-byte block. Then a = b; overwrites a with the address of the 200-byte block. Now nothing points to the 100-byte block — it's leaked. free(a) frees the 200-byte block (since a now holds b's address). The 200-byte block is fine. But the original 100-byte block is gone forever.
  

The defensive checklist

Print this. Stick it on your monitor. Every malloc you write should pass through this checklist:

1. Check for NULL. if (!ptr) { handle error; } — every single malloc/calloc/realloc.
2. Pair every malloc with a free. Trace ownership: who allocated, who frees, and when.
3. Nullify after free. free(p); p = NULL; — prevents use-after-free and double-free.
4. Never return stack pointers. If a value must outlive the function, malloc it.
5. Don't overwrite your last pointer. Before p = something_else;, make sure the old allocation is freed.
6. Compile with -g and test with Valgrind. Make it a habit, not an afterthought.