C++ Memory Leaks — 1.5 GB After 50 Tab Cycles

Memory leaks are the silent killers of C++ applications. Unlike a crash that screams at you immediately, a memory leak is a slow bleed — your process's RSS (Resident Set Size) climbs steadily over hours or days, swap starts thrashing, and eventually the OOM killer on Linux terminates your process with no warning. This is exactly what happened in a famous 2015 Firefox bug where tab-related allocations were never freed, causing hundreds of megabytes of leak per browsing session. The C++ runtime has no garbage collector watching your back. Every byte you allocate is your responsibility to free.

The core problem is the gap between WHEN you allocate memory and WHEN you need to free it. Throw exceptions, early returns, complex ownership semantics, or circular references into the mix, and that gap becomes a minefield. Raw pointers in C++ carry no metadata about who owns them, who should free them, or whether they're still valid. The language gives you a chainsaw — powerful, but it doesn't stop you from cutting your own hand off.

By the end of this article, you'll understand exactly how the heap allocator works under the hood, why leaks happen even in 'careful' code, how to use Valgrind and AddressSanitizer to pinpoint leaks down to the exact line, and how to architect your code with RAII and smart pointers so that leaks become structurally impossible. You'll also leave with the exact vocabulary and depth to ace memory management questions in senior C++ interviews.

What Is a Memory Leak and Why Does It Happen?

A memory leak occurs when a program allocates memory from the heap (using new, malloc, or calloc) and never deallocates it. The leaked memory remains allocated until the process exits. The operating system reclaims it on process termination, but during the process lifetime, the leak gradually reduces available heap space.

Leaks happen because C++ does not have automatic garbage collection. The programmer must explicitly pair every allocation with a deallocation. Real-world causes include:

• Exception thrown before delete is reached.
• Early return paths that skip cleanup.
• Overwriting the only pointer to allocated memory (pointer reassignment without delete).
• Circular references involving shared_ptr.
• Missing virtual destructors, causing derived resource not to be released.

// TheCodeForge — C++ memory leak example
#include <iostream>

class Resource {
public:
    Resource() { std::cout << "Resource acquired\n"; }
    ~Resource() { std::cout << "Resource released\n"; }
};

void leak_function() {
    Resource* r = new Resource();  // allocated
    // some condition that causes early return
    if (rand() % 2 == 0) {
        // missing delete r; -> memory leak
        return;
    }
    delete r;
    return;
}

int main() {
    for (int i = 0; i < 10; ++i) {
        leak_function();
    }
    return 0;
}

Heap Allocator Internals: How Leaks Steal Memory

The heap allocator (glibc's malloc, tcmalloc, jemalloc) manages a pool of memory blocks. When you call new, it finds a free block via the free list, marks it as used, and returns the address. When you call delete, it returns the block to the free list. Coalescing merges adjacent free blocks into larger ones.

A leak does not just lose memory — it also fragments the heap. If many small blocks are leaked in the middle of the heap, the free list contains many small holes. A request for a larger contiguous block may fail even though total free memory is sufficient. This is called external fragmentation.

Production allocators also maintain thread caches to reduce lock contention. Leaked memory in thread caches is even harder to track because it may appear as "in use" but not actually reachable by any pointer. Tools like Valgrind intercept every malloc/free call to track reachable pointers.

// TheCodeForge — heap fragmentation simulation
#include <iostream>
#include <vector>

int main() {
    // allocate large blocks, free every other one -> fragmentation
    std::vector<int*> blocks;
    for (int i = 0; i < 100; ++i) {
        blocks.push_back(new int[1024]);  // 4KB each
    }
    // free even indices
    for (size_t i = 0; i < blocks.size(); i += 2) {
        delete[] blocks[i];
    }
    // now heap has 50 holes of 4KB each, interspersed with used blocks
    // a new request for a 200KB contiguous block may fail!
    int* big = new int[50*1024];  // 200KB
    if (!big) std::cout << "Allocation failed due to fragmentation\n";
    else std::cout << "Allocation succeeded (if not fragmented)\n";
    delete[] big;
    for (size_t i = 1; i < blocks.size(); i += 2) {
        delete[] blocks[i];
    }
    return 0;
}

RAII and Smart Pointers: Making Leaks Impossible

RAII (Resource Acquisition Is Initialization) ties resource lifetime to object lifetime. When an object goes out of scope, its destructor automatically frees the resource. This makes leaks structurally impossible if the resource is owned by an RAII wrapper.

Rule: Never use raw new/delete outside of a RAII wrapper or low-level allocator. The only exceptions are when writing custom containers or interfacing with C libraries.

// TheCodeForge — RAII with unique_ptr
#include <memory>
#include <iostream>

struct Widget {
    ~Widget() { std::cout << "Widget destroyed\n"; }
    void doWork() const { std::cout << "Work\n"; }
};

void process() {
    auto w = std::make_unique<Widget>();  // RAII
    w->doWork();
    // no delete needed! destructor called automatically
}

int main() {
    process();  // Output: "Work" then "Widget destroyed"
    // No leak even if exception thrown inside process()
    return 0;
}

Using Valgrind and AddressSanitizer to Find Leaks

Two dominant tools for finding memory leaks:

Valgrind (memcheck): Runs the program under a synthetic CPU. Intercepts all malloc/free/new/delete calls. Tracks reachability by scanning memory for pointer values. Reports: - definitely lost: pointer to block overwritten, no way to free. - indirectly lost: block is only referenced by other lost blocks. - possibly lost: pointer to interior of block exists, but start address might be lost. - still reachable: pointer still exists but block not freed before exit (technically not a leak, but often suggests design issue).

AddressSanitizer (ASan): Compile-time instrumentation. For every allocation, it records a shadow byte that tracks access permissions. At runtime, it detects heap-use-after-free, buffer overflow, and memory leaks (with detect_leaks=1). Much faster than Valgrind (2-4x slowdown vs 10-50x).

Both tools should be used during development and in stress testing. They are too slow for production. Use core dumps and heap profiling in production.

# Compile with debug symbols (ASan)
g++ -g -O0 -fsanitize=address -fno-omit-frame-pointer leak_example.cpp -o leak_asan

# Run with ASan leak detection
ASAN_OPTIONS=detect_leaks=1:abort_on_error=1 ./leak_asan

# Compile for Valgrind (no sanitizer)
g++ -g -O0 leak_example.cpp -o leak_valgrind

# Run under Valgrind
valgrind --tool=memcheck --leak-check=full --show-leak-kinds=all ./leak_valgrind

# Example output from ASan:
# =================================================================
# ==12345==ERROR: LeakSanitizer: detected memory leaks
# Direct leak of 40 byte(s) in 5 object(s) allocated from:
#     #0 0x7f8c1c2b1b40 in operator new(unsigned long)
#     #1 0x400a1f in leak_function() /tmp/leak_example.cpp:14
#     #2 0x400a76 in main /tmp/leak_example.cpp:22
# SUMMARY: AddressSanitizer: 40 byte(s) leaked in 5 allocation(s).

Production Debugging Without Tools: Core Dumps and Heap Analysis

When a process is OOM-killed, you lose the process. But if you enable core dumps (ulimit -c unlimited), the OS saves the entire memory image to a file. You can analyze it post-mortem: - Use gdb to inspect pointers and see what blocks are reachable. - Use pstack to get thread stacks. - Use malloc_info(0, stderr) to dump glibc's internal allocation statistics.

Heap profiling tools like gperftools (Google Performance Tools) or jemalloc's built-in profiler can be enabled at runtime with minimal overhead (~5%). They generate heap snapshots that you can diff over time to find growing allocations.

In production, never run Valgrind or ASan. Instead, enable lightweight heap profiling continuously. Set a threshold: if RSS grows more than 10% in an hour, alert the pager with a heap snapshot attached.

# Enable core dumps
echo '/tmp/core.%p' | sudo tee /proc/sys/kernel/core_pattern
ulimit -c unlimited

# Run with gperftools heap profiler
env HEAPPROFILE=/tmp/myapp.hprof HEAP_PROFILE_ALLOCATION_INTERVAL=2097152 ./myapp

# Signal to dump current heap profile
kill -USR2 $(pgrep myapp)

# Analyze diff between two snapshots
pprof --text --base=/tmp/myapp.hprof.0001.heap /tmp/myapp.hprof.0002.heap

# Example pprof output:
# Total: 256.0 MB
#  85.0 MB (33.2%): 0x7f8c1c2b1b40 /usr/lib/libstdc++.so.6.0.30
#  40.0 MB (15.6%): my_func /home/user/myapp.cpp:150

Common Leak Patterns and How to Fix Them

1. Missing virtual destructor: Base class pointer to derived object. If base destructor is not virtual, derived destructor never runs, leaking derived members.
2. Circular shared_ptr references: A->B and B->A both hold shared_ptr. Neither reference count reaches zero. Fix: use weak_ptr in one direction.
3. Exception in constructor: If constructor throws after new but before assigning to a smart pointer, the raw allocation is leaked. Fix: use RAII wrappers for all allocations in constructor initializer lists.
4. Unhandled allocation failure: new may throw std::bad_alloc. If not caught, the code after it may never execute, potentially leaking prior allocations. Fix: always handle exceptions or use nothrow new.
5. Forgetting to delete in setter/reassignment: ptr = new X; overwrites old pointer without delete. Fix: always delete before reassigning, or use smart pointers.
6. Thread-local storage leaks: If a thread exits without cleaning up its TLS blocks, those blocks remain allocated until process death. Fix: register cleanup functions with pthread_key_create destructor.

// TheCodeForge — missing virtual destructor leak
#include <iostream>

class Base {
public:
    ~Base() { std::cout << "Base destructor\n"; }  // not virtual!
};

class Derived : public Base {
    int* data;
public:
    Derived() : data(new int[100]) {}
    ~Derived() { delete[] data; std::cout << "Derived destructor\n"; }
};

int main() {
    Base* b = new Derived();
    delete b;  // calls ~Base() only, not ~Derived()! -> leak of data array
    return 0;
}

Static Analysis and Coding Standards: Prevent Leaks at Compile Time

The best tool for memory leaks is prevention. C++ has evolved to make leaks harder to write: - -Wall -Wextra -Werror flags catch some cases. - clang-tidy with cppcoreguidelines-no-malloc, modernize-use-auto, modernize-use-equals-default. - cppcheck for static analysis: detects missing delete, mismatched allocation/deallocation, leaky containers. - -fsanitize=address as part of CI pipeline.

// TheCodeForge — clang-tidy will flag this
#include <memory>

class MyClass {
public:
    MyClass() {
        ptr = new int[100];  // clang-tidy: warning: use make_unique
    }
    ~MyClass() {
        delete[] ptr;
    }
private:
    int* ptr;
};

// Better:
class MyClassFixed {
public:
    MyClassFixed() : ptr(std::make_unique<int[]>(100)) {}
private:
    std::unique_ptr<int[]> ptr;
};