DEV Community: Wang - C++ Developer

Crash Patterns Overview: A Practical, Symptom‑First Guide to Debugging C++ Crashes

Wang - C++ Developer — Thu, 14 May 2026 14:57:56 +0000

Debugging C++ crashes is not guesswork. It’s pattern recognition.

After decades of debugging production systems, one truth becomes obvious: crashes follow repeatable patterns — not because the bugs are simple, but because the ways C++ programs fail are consistent.

This article introduces a practical, two‑layer model for understanding crashes:

Symptom Buckets — what you can observe immediately
Crash Patterns — what those symptoms usually mean

This model is the foundation of the entire crash‑analysis series.

Why a Symptom‑First Model
The Five Symptom Buckets (S1–S5)
The Ten Crash Patterns
The Debugging Workflow
What This Model Enables for Teams
What’s Next in the Series

⭐ Why a Symptom‑First Model

When a C++ program crashes, you never begin with the root cause.

You begin with the raw signals the system gives you at the moment of failure.

These signals are limited, messy, and often incomplete — but they are consistent enough that, over decades of debugging, engineers have learned to group them into five repeatable categories, which we call Symptom Buckets.

These buckets come directly from the only things you can reliably observe when a crash happens:

Where the crash occurred? your code, allocator, thread library, kernel
What the call stack looks like? clean, corrupted, missing frames, nonsense addresses
What the allocator reports? invalid free, corrupted chunk, double free
What the threads are doing? running, blocked, deadlocked, spinning
What sanitizers report? (only when running with sanitizers enabled — ASan/TSAN/UBSan/Valgrind)

These are the first clues — and at the moment of a crash, they’re all you have. Everything else (patterns, root causes, fixes) comes later.

A symptom‑first model mirrors how real debugging works in production:

Observe the symptom
Classify it into a Symptom Bucket
Infer the likely crash patterns
Choose the right tools
Identify the Root Cause
Fix the underlying code

This is the workflow used by senior engineers in real systems.

⭐ Layer 1 — Symptom Buckets (Start Here)

Based on the symptoms you observe at the moment of a crash, you can classify the failure into one of five buckets.

Each bucket represents a distinct observable behavior — the first clue in the debugging workflow.

S1 — Clean Backtrace Crashes

Symptoms

Backtrace is readable and complete
Frames make sense
Crash occurs inside your code
Program counter points to a valid instruction
No signs of stack corruption

Likely patterns

Null pointer dereference
Uninitialized memory
Simple boundary error

S2 — Crashes in malloc/free/new/delete

Symptoms

Backtrace ends inside allocator functions
Allocator reports “invalid pointer”, “double free”, “corrupted chunk”
Crash happens during allocation or deallocation

Likely patterns

Use‑after‑free
Double free
Heap corruption
Boundary error on heap buffer

S3 — Broken or Nonsensical Backtrace

Symptoms

gdb shows garbage frames
Return addresses look invalid
Stack unwinding fails
Backtrace jumps into unrelated modules
Stepping behaves unpredictably

Likely patterns

Stack corruption
Severe boundary error
ABI mismatch

S4 — Process Frozen (No Crash)

Symptoms

No core dump
CPU usage low or zero
Threads blocked
Program stops making progress
gdb shows threads waiting on locks

Likely patterns

Deadlock
Livelock
Waiting forever

S5 — Sanitizer Reports (ASan/TSAN/UBSan/Valgrind)

Symptoms

(Only when running with sanitizers enabled)

ASan: heap-use-after-free, stack-buffer-overflow
TSAN: data race
UBSan: undefined behavior
Valgrind: invalid read/write, uninitialized value

Likely patterns

Memory lifetime errors
Boundary errors
Concurrency errors
Initialization errors

⭐ Layer 2 — Crash Patterns (What the Symptoms Suggest)

These are the 10 recurring crash patterns seen in real C++ systems.
Each pattern describes a type of failure. Deep‑dive articles will follow later.

Memory Lifetime Errors

1. Null Pointer Dereference

Accessing memory through a pointer that is nullptr.
Often caused by missing initialization or failed allocation.

2. Use‑After‑Free (UAF)

Accessing memory after it has been freed.
The pointer still “looks valid,” but the memory no longer belongs to you.

3. Double Free / Invalid Free

Freeing the same memory twice, or freeing memory never allocated. This corrupts allocator metadata and often crashes inside free().

Memory Boundary Errors

4. Boundary / Off‑By‑One Error

Reading or writing just outside the valid range of a buffer.
Often subtle: wrong index, wrong size, or one extra iteration.

5. Stack Corruption

Writing past a stack buffer and overwriting the return address or saved registers.
This breaks stack unwinding and produces nonsensical backtraces.

6. Heap Corruption

Writing past a heap allocation and damaging allocator metadata.
Crashes usually appear later during malloc() or free().

Concurrency Errors

7. Data Race

Two threads access the same memory without proper synchronization.
Leads to unpredictable behavior and rare crashes.

8. Deadlock / Livelock

Threads block each other forever (deadlock) or keep running without progress (livelock).
The program freezes instead of crashing.

ABI / Layout Errors

9. ABI Mismatch

Different modules disagree on struct layout, calling conventions, or compiler settings.
Objects appear corrupted even though the code “looks correct.”

Initialization Errors

10. Uninitialized Memory

Using a variable or buffer before assigning a value.
Debug builds often hide it; release builds expose it.

⭐ The Debugging Workflow (The Core of This Series)

This is the model you will learn to apply:

Symptom → Pattern → Tools → Fix

Example:

Crash in free() → S2

Likely UAF or heap corruption → Pattern

Run ASan → Tools

Fix ownership or indexing → Fix

This workflow is repeatable, reliable, and works in real production systems.

┌──────────────────────────────────────────────────────────┐
│ 1. Observe the Symptom                                   │
│    (backtrace, allocator message, thread state, sanitizer)│
└──────────────────────────────────────────────────────────┘
                     ▼
┌──────────────────────────────────────────────────────────┐
│ 2. Classify into a Symptom Bucket (S1–S5)                │
│    Clean backtrace? Allocator crash? Broken stack? Freeze?│
│    Sanitizer report?                                      │
└──────────────────────────────────────────────────────────┘
                     ▼
