Memory Leaks in C: How They Happen and How to Find Them

A memory leak is not memory that vanished. It is memory that is still yours, still reserved, and that you have lost the ability to hand back - because the last pointer to it is gone. Nothing crashes. The program keeps running, a little heavier each time, until something eventually fails somewhere unrelated.

This page covers how leaks arise, the discipline that prevents most of them, and the two tools that find the rest.

What a Leak Looks Like

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

int main(void) {
    for (int i = 0; i < 3; i++) {
        int *block = malloc(1000 * sizeof *block);
        if (block == NULL) {
            return 1;
        }
        block[0] = i;
        printf("pass %d wrote %d\n", i, block[0]);
        /* no free - each pass abandons 4000 bytes */
    }

    printf("done (3 blocks leaked)\n");
    return 0;
}

Each iteration overwrites block with a fresh pointer. The previous block is still allocated; no variable holds its address; it can never be freed. Three iterations lose twelve kilobytes. A server doing this once per request loses it forever, at whatever rate requests arrive.

The fix is one line - free(block); at the end of the body - but recognizing where it belongs is the actual skill.

How Leaks Happen

1. The lost pointer

Any assignment to a pointer that still holds the only reference to a live block leaks it.

char *name = malloc(32);
name = malloc(64);     /* the first 32 bytes are now unreachable */

The loop above is the same bug wearing a loop. So is reassigning a struct field, and so is the realloc shorthand from calloc and realloc:

p = realloc(p, n);     /* on failure: p becomes NULL, old block orphaned */

2. The early return

Every path out of a function has to release what the function has already taken. The one that gets forgotten is always an error path.

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

/* BUG: the second failure path leaks 'a' */
int broken(int n) {
    int *a = malloc((size_t)n * sizeof *a);
    if (a == NULL) {
        return 0;
    }

    int *b = malloc((size_t)n * sizeof *b);
    if (b == NULL) {
        return 0;          /* 'a' is still allocated and now unreachable */
    }

    for (int i = 0; i < n; i++) {
        a[i] = i;
        b[i] = i * i;
    }
    int total = a[n - 1] + b[n - 1];

    free(a);
    free(b);
    return total;
}

int main(void) {
    printf("%d\n", broken(5));
    return 0;
}

The happy path is correct and the error path leaks, which is why this survives testing: the failing branch almost never runs during development. The fix is a single cleanup section each path jumps to:

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

int fixed(int n) {
    int *a = NULL;
    int *b = NULL;
    int total = 0;

    a = malloc((size_t)n * sizeof *a);
    if (a == NULL) {
        goto cleanup;
    }

    b = malloc((size_t)n * sizeof *b);
    if (b == NULL) {
        goto cleanup;
    }

    for (int i = 0; i < n; i++) {
        a[i] = i;
        b[i] = i * i;
    }
    total = a[n - 1] + b[n - 1];

cleanup:
    free(a);       /* free(NULL) is defined to do nothing */
    free(b);
    return total;
}

int main(void) {
    printf("%d\n", fixed(5));
    return 0;
}

This is the one use of goto that experienced C programmers actively recommend. It works because every pointer starts at NULL and free(NULL) is a no-op, so a single exit block is correct no matter how far the function got.

3. Unclear ownership

The subtlest leaks are not coding errors at all - they are two functions disagreeing about whose job it was.

char *build_message(void);   /* does the caller free this? */
void  store(char *text);     /* does store take ownership? */

If build_message returns allocated memory and store copies it, the caller must free. If store keeps the pointer, the caller must not. Nothing in the code says which, so one of the two assumptions gets made twice - and you get either a leak or a double free.

The remedy is a convention, stated in a comment beside every function that allocates:

/* Returns a newly allocated string; the caller must free it. */
char *build_message(void);

/* Takes ownership of 'text'; it will be freed by store_free(). */
void store(char *text);

Write the rule at the function, not in a design document. It is the single highest-value habit in C memory management.

The Ownership Discipline

Four rules cover nearly everything:

1. Every allocation has exactly one owner - one piece of code responsible for freeing it.
2. Pair each allocating function with a releasing one. vec_init / vec_free, config_load / config_free. The symmetry makes a missing call visible.
3. Free in the same layer that allocated, unless the function's comment explicitly transfers ownership.
4. Set a pointer to NULL after freeing it, so a later accidental use crashes at the fault site instead of corrupting the heap quietly.

Finding Leaks: valgrind

On Linux, valgrind needs no recompilation, though debug symbols make the report readable:

gcc -g -O0 program.c -o program
valgrind --leak-check=full --show-leak-kinds=all ./program

For the leaking loop at the top of this page, the report ends with something like:

==12345== HEAP SUMMARY:
==12345==     in use at exit: 12,000 bytes in 3 blocks
==12345==   total heap usage: 3 allocs, 0 frees, 12,000 bytes allocated
==12345==
==12345== 12,000 bytes in 3 blocks are definitely lost in loss record 1 of 1
==12345==    at 0x4C2FB0F: malloc (vg_replace_malloc.c:299)
==12345==    by 0x108671: main (program.c:6)
==12345==
==12345== LEAK SUMMARY:
==12345==    definitely lost: 12,000 bytes in 3 blocks

Read it from the bottom. "definitely lost" means no pointer to the block existed at exit - a real leak. The stack trace names the line of the malloc that created it, not the line where it was lost, which is usually enough to find the missing free.

Two other categories appear:

• indirectly lost - blocks reachable only through a block that was itself lost, such as the elements of a leaked linked list. Fix the "definitely lost" one and these disappear.
• still reachable - allocated at exit but with a live pointer, typically a global cache. Not a leak in the dangerous sense, but worth freeing so the report stays empty.

Valgrind also catches reads of uninitialized memory and writes past the end of a block, which is often how you discover the bug behind the leak.

Finding Leaks: AddressSanitizer

AddressSanitizer is built into GCC and Clang, runs far faster than valgrind, and works where valgrind does not (including current macOS):

gcc -g -fsanitize=address -fno-omit-frame-pointer program.c -o program
./program

The leak report prints at exit automatically:

=================================================================
==12345==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 12000 byte(s) in 3 object(s) allocated from:
    #0 0x7f... in malloc
    #1 0x1086... in main program.c:6

SUMMARY: AddressSanitizer: 12000 byte(s) leaked in 3 allocation(s).

ASan also turns use-after-free and heap buffer overflows into immediate, clearly labeled aborts rather than mysterious corruption later. Build your test runs with it on; build releases with it off, since it costs memory and speed.

If leak detection does not fire on your platform, set ASAN_OPTIONS=detect_leaks=1 in the environment before running.

Fixing a Leaky Program Step by Step

Here is a small program with three separate leaks:

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

char *shout(const char *text) {
    size_t len = strlen(text);
    char *out = malloc(len + 1);
    if (out == NULL) {
        return NULL;
    }
    for (size_t i = 0; i < len; i++) {
        out[i] = (char)(text[i] - 32 * (text[i] >= 'a' && text[i] <= 'z'));
    }
    out[len] = '\0';
    return out;
}

int main(void) {
    /* leak 1: the result of shout is never freed */
    printf("%s\n", shout("hello"));

    /* leak 2: buf is overwritten, losing the first block */
    char *buf = malloc(16);
    buf = malloc(32);
    strcpy(buf, "second block");
    printf("%s\n", buf);
    free(buf);

    /* leak 3: early return skips the free */
    int *nums = malloc(4 * sizeof *nums);
    if (nums == NULL) {
        return 1;
    }
    nums[0] = 1;
    if (nums[0] != 0) {
        printf("bailing out\n");
        return 0;
    }
    free(nums);
    return 0;
}

Valgrind reports three "definitely lost" records with three different line numbers. Fixed one at a time:

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

/* Returns a newly allocated string; the caller must free it. */
char *shout(const char *text) {
    size_t len = strlen(text);
    char *out = malloc(len + 1);
    if (out == NULL) {
        return NULL;
    }
    for (size_t i = 0; i < len; i++) {
        out[i] = (char)(text[i] - 32 * (text[i] >= 'a' && text[i] <= 'z'));
    }
    out[len] = '\0';
    return out;
}

int main(void) {
    /* fix 1: hold the pointer, use it, free it */
    char *loud = shout("hello");
    if (loud == NULL) {
        return 1;
    }
    printf("%s\n", loud);
    free(loud);

    /* fix 2: one allocation, sized correctly the first time */
    char *buf = malloc(32);
    if (buf == NULL) {
        return 1;
    }
    strcpy(buf, "second block");
    printf("%s\n", buf);
    free(buf);
    buf = NULL;

    /* fix 3: every exit path frees */
    int *nums = malloc(4 * sizeof *nums);
    if (nums == NULL) {
        return 1;
    }
    nums[0] = 1;
    if (nums[0] != 0) {
        printf("bailing out\n");
        free(nums);
        return 0;
    }
    free(nums);
    return 0;
}

Fix 1 is the ownership comment made real: shout allocates, main frees. Fix 2 removes the doubled allocation entirely rather than freeing the first - the simpler code is also the correct code. Fix 3 adds the missing free on the early return; with more allocations in play, the single cleanup: label shown earlier scales better than repeating the frees.

Habits That Prevent Leaks

• Write the free immediately after writing the malloc, then fill the code in between.
• Give every allocating function a matching freeing function.
• State ownership in a comment on any function that returns or takes a pointer it allocated.
• Use one cleanup: exit block in functions holding several allocations.
• Run your tests under -fsanitize=address as a matter of course, not only when something looks wrong.
• Treat "definitely lost: 0 bytes" as part of a passing test run.