Diagnosing and Fixing Memory Leaks in C++ with RAII and Smart Pointers

Recognizable Condition

The resident set size (RSS) of a C++ process climbs steadily during repeated execution of a workload and does not return to its baseline after the workload finishes. The growth is monotonic and correlates with the number of iterations, not with transient spikes.

Cause and Diagnostic Indicators

Observation	Likely Cause
High RSS + steady heap growth over time	Unreleased allocations (missing delete or circular std::shared_ptr references)
High RSS + erratic, saw‑tooth pattern	Heap fragmentation rather than a leak

Ordered Diagnostic Checks

1. Audit raw owning pointers – Search the source for every new (or malloc) and verify that a matching delete (or free) exists on all control‑flow paths, including those that exit via exceptions or early returns. If any allocation lacks a guaranteed release, mark it as a candidate leak.
2. Inspect std::shared_ptr usage – Look for objects that hold std::shared_ptr members pointing back to each other (e.g., a parent holding a shared_ptr to a child and the child holding a shared_ptr to the parent). Such cycles prevent the reference count from reaching zero.
3. Run a leak detector – Compile with AddressSanitizer (-fsanitize=address -g) and execute the program under a workload that triggers the suspected path. The tool will report allocation stacks for blocks not freed at exit.
4. Monitor memory trend – While repeatedly exercising the workload, observe RSS with top, htop, or Task Manager. A continual upward slope after each iteration confirms a leak; a stable RSS with occasional drops points to fragmentation.

Fixes Matched to Findings

Replace raw owning pointers with std::unique_ptr

When an object has a single owner, replace the raw pointer with std::unique_ptr. The destructor automatically releases the memory when the owning scope ends, even if an exception is thrown.

// Before: raw owning pointer
class Node {
    int* data;
public:
    Node() : data(new int(42)) {}
    ~Node() { delete data; } // easy to forget or miss on error paths
};

// After: unique_ptr
#include 
class Node {
    std::unique_ptr data;
public:
    Node() : data(std::make_unique(42)) {}
    // No destructor needed; unique_ptr cleans up automatically
};

Break std::shared_ptr cycles with std::weak_ptr

In parent‑child or observer relationships, make the back‑reference a std::weak_ptr. This does not increment the reference count, allowing the cycle to be destroyed when the owning shared_ptr goes out of scope.

#include 
struct Child;

struct Parent {
    std::shared_ptr child; // owns the child
    ~Parent() = default;
};

struct Child {
    std::weak_ptr parent; // non‑owning back reference
    ~Child() = default;
};

// Usage
auto p = std::make_shared();
auto c = std::make_shared();
p->child = c;
c->parent = p; // weak_ptr, does not create a cycle
// When p and c go out of scope, both are destroyed

Escalation Criteria

If the checks above do not reveal the source of monotonic memory growth, proceed to:

• Heap profilers such as Valgrind memcheck or massif to identify allocation sites that accumulate over time.
• Allocator‑level tracing (e.g., LTrace or custom new/delete hooks) to verify whether the growth originates from third‑party libraries.
• Review of static‑or‑thread‑local objects that may accumulate state across iterations.

Only after confirming that the leak persists despite correct RAII usage should you invest in deeper profiling; otherwise, the fixes outlined above typically resolve the issue.