┌──────────────────────────────────────────────────────────┐
│ 3. Map to Likely Crash Patterns (10 patterns)             │
│    UAF? Double free? Boundary error? Data race? ABI issue?│
└──────────────────────────────────────────────────────────┘
                     ▼
┌──────────────────────────────────────────────────────────┐
│ 4. Choose the Right Tools                                 │
│    gdb, ASan/TSAN, Valgrind, logging, core dumps, traces  │
└──────────────────────────────────────────────────────────┘
                     ▼
┌──────────────────────────────────────────────────────────┐
│ 5. Identify the Root Cause                                │
│    Ownership? Boundary? Concurrency? Layout? Init?        │
└──────────────────────────────────────────────────────────┘
                     ▼
┌──────────────────────────────────────────────────────────┐
│ 6. Apply the Fix                                          │
│    Correct lifetime, fix indexing, add locks, fix ABI,    │
│    initialize variables, redesign unsafe code paths       │
└──────────────────────────────────────────────────────────┘

⭐ What This Model Enables for Teams

A shared debugging framework:

reduces time‑to‑root‑cause
avoids chasing noise
makes debugging teachable
creates shared vocabulary
prevents “hero debugging” culture
scales across large systems

This is not just a technique — This shared model turns debugging from an individual skill into a repeatable team capability.

⭐ What’s Next

Next article:

👉 S1 — Clean Backtrace Crashes

How to debug the “easy mode” crashes: null pointers, uninitialized memory, simple OOB.

Then:

👉 S2, S3, S4, S5

👉 Pattern deep‑dives

👉 Advanced debugging topics

Each article will include real crash examples, tools, and step‑by‑step workflows you can apply immediately.

https://lnkd.in/ekhzzfum

Finding Memory Leaks in Legacy C++ Applications with Valgrind

Wang - C++ Developer — Wed, 06 May 2026 18:43:51 +0000

Legacy C++ services don't crash — they slowly bleed memory until someone restarts them at 3 AM.

If you've inherited a 20‑year‑old codebase with mysterious memory growth, this guide is for you.

You can't fix a leak if you can't reproduce.

This is your complete, production‑focused Valgrind investigation playbook.
It's based on real systems, real leaks, and real debugging pain.

The Workflow
Step 1 — Reproduce the Leak
Step 2 — Static Analysis
Step 3 — Compile for Valgrind
Step 4 — Run Valgrind
Step 5 — Understand Valgrind's Leak Types
Step 6 — Capture the Stack Trace
Step 7 — Optional Regression Test
Quick Reference
Real‑World Example
The Golden Rule

The Workflow

[Leak Trigger] → [Static Analysis] → [Compile Debug Build]
        ↓
   [Run Valgrind] → [Interpret Leak Types] → [Stack Trace]
        ↓
     [Regression Test]

Step 1 — Reproduce the Leak

You cannot find a leak if you cannot trigger it.

Measure memory growth

use the following script to track the total memory of your application used.

PID=$(pgrep your_service)
while true; do
  echo "$(date): $(pmap $PID | grep total | awk '{print $2}')"
  sleep 60
done

Interpretation:

Pattern	Meaning
Linear growth	Per‑operation leak
Step‑function growth	Specific trigger
No growth	Wrong hypothesis

Find the minimum trigger

Your goal: reproduce the leak in under 10 minutes.

Why?

Valgrind slows execution by 20–50×
A 10‑minute trigger becomes 3–8 hours
A 1‑hour trigger becomes 2–5 days

Why this matters: If your trigger is too slow, Valgrind becomes unusable.

Step 2 — Static Analysis (5 minutes, zero runtime cost)

Before running anything, let the compiler find the obvious issues.

Clang Static Analyzer

scan-build make

Look for "Memory leak" warnings (ignore "Potential leak").

clang‑tidy

clang-tidy legacy_file.cpp \
  --checks='-*,clang-analyzer-*,cppcoreguidelines-owning-memory'

Finds:

new without delete
malloc without free
Raw owning pointers

Misses:

Cycles
Third‑party leaks
Runtime‑dependent leaks

Why this matters: Static analysis gives you free wins before you even run the program.

Step 3 — Compile for Valgrind

Valgrind is useless without debug symbols. So first thing you should do is to compile the whole application with debug flag.

g++ -g3 -O0 -fno-omit-frame-pointer -o your_service your_service.cpp

Flag	Purpose
`-g3`	Full debug info
`-O0`	Clean stack frames
`-fno-omit-frame-pointer`	Reliable backtraces

Why this matters: Without debug symbols, Valgrind can't show you file/line numbers.

Step 4 — Run Valgrind

Run only the trigger you identified in Step 1.

valgrind --leak-check=full \
         --show-leak-kinds=definite,indirect \
         --track-origins=yes \
         --log-file=valgrind_out.txt \
         ./your_service --run-trigger

For long‑running services

Use vgdb to inspect leaks mid‑run:

valgrind --vgdb=yes --vgdb-error=0 --leak-check=full ./your_service

Then:

vgdb leak_check full definite indirect

Why this matters: You don't need to wait hours — you can inspect leaks while running.

Step 5 — Understand Valgrind's Leak Types

After the run, Valgrind will give you a report about memory lost in valgrind_out.txt. Example summary:

definitely lost: 1,024 bytes
indirectly lost: 6,144 bytes
possibly lost: 0 bytes
still reachable: 45,000 bytes

What each type means

Valgrind gives the following types of memory lost. Based on the types, you decides your action.

Type	Meaning	Action
definitely lost	Real leak	Fix first
indirectly lost	Child of a lost block	Fix parent
possibly lost	Pointer arithmetic / corruption	Investigate
still reachable	Globals/statics	Ignore unless growing

If "still reachable" grows

Use Massif:

valgrind --tool=massif ./your_trigger
ms_print massif.out

Why this matters: "Still reachable" is not a leak — unless it grows.

Step 6 — Capture the Stack Trace

A real leak looks like the following. With the stack trace and debug symbols, exact source file name and line number will be given. That is where memory is allocated. To fix it, you need to find out why the allocated memory was not released, e.g. delete is only called on one running path. With the trigger, another running path is active.

1,024 bytes in 1 blocks are definitely lost
at operator new
by DatabaseConnection::ExecuteQuery (db_connection.cpp:67)
by CustomerLoader::FetchCustomer (customer_loader.cpp:89)

Extract only leak blocks:

grep -A10 "definitely lost" valgrind_out.txt

Why this matters: The stack trace is the map that leads you to the leak.

Step 7 — Optional Regression Test

Useful when multiple developers touch the code.

TEST(LeakTest, ConfirmLeakExists) {
    size_t before = get_current_rss();
    for (int i = 0; i < 100; i++) {
        suspect_function();
    }
    size_t after = get_current_rss();
    EXPECT_LT((after - before) / 100, 1024);
}

Why this matters: Regression tests prevent old leaks from returning.

Quick Reference

Task	Command
Basic leak check	`valgrind --leak-check=full ./binary`
Only real leaks	`--show-leak-kinds=definite,indirect`
Save output	`--log-file=leak.log`
Check running service	`vgdb leak_check full definite indirect`
Heap profiling	`valgrind --tool=massif`
Extract leak	`grep -A10 "definitely lost"`

Real‑World Example

Imagine a legacy service that loads customers from a database and caches them.

The bug

// customer_loader.h
struct Customer {
    int id;
    std::string name;
};

class CustomerRepository {
public:
    Customer* LoadCustomer(int id);
};

// customer_loader.cpp
#include "customer_loader.h"
#include "db_connection.h"

Customer* CustomerRepository::LoadCustomer(int id)
{
    DatabaseConnection* conn = DatabaseConnection::Get(); // singleton
    ResultSet* rs = conn->ExecuteQuery("SELECT id, name FROM customers WHERE id = " + std::to_string(id));

    if (!rs->Next()) {
        return nullptr;
    }

    Customer* c = new Customer{};
    c->id = rs->GetInt(0);
    c->name = rs->GetString(1);

    // BUG: ResultSet is never deleted
    // delete rs;  // missing

    return c; // caller owns Customer*
}

Caller code:

void ProcessRequest(int customerId)
{
    CustomerRepository repo;
    Customer* c = repo.LoadCustomer(customerId);

    if (!c) {
        return;
    }

    // ... use c ...

    delete c; // correct
}

At first glance, this looks “fine” because Customer is deleted.

But ResultSet is leaked on every call.

Valgrind report

You run your request handler under Valgrind:

valgrind --leak-check=full \
         --show-leak-kinds=definite,indirect \
         --track-origins=yes \
         --log-file=valgrind_leak.log \
         ./service --handle-request 42

Relevant part of the report:

==12345== 128 bytes in 1 blocks are definitely lost in loss record 3 of 5
==12345==    at 0x4C2F1A3: operator new(unsigned long) (vg_replace_malloc.c:422)
==12345==    by 0x401F8B: ResultSet::ResultSet(DBHandle*) (result_set.cpp:27)
==12345==    by 0x4023D1: DatabaseConnection::ExecuteQuery(std::string const&) (db_connection.cpp:88)
==12345==    by 0x4039A4: CustomerRepository::LoadCustomer(int) (customer_loader.cpp:11)
==12345==    by 0x40412F: ProcessRequest(int) (request_handler.cpp:25)
==12345==    by 0x4043C9: main (main.cpp:17)

Key points:

“128 bytes in 1 blocks are definitely lost” → real leak
Allocation happens in ResultSet::ResultSet
The call chain leads to CustomerRepository::LoadCustomer

You don’t need to know ResultSet internals—only that you allocated it and never freed it.

The fix

Customer* CustomerRepository::LoadCustomer(int id)
{
    DatabaseConnection* conn = DatabaseConnection::Get();
    ResultSet* rs = conn->ExecuteQuery("SELECT id, name FROM customers WHERE id = " + std::to_string(id));

    if (!rs->Next()) {
        delete rs;          // ✅ free on early return
        return nullptr;
    }

    Customer* c = new Customer{};
    c->id = rs->GetInt(0);
    c->name = rs->GetString(1);

    delete rs;              // ✅ free after use

    return c;
}

Re‑run Valgrind:

==12345== HEAP SUMMARY:
==12345==     in use at exit: 0 bytes in 0 blocks
==12345==   total heap usage: 1,234 allocs, 1,234 frees, 98,765 bytes allocated
==12345== 
==12345== All heap blocks were freed -- no leaks are possible

The Golden Rule

Never start fixing until you can reproduce the leak in under 10 minutes.

The trigger is your truth.
The stack trace is your map.

Debugging Legacy C++ Crashes: Core Dumps, Symbols, addr2line, and GDB Explained

Wang - C++ Developer — Sun, 26 Apr 2026 16:30:27 +0000

You're on call. A production C++ service just crashed — no logs, no stack trace, just a dead process and maybe a core file.

This guide gives you a clear, repeatable workflow to diagnose any crash, even when you're missing debug symbols or working with a stripped legacy binary. Whether you have a core file, a symbol file, an unstripped build, or nothing at all, you will always know the next step.

Why This Matters

Debugging crashes in legacy C++ systems is notoriously difficult because:

Deployments often strip symbols
Core dumps are disabled in production
Build IDs don’t match
ASLR shifts memory layouts
Frame pointers are omitted
Systemd overrides ulimit settings

This workflow eliminates guesswork and gives you a deterministic path from crash to root cause.

Crash Debugging Decision Map

CRASH
  |
  v
HAVE CORE FILE?
  |-- No --> Enable cores (Path B) → Reproduce crash
  |
  |-- Yes (Path A)
        |
        v
   HAVE DEBUG SYMBOLS?
        |-- Yes --> Debug now (A4)
        |
        |-- No
              |
              v
        HAVE SYMBOL FILE?
              |-- Yes --> Load with -s (A6)
              |
              |-- No
                    |
                    v
        CAN REPRODUCE WITH SYMBOLS?
              |-- Yes --> Rebuild with -g (A7)
              |
              |-- No
                    |
                    v
        HAVE ORIGINAL BUILD?
              |-- Yes --> Map addresses (A8)
              |
              |-- No --> Fallback analysis (A9)

Path A — You Have a Core File

A1 — Locate the Core File

Common locations:

ls -la core*
ls -la /var/core/
find / -name "core*" -type f 2>/dev/null
cat /proc/sys/kernel/core_pattern

If you find a core file, continue to A2.

If not, jump to Path B.

A2 — Identify Which Binary Produced the Core

file core
gdb -c core -batch -ex "info files"

Confirm that the core file belongs to the binary you intend to debug (path, build, version).

A3 — Check Whether the Binary Has Debug Symbols

file ./myapp
nm ./myapp | head

If the binary is not stripped and you see symbol names → go to A4.
If it is stripped → go to A5.

A4 — Debugging With Symbols (Best Case)

gdb ./myapp core

Useful GDB commands:

bt full
info threads
thread apply all bt
frame 0
info locals
print var
list

At this point you usually have:

The crashing function and line
The call stack
Local variables and arguments

A5 — Binary Is Stripped: Find the Symbol File

In many production setups, the deployed binary is stripped, but symbol files are archived separately.

A5.1 — Extract Build ID

readelf -n ./myapp | grep "Build ID"

You’ll get something like:

Build ID: 1234567890abcdef...

A5.2 — Locate Matching Symbol File

Search your symbol store (example path):

find /symbols -type f -exec grep -l "1234567890abcdef" {} \;

If you find a matching symbol file → go to A6.
If not → go to A7.

A6 — Debug Using Separate Symbol Files

If your symbol file is myapp.dbg:

gdb -s myapp.dbg -e ./myapp -c core

Or recombine into a single unstripped binary:

eu-unstrip ./myapp myapp.dbg -o myapp.full
gdb ./myapp.full core

Now you can use the same commands as in A4.

A7 — No Symbol File: Reproduce With Debug Build

If you can rebuild and reproduce the crash:

g++ -g -O0 -fno-omit-frame-pointer -o myapp_debug ...

Run the debug build under the same conditions until it crashes and generates a new core file. Then debug that core with full symbols as in A4.

If you cannot reproduce the crash (e.g., one‑off production incident), continue with A8 or A9.

A8 — Map Raw Addresses Using an Unstripped Build

If you still have the original unstripped build (or can reconstruct it):

Extract the crash address from the core:

   gdb -c core -batch -ex "info registers" | grep rip

Get the memory map of the process:

   gdb -c core -batch -ex "info proc mappings"

Compute the offset:

   offset = crash_address - base_address_of_binary

Map the offset to source:

   addr2line -e /path/to/unstripped/myapp -f 0xOFFSET

This gives you the function and line number corresponding to the crash address.

A9 — No Symbols, No Reproduction: Fallback Forensics

Even with no symbols and no way to reproduce, you can still extract useful information.

Inspect Registers

gdb -c core -batch -ex "info registers"

Look for:

Null pointers (rax, rdi, etc. equal to 0x0)
Suspicious addresses in your binary’s range

Inspect Instructions Around the Crash

gdb -c core -batch -ex "x/20i $rip-40"

You might see something like:

mov    %rax,%rdi
test   %rdi,%rdi
je     <skip>
mov    (%rdi),%rdx   ← crash here

If rdi is 0x0, you can infer a null pointer dereference, even without symbols.

Path B — No Core File Generated

B1 — Check Core Dump Settings

ulimit -c
cat /proc/sys/kernel/core_pattern

If ulimit -c is 0, core dumps are disabled for your shell or service.

B2 — Enable Core Dumps

Temporary (current shell):

ulimit -c unlimited

Permanent (system‑wide):

echo "* soft core unlimited" | sudo tee -a /etc/security/limits.conf
echo "* hard core unlimited" | sudo tee -a /etc/security/limits.conf

You may need to log out and back in, or restart services.

B3 — Set Core File Location

Configure a directory for core files:

echo "/var/core/core.%e.%p.%t" | sudo tee /proc/sys/kernel/core_pattern

This pattern includes:

%e — executable name
%p — PID
%t — timestamp

B4 — Fix Permissions

sudo mkdir -p /var/core
sudo chmod 1777 /var/core

This ensures any process can write core files there.

B5 — Test Core Dump Generation

Create a small crash program:

int main() {
    int* p = nullptr;
    *p = 42;
}

Compile and run it:

g++ -g crash_test.cpp -o crash_test
./crash_test

Verify that a core file appears in /var/core (or your configured directory).

B6 — Rerun the Crashed Application

Now rerun the real application under the same conditions.

When it crashes, it should generate a core file.

Then return to Path A and continue from A2.

Common Pitfalls

Core dumps disabled in production (ulimit -c 0)
Stripped binaries deployed without archiving symbol files
Mismatched Build IDs between binary and symbol file
ASLR causing incorrect address mapping when computing offsets
Missing frame pointers (-fomit-frame-pointer) breaking backtraces
Systemd or other service managers overriding ulimit
Symbol files not stored or indexed by Build ID

Quick Reference Table

Task	Command
Enable cores	`ulimit -c unlimited`
Find cores	`find / -name "core*"`
Check symbols	`file ./myapp`
Get Build ID	`readelf -n ./myapp`
Debug with symbols	`gdb -s myapp.dbg -e myapp -c core`
Map address	`addr2line -e myapp -f 0xOFFSET`
Check core pattern	`cat /proc/sys/kernel/core_pattern`

Pro Tips

Always compile with -g, then strip separately for release.
Store symbol files indexed by Build ID in a central, backed‑up location.
Use -fno-omit-frame-pointer for more reliable backtraces.
Test core dump generation in a staging environment that mirrors production.
Automate core collection and symbol archiving as part of your deployment pipeline.

Conclusion

This workflow covers every crash scenario — from “no core file” to “no symbols” to “full debug context.”

Bookmark it, share it with your team, and use it as your standard operating procedure for production crash analysis.

LinkedIn discussion

Beyond New and Delete: Engineering Approach with gsl::owner, std::span and clang-tidy

Wang - C++ Developer — Sun, 26 Apr 2026 15:27:41 +0000

In my previous articles, Beyond new and delete: A Practical Guide to Refactoring Raw Pointers to Smart Pointers and Beyond new and delete: to Weak Pointer, I explained how to refactor raw pointers into unique_ptr, shared_ptr, weak_ptr, and references.

But swapping pointer types is only half the battle. A successful refactoring also requires a systematic engineering process — one that combines ownership analysis, modern C++ types, static analysis, and incremental testing to ensure safety and correctness.

In this article, we focus on that engineering workflow:
Audit & Annotate → Static Analysis → Replace → Refactor Incrementally

Step	Action
1	Audit & Annotate – Mark owning vs observer pointers, use GSL
2	Static Analysis – Enable `-Wall`, run clang-tidy, add sanitizers
3	Replace with Modern Types – `unique_ptr`, `shared_ptr`, `span`, references
4	Refactor Incrementally – Start with leaf modules, remove manual `delete`

Step 1. Audit and Annotate Ownership

Goal: Make ownership explicit before changing any code.

Use comments or annotations to mark which pointers own memory and which do not.

Consider using the Guidelines Support Library (GSL) – available via vcpkg, Conan, or as a header‑only library (#include <gsl/gsl>):

gsl::owner<T*> for owning pointers.
T* or gsl::not_null<T*> for non-owning pointers.

Example:

#include <gsl/gsl>

void process(gsl::not_null<MyClass*> ptr) {
    // ptr is guaranteed non-null - no need to check!
    ptr->doSomething();
}

void legacy_owner(gsl::owner<MyClass*> owned) {
    // This raw pointer OWNS the memory
    delete owned;
}

Step 2. Use Static Analysis and Compiler Options

Enable compiler warnings for unsafe pointer usage:

GCC/Clang: -Wall -Wextra -Werror
MSVC: /W4

or Use static analysis tools to catch raw pointer misuse:

clang-tidy
Cppcheck

# Run clang-tidy with Core Guidelines checks
clang-tidy --checks='cppcoreguidelines-owning-memory,modernize-*' file.cpp

Other useful tools: LeakSanitizer, Valgrind, Dr. Memory.

Typical warnings are listed below.

Warning 1: Missing 'gsl::owner' on allocated pointer

int* data = new int[100];  // warning here
delete[] data;

warning: initializing non-owner 'int *' with a newly created 'gsl::owner<>' [cppcoreguidelines-owning-memory]

Fix: gsl::owner<int*> data = new int[100]; or use std::unique_ptr.

Warning 2: Deleting a non-owner pointer

int* ptr = new int(42);  // missing owner annotation
delete ptr;              // warning here

warning: deleting a pointer through a type that is not marked 'gsl::owner<>' [cppcoreguidelines-owning-memory]

Fix: Mark with gsl::owner or use smart pointer.

Warning 3: Returning raw pointer from factory (ownership unclear)

int* make_int() {        // warning: returning raw pointer
    return new int(42);
}

warning: function returns a raw pointer that may be an owner [cppcoreguidelines-owning-memory]

Fix: std::unique_ptr<int> make_int() or mark as gsl::owner<int*>.

Warning 4: Assignment loses ownership

gsl::owner<int*> create() { return new int(42); }

void test() {
    int* p = create();   // warning: owner assigned to non-owner
    delete p;
}

warning: initializing non-owner 'int *' with a newly created 'gsl::owner<>' [cppcoreguidelines-owning-memory]

Fix: gsl::owner<int*> p = create(); or use auto p = create();.

Warning 5: Using std::unique_ptr with raw delete

auto p = std::make_unique<int>(42);
delete p.get();          // warning: manual delete on smart pointer

warning: 'delete' applied to pointer that is owned by a smart pointer [cppcoreguidelines-owning-memory]

Fix: Remove manual delete – the smart pointer handles it.

Step 3. Replace with Modern Types

Ownership/Usage	Modern C++ Type	Notes
Sole ownership	`std::unique_ptr<T>`	Use `std::make_unique<T>()`
Shared ownership	`std::shared_ptr<T>`	Use `std::make_shared<T>()`
Non-owning, never null	`T&` or `gsl::not_null<T*>`	Prefer references when possible
Non-owning, may be null	`T*` (with optional GSL annotation)	Raw pointer is fine as an observer
Array/view, non-owning	`std::span<T>`	C++20 (or GSL span for older standards)

Example:

void process(std::span<int> data); // Non-owning view over array/vector

💡 For dynamic arrays, consider std::vector<T> over std::unique_ptr<T[]> unless you need a specific allocator or C API compatibility.

Step 4. Refactor Incrementally

Start with leaf modules (fewest dependencies).

Replace gsl::owner<T*> with std::unique_ptr<T> or std::shared_ptr<T> as appropriate.
Use std::span<T> for functions that take raw array pointers and sizes.
Update function signatures and member variables.
Remove manual delete calls.

An Example: Step‑by‑Step Refactoring

Before:

void foo(int* arr, size_t n);               // arr is not owned
void bar(gsl::owner<MyClass*> obj);         // obj is owned

void caller() {
    int* data = new int[10];
    foo(data, 10);
    delete[] data;

    MyClass* mc = new MyClass();
    bar(mc);
    delete mc;
}

After:

#include <memory>
#include <span>

void foo(std::span<int> arr);                // Non-owning view
void bar(std::unique_ptr<MyClass> obj);      // Ownership transferred

void caller() {
    auto data = std::make_unique<int[]>(10);
    foo(std::span<int>(data.get(), 10));
    // No delete needed

    auto mc = std::make_unique<MyClass>();
    bar(std::move(mc));
    // No delete needed
}

When NOT to Refactor

Refactoring raw pointers isn't always the right move. Consider postponing or skipping when:

Performance‑critical hot paths – the (small) overhead of smart pointers might matter (measure first).
Codebases frozen for certification – aviation, medical, or safety‑critical systems.
Interfacing with C libraries – raw pointers are often unavoidable there.
The code is about to be deprecated – don't invest time in dead code.

Reference: clang-tidy Commands for Raw Pointer Refactoring

Check Commands (Analyze Only)

Command	Purpose
`clang-tidy --checks='cppcoreguidelines-owning-memory' file.cpp`	Detect missing `gsl::owner` annotations and improper deletions
`clang-tidy --checks='modernize-make-unique' file.cpp`	Find raw `new` that can be replaced with `std::make_unique`
`clang-tidy --checks='modernize-make-shared' file.cpp`	Find raw `new` that can be replaced with `std::make_shared`
`clang-tidy --checks='modernize-use-auto' file.cpp`	Find verbose type names that can be replaced with `auto`
`clang-tidy --checks='modernize-use-nullptr' file.cpp`	Find `NULL` or `0` that can be replaced with `nullptr`
`clang-tidy --checks='cppcoreguidelines-owning-memory,modernize-*' file.cpp`	Run all relevant checks together

Fix Commands (Apply Changes)

Command	Purpose
`clang-tidy --fix --checks='modernize-make-unique' file.cpp`	Automatically replace `new` with `std::make_unique`
`clang-tidy --fix --checks='modernize-make-shared' file.cpp`	Automatically replace `new` with `std::make_shared`
`clang-tidy --fix --checks='modernize-use-auto' file.cpp`	Automatically replace verbose types with `auto`
`clang-tidy --fix --checks='modernize-use-nullptr' file.cpp`	Automatically replace `NULL` with `nullptr`
`clang-tidy --fix --checks='cppcoreguidelines-owning-memory' file.cpp`	Add `gsl::owner` annotations (manual review still recommended)

Recommended Workflow with clang-tidy

# Step 1: Run checks to see what needs fixing
clang-tidy --checks='cppcoreguidelines-owning-memory,modernize-*' file.cpp

# Step 2: Apply automatic fixes safely
clang-tidy --fix --checks='modernize-make-unique,modernize-make-shared,modernize-use-auto,modernize-use-nullptr' file.cpp

# Step 3: Re-run checks to verify fixes
clang-tidy --checks='cppcoreguidelines-owning-memory' file.cpp

Conclusion

A professional refactoring from raw pointers to modern C++ involves:

Explicitly annotating ownership (with GSL or comments)
Using compiler warnings and static analysis
Replacing with the right smart pointer or view type (unique_ptr, shared_ptr, std::span, references)
Testing and reviewing at every step

This approach produces safer, more maintainable, and truly modern C++ code – without the sleepless nights hunting for memory leaks.

Beyond new and delete: to Weak Pointer

Wang - C++ Developer — Mon, 20 Apr 2026 09:15:11 +0000

In the previous article, we left one case untouched: the transition from raw pointers to weak_ptr. That's exactly what we'll dive into today.

Use shared_ptr when multiple parts of your system need to keep an object alive, and you can't predict which part will outlive the others. But shared_ptr has a fatal flaw: cyclic references.

When two shared_ptrs point to each other, neither can die. They hold each other hostage forever. The result? A memory leak that never gets cleaned up.

Let me break it down step by step.

The Core Problem: What happens when objects point to each other?

Normal case (no cycle)

class Person {
    std::shared_ptr<Person> mother;  // Owning reference
};

auto alice = std::make_shared<Person>();
auto bob = std::make_shared<Person>();

// alice's reference count = 1
// bob's reference count = 1
// When they go out of scope, both are destroyed ✅

The cyclic problem

class Person {
    std::shared_ptr<Person> mother;
    std::shared_ptr<Person> father;
};

auto alice = std::make_shared<Person>();  // alice ref count = 1
auto bob = std::make_shared<Person>();    // bob ref count = 1

alice->father = bob;   // bob's ref count becomes 2
bob->mother = alice;   // alice's ref count becomes 2

Now what happens when alice and bob go out of scope?

alice (the variable) is destroyed → alice's ref count drops from 2 → 1
bob (the variable) is destroyed → bob's ref count drops from 2 → 1
Both objects still have ref count = 1! They point to each other, so neither can be destroyed.
MEMORY LEAK 💥

The Solution: `weak_ptr`

weak_ptr is like a "peek" at the object — it doesn't increase the reference count.

class Person {
    std::shared_ptr<Person> mother;  // Owning (increases count)
    std::weak_ptr<Person> father;    // Observing (doesn't increase count)
};

auto alice = std::make_shared<Person>();  // alice count = 1
auto bob = std::make_shared<Person>();    // bob count = 1

alice->father = bob;   // bob's count stays 1 (weak_ptr doesn't affect it)
bob->mother = alice;   // alice's count becomes 2

// When variables go out of scope:
// bob count: 1 → 0 (destroyed)
// alice count: 2 → 1 → 0 (destroyed when bob's weak_ptr expires)
// NO LEAK! ✅

Using `weak_ptr`: The `.lock()` method

You can't use a weak_ptr directly — you must first "lock" it to get a temporary shared_ptr. .lock() atomically checks existence and acquires a shared_ptr in one thread-safe operation — there is no other safe way to access a weak_ptr's target.

// BAD: Can't use weak_ptr directly
father->doSomething();  // Compiler error!

// GOOD: Lock it first
if (auto temp = father.lock()) {  // Try to get shared_ptr
    temp->doSomething();           // Use it safely
} else {
    // The object has been destroyed
    std::cout << "Father is gone\n";
}

Real-World Examples

1. Parent-child relationships

class Node {
    std::vector<std::shared_ptr<Node>> children;  // Owning
    std::weak_ptr<Node> parent;                   // Observing (back-pointer)
};

2. Event observers

class Button {
    std::vector<std::weak_ptr<ClickObserver>> observers;  // Non-owning

    void onClick() {
        for (auto& weakObs : observers) {
            if (auto obs = weakObs.lock()) {
                obs->notify();
            }
        }
        // Clean up dead observers
        observers.erase(remove_if(...));
    }
};

3. Caches

class ImageCache {
    std::map<std::string, std::weak_ptr<Image>> cache;

    std::shared_ptr<Image> get(const std::string& path) {
        auto it = cache.find(path);
        if (it != cache.end()) {
            if (auto img = it->second.lock()) {
                return img;  // Still in use, return it
            }
        }
        // Not in cache or expired, load new image
        auto img = std::make_shared<Image>(path);
        cache[path] = img;  // Store as weak_ptr
        return img;
    }
};

The `shared_ptr.get()` -> weak_ptr

The comment about .get() means: If you ever write this:

// BAD pattern
std::shared_ptr<Widget> sp = std::make_shared<Widget>();
Widget* raw = sp.get();  // Storing raw pointer
// Later: use raw somewhere else — DANGEROUS!

That's usually a sign you should use weak_ptr instead:

// GOOD pattern
std::shared_ptr<Widget> sp = std::make_shared<Widget>();
std::weak_ptr<Widget> wp = sp;  // Non-owning reference
// Later: wp.lock() to safely access

Key Takeaways

`shared_ptr`	`weak_ptr`
Owns the object	Observes the object
Increases ref count	Doesn't affect ref count
Keeps object alive	Object can die
Always valid (until destroyed)	May be expired
Direct access with `->`	Must call `.lock()` first

When to use weak_ptr: Any time you need a reference to an object but don't want to be responsible for keeping it alive — especially parent back-pointers, observers, and caches.

Does this make the cyclic reference problem clearer?

Beyond new and delete: A Practical Guide to Refactoring Raw Pointers to Smart Pointers

Wang - C++ Developer — Fri, 17 Apr 2026 05:45:18 +0000

You've been there. You inherit a codebase filled with Widget* w = new Widget(), manual delete calls scattered across error-prone destructors, and the occasional use-after-free that crashes in production once a week.

You know C++11's smart pointers are the answer. But refactoring a raw pointer to std::unique_ptr, std::shared_ptr, or even back to a plain reference isn't always obvious. The core question is: Who owns this object?

In this article, we'll build a decision framework. In 15 minutes, you'll learn how to mechanically refactor raw pointers and when to choose each smart pointer—or avoid them altogether.

The Decision Workflow (15-Second Check)

Raw Pointer?
    │
    ├─ Does it OWN the object?
    │       │
    │       ├─ NO  → raw reference (&) or raw pointer (*)
    │       │        (never delete)
    │       │
    │       └─ YES → Is ownership EXCLUSIVE?
    │                   │
    │                   ├─ YES → std::unique_ptr ← 80% of cases
    │                   │
    │                   └─ NO  → Is ownership SHARED?
    │                               │
    │                               ├─ YES → Is there a CYCLE?
    │                               │           │
    │                               │           ├─ YES → std::weak_ptr
    │                               │           │
    │                               │           └─ NO  → std::shared_ptr
    │                               │
    │                               └─ NO  → Re-examine design

The 3-Question Drill:

Question	Answer → Action
Owns?	No → Raw reference/pointer (never delete)
Exclusive?	Yes → `unique_ptr`
Shared?	Yes → `shared_ptr` (check for cycles → `weak_ptr`)

That's it. 80% of raw pointers become unique_ptr. 15% become raw references. 5% become shared_ptr/weak_ptr.

The Golden Rule of Refactoring

Never change behavior while refactoring. Start with a single raw pointer. Ask three questions:

Is this pointer nullable? (Can it be nullptr?)
Who is responsible for deleting the object?
Is ownership shared or unique?

Once you answer those, the path becomes clear.

The Obvious Case — Exclusive Ownership → `std::unique_ptr`

Use unique_ptr when exactly one part of the code owns the object, but the pointer might be moved or transferred.

Signs you need unique_ptr:

The raw pointer is deleted in the same class that creates it.
The pointer is never copied (only moved or passed as a raw pointer to functions that don't store it).
You see delete ptr; in a destructor and nowhere else.

Before refactoring:

class Connection {
public:
    Connection() : socket_(new Socket()) {}
    ~Connection() { delete socket_; }
    // Manual move/copy? Omitted for brevity — disaster waiting.
private:
    Socket* socket_;
};

After refactoring:

class Connection {
public:
    Connection() : socket_(std::make_unique<Socket>()) {}
    // Destructor auto-deletes. Move is automatic.
    Connection(Connection&&) = default;
private:
    std::unique_ptr<Socket> socket_;
};

Key nuance: You can still pass a raw pointer to a function that doesn't own the object (e.g., void send(Socket* s)). Use .get() for that. But never .release() unless you truly mean to transfer ownership.

Heuristic: If you would have used std::auto_ptr (RIP), use unique_ptr.

Shared Ownership → `std::shared_ptr`

Use shared_ptr when multiple parts of the system need to keep the object alive and you cannot predict which one will outlive the others.

Signs you need shared_ptr:

The pointer is stored in several containers or callbacks.
You have std::vector and multiple threads or components delete items unpredictably.
You find yourself implementing reference counting manually (e.g., AddRef/Release).

Before refactoring:

class Node {
public:
    Node* parent;
    std::vector<Node*> children;
    ~Node() {
        for (auto* child : children) delete child;
    }
};

This leaks if a child is referenced from two parents. Don't do this.

After refactoring:

class Node : public std::enable_shared_from_this<Node> {
public:
    std::shared_ptr<Node> parent;
    std::vector<std::shared_ptr<Node>> children;
    // No manual destructor.
};

The cost:
shared_ptr doubles the size (two pointers: object + control block) and uses atomic increments (slower, but fine for most apps). Only reach for shared_ptr when unique_ptr is impossible.

The Observer Case — Breaking Cycles → `std::weak_ptr`

shared_ptr has a fatal flaw: cyclic references. If two shared_ptrs point to each other, they never die.

The problem:

class Person {
    std::shared_ptr<Person> mother;
    std::shared_ptr<Person> father;  // Cycle!
};

The fix:

class Person {
    std::shared_ptr<Person> mother;  // Owning
    std::weak_ptr<Person> father;    // Observing (no cycle)
};

Use weak_ptr when you need a non-owning reference to an object managed by shared_ptr.

Full explanation and refactoring techniques for weak_ptr → see the next article.

The No-Ownership Case — Raw References & Raw Pointers

Smart pointers express ownership. Not every pointer needs to be smart. In fact, using a shared_ptr for every single pointer is an anti-pattern (slow, bloated, semantically wrong).

Use plain references (&) or raw pointers (*) for non-owning observers when you are certain the lifetime is longer than the use.

When to use a raw reference:

The object must exist (no nullptr).
You are not storing it for later (e.g., function parameter).
Example: void draw(const Shape& shape);

When to use a raw pointer:

The observer can be null.
You need to reseat it (references can't be reassigned).
Example: void setLogger(Logger* logger) { logger_ = logger; } – but only if the Logger outlives this object.

The critical rule:
A raw pointer or reference must never be deleted. If you see delete ptr on a raw pointer, you made a wrong turn.

Real Refactoring Example — A Cache System

Let's refactor a small in-memory cache from raw pointers to smart pointers.

Before (broken):

class Cache {
    std::unordered_map<std::string, Data*> store;
public:
    void put(const std::string& key, Data* data) { store[key] = data; }
    Data* get(const std::string& key) { return store[key]; }
    ~Cache() { for (auto& [k, v] : store) delete v; }
};
// Usage: who deletes the Data? Cache does, but what if two caches share it?

After (clear ownership):

class Cache {
    // Cache owns the Data exclusively.
    std::unordered_map<std::string, std::unique_ptr<Data>> store;
public:
    void put(const std::string& key, std::unique_ptr<Data> data) {
        store[key] = std::move(data);
    }
    // Returns non-owning observer
    Data* get(const std::string& key) {
        auto it = store.find(key);
        return (it != store.end()) ? it->second.get() : nullptr;
    }
};

Now ownership is explicit. The cache destroys the data. Callers can observe but not delete.

Common Pitfalls During Refactoring

❌ Mixing ownership styles
std::shared_ptr<Widget> sp = std::make_unique<Widget>(); // Works but confusing. Prefer consistent smart pointer types.

❌ Using shared_ptr for everything "just to be safe"
This hides design issues and kills performance (atomic ops). Refactor to unique_ptr first.

❌ Calling .get() and storing the raw pointer long-term
That's just raw pointer ownership again. Store the smart pointer or use weak_ptr.

❌ Forgetting make_unique / make_shared

// Old: std::unique_ptr<Widget> p(new Widget());
// New:
auto p = std::make_unique<Widget>();

make_unique is exception-safe and slightly more efficient.

When Not to Refactor

Some raw pointers are fine:

Non-owning iterators into a buffer.
Polymorphic casts in performance-critical loops (you still need to ensure lifetime).
Legacy APIs that expect raw pointers and manage their own memory. Don't force shared_ptr into a C-style callback.

In those cases, document the lifetime contract: "This pointer is valid only during the call."

Conclusion: Ownership Is Documentation

Refactoring raw pointers to smart pointers isn't just about memory safety—it's about expressing intent. When I see unique_ptr, I know: This object has a single, clear owner. When I see shared_ptr, I know: Multiple agents collaborate here. When I see a raw reference, I know: I'm just visiting; don't delete.

Next time you look at a MyClass* member variable, ask: "Who owns this?" Then pick the tool that answers that question in code.

Your future self—and your teammates—will thank you.

DEV Community: Wang - C++ Developer

Crash Patterns Overview: A Practical, Symptom‑First Guide to Debugging C++ Crashes

Contents

⭐ Why a Symptom‑First Model

⭐ Layer 1 — Symptom Buckets (Start Here)

S1 — Clean Backtrace Crashes

S2 — Crashes in malloc/free/new/delete

S3 — Broken or Nonsensical Backtrace

S4 — Process Frozen (No Crash)

S5 — Sanitizer Reports (ASan/TSAN/UBSan/Valgrind)

⭐ Layer 2 — Crash Patterns (What the Symptoms Suggest)

Memory Lifetime Errors

1. Null Pointer Dereference

2. Use‑After‑Free (UAF)

3. Double Free / Invalid Free

Memory Boundary Errors

4. Boundary / Off‑By‑One Error

5. Stack Corruption

6. Heap Corruption

Concurrency Errors

7. Data Race

8. Deadlock / Livelock

ABI / Layout Errors

9. ABI Mismatch

Initialization Errors

10. Uninitialized Memory

⭐ The Debugging Workflow (The Core of This Series)

⭐ What This Model Enables for Teams

⭐ What’s Next

Finding Memory Leaks in Legacy C++ Applications with Valgrind

Table of Contents

The Workflow

Step 1 — Reproduce the Leak

Measure memory growth

Find the minimum trigger

Step 2 — Static Analysis (5 minutes, zero runtime cost)

Clang Static Analyzer

clang‑tidy

Step 3 — Compile for Valgrind

Step 4 — Run Valgrind

For long‑running services

Step 5 — Understand Valgrind's Leak Types

What each type means

If "still reachable" grows

Step 6 — Capture the Stack Trace

Step 7 — Optional Regression Test

Quick Reference

Real‑World Example

The bug

Valgrind report

The fix

The Golden Rule

Debugging Legacy C++ Crashes: Core Dumps, Symbols, addr2line, and GDB Explained

Why This Matters

Crash Debugging Decision Map

Path A — You Have a Core File

A1 — Locate the Core File

A2 — Identify Which Binary Produced the Core

A3 — Check Whether the Binary Has Debug Symbols

A4 — Debugging With Symbols (Best Case)

A5 — Binary Is Stripped: Find the Symbol File

A5.1 — Extract Build ID

A5.2 — Locate Matching Symbol File

A6 — Debug Using Separate Symbol Files

A7 — No Symbol File: Reproduce With Debug Build

A8 — Map Raw Addresses Using an Unstripped Build

A9 — No Symbols, No Reproduction: Fallback Forensics

Inspect Registers

Inspect Instructions Around the Crash

Path B — No Core File Generated

B1 — Check Core Dump Settings

B2 — Enable Core Dumps

B3 — Set Core File Location

B4 — Fix Permissions

B5 — Test Core Dump Generation

B6 — Rerun the Crashed Application

Common Pitfalls

Quick Reference Table

Pro Tips

Conclusion

The Solution: `weak_ptr`

Using `weak_ptr`: The `.lock()` method

The `shared_ptr.get()` -> weak_ptr

The Obvious Case — Exclusive Ownership → `std::unique_ptr`

Shared Ownership → `std::shared_ptr`

The Observer Case — Breaking Cycles → `std::weak_ptr`