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

Limitations: - Only works in debug builds (can be enabled in release with _DEBUG defined, but with performance impact). - Does not track all memory (e.g., allocations by third-party libraries using different runtimes). - Reports are not as detailed as Valgrind's stack traces (only allocation number, size, and file/line if source info is available).

Setup steps: 1. Add #define _CRTDBG_MAP_ALLOC before including <crtdbg.h> to map new to new() with file/line info. 2. Include <crtdbg.h> and call _CrtSetDbgFlag early in main(). 3. Optionally call _CrtDumpMemoryLeaks() before exit. 4. For per-thread tracking, use _CrtMemCheckpoint in each thread's main function.

// TheCodeForge — Windows CRT Debug Heap example
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
#include <iostream>

int main() {
    // Enable leak detection on program exit
    _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF);

    // Break on allocation #123 (replace with actual number from report)
    // _CrtSetBreakAlloc(123);

    int* leak = new int[100];  // intentional leak

    // Dump all leaks at this point (optional, already done on exit)
    // _CrtDumpMemoryLeaks();

    return 0;
}

// Output:
// Detected memory leaks!
// Dumping objects ->
// {123} normal block at 0x00AABBCC, 400 bytes long.
//  Data: <                > CD CD CD CD ...
// Object dump complete.

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;
}

Common Leak Patterns — Quick Checklist

Use this checklist to quickly identify and fix the most frequent memory leak patterns in C++ code.

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;
};

Manual Leak Hunting: What the Tools Don't Tell You

Valgrind and ASan are your first line of defense, but they're not magic. When you're dealing with a 500k-line codebase that links against third-party shared objects you can't rebuild, static analysis and runtime tools will miss things. You need to know how to read a core dump's heap fragments and trace allocation chains by hand.

The first rule: never allocate memory at module load time. Static initialization order fiasco will hide leaks that only manifest during shutdown. Always allocate when first needed, not when the DLL loads. Second rule: tag your allocations. Use the new operator with a filename and line number macro. In production builds, I wrap every new call in a macro that stores the allocation site in a thread-local ring buffer. When the process OOMs, I dump that buffer to find the offender.

Third rule: audit your destructors. Virtual destructors in base classes aren't optional if you're deleting through a base pointer. Miss one, and you leak an entire derived object's memory silently. I've seen this crash production services after three days of uptime.

Heap Snapshots: Finding Leaks Without Tearing Down the Process

Sometimes you can't restart the application. Maybe it's a payment processing gateway with an SLA of 99.999%. Or a medical device firmware that boots for months. You need to diagnose memory bloat while the process keeps running. That's where heap snapshots come in.

On Linux, you can dump the heap mappings directly from /proc/<pid>/maps and examine all [heap] regions with gdb --pid <pid>. In gdb, use info malloc-stats if you're running with glibc's mtrace. For a raw approach, attach with gdb, run call malloc_stats() to print summary stats to stderr, then inspect specific allocation sizes that grow over time.

On Windows, you can call _CrtMemCheckpoint() at intervals in a background thread and compare state dumps. The CRT debug heap stores a linked list of all live allocations — you can walk it with _CrtMemDumpAllObjectsSince() on a timer. Pair this with a metric like 'total heap bytes' exported to Prometheus and you'll catch the drift before it kills the node.

Custom Allocator Hooks: When You Need Surgical Precision

Valgrind instruments every load and store — that's 5-20x slowdown. Unacceptable for latency-sensitive code. The solution is a lightweight custom allocator with built-in leak detection. I've shipped this pattern in trading systems where every microsecond counts.

The idea is simple: override operator new and operator delete at the translation unit level (don't touch global new unless you own every allocation). Your custom allocator maintains a concurrent hash map keyed by the allocation address. On allocation, store the call stack (use backtrace() on Linux, CaptureStackBackTrace() on Windows) and the allocation size. On deallocation, remove the entry. Once per minute, dump any entries older than N seconds — those are leaks.

The performance cost is one hash map insert per allocation (~50ns with a good hash), zero cost on deallocation (just a lookup and erase). That's 100x faster than AddressSanitizer. The tradeoff: you only catch allocations through your custom allocator, so malloc or mmap calls slip through. But for internal subsystems, this is production-grade leak detection that doesn't kill performance.

False Positives: The Tools Are Wrong, Now What?

Valgrind and AddressSanitizer are not omniscient. They report allocations that are reachable but never freed as leaks. That's correct for the heap, but it doesn't mean your code is broken. The most common false positive: a global singleton that lives for the entire process lifetime. The memory is freed by the OS on exit — there's zero practical leak. Yet the tool screams at you.

Why does this matter? Because rookie devs waste hours chasing ghosts. They add destructors to globals, introduce static order-of-initialization bugs, and generally make a mess. The senior move: classify each leak report. Green: actual leak (allocation grows over time). Yellow: reachable-on-exit (benign). Red: tool artifact (e.g., STL internal caches).

Suppress false positives explicitly. Valgrind has --suppressions, ASan has __attribute__((no_sanitize("address"))). Document every suppression with a reason. That turns a noisy report into a signal you can trust in CI.

// io.thecodeforge — c-cpp tutorial

#include <iostream>
#include <vector>

// Global cache: allocated once, never freed — but not a leak.
static std::vector<int>* global_cache = new std::vector<int>();

int main() {
    global_cache->push_back(42);
    std::cout << "Cache size: " << global_cache->size() << "\n";
    // Valgrind will flag this as "still reachable" — suppress it.
    // Use: --suppressions=suppress_global.supp
    // Inside suppressions file:
    // {
    //    <insert_a_suppression_name_here>
    //    Memcheck:Leak
    //    match-leak-kinds: reachable
    //    fun:_zn6global_cache...

    return 0;
}

Heap Snapshots: Find Leaks Without Killing Your Process

You can't restart production every time you suspect a leak. Heap snapshots let you compare the heap state at two points in time — without restarting. The core idea: take a baseline snapshot, run a suspect code path, take another snapshot, diff them. Any allocation that exists in the second snapshot but not the first is either a leak or a long-lived object.

On Linux, malloc_hook or LD_PRELOAD libraries can capture heap state. But the production-friendly method: use mallinfo() or mallinfo2() to track arena size deltas over time. If arena size grows monotonically while RSS stays flat, you have internal fragmentation — not a leak.

For surgical work, Google's GWP-ASan or heapprofd (Android) give you real-time allocation stacks. They sample high-frequency allocations and dump stack traces on every malloc. The trick: run them at 1% sample rate in production. The performance hit is ~2%. You get leak candidates without crashes. That's senior-engineer territory.

// io.thecodeforge — c-cpp tutorial

#include <malloc.h>
#include <iostream>

void print_heap_stats(const char* label) {
    struct mallinfo mi = mallinfo();
    std::cout << label
              << " — arena: " << mi.arena
              << " bytes, allocated: " << mi.uordblks
              << " bytes\n";
}

void suspect_function() {
    for (int i = 0; i < 1000; ++i) {
        // Leak: allocate and never free
        int* p = new int(42);
    }
}

int main() {
    print_heap_stats("Before");
    suspect_function();
    print_heap_stats("After");
    // Delta shows ~4000 bytes (1000 * sizeof(int))
    return 0;
}