DEV Community: Rui-Tech

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

Rui-Tech — 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.

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

Rui-Tech — 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

Rui-Tech — 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

Rui-Tech — 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: Rui-Tech

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

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

Step 1. Audit and Annotate Ownership

Step 2. Use Static Analysis and Compiler Options

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

Warning 2: Deleting a non-owner pointer

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

Warning 4: Assignment loses ownership

Warning 5: Using std::unique_ptr with raw delete

Step 3. Replace with Modern Types

Step 4. Refactor Incrementally

An Example: Step‑by‑Step Refactoring

When NOT to Refactor

Reference: clang-tidy Commands for Raw Pointer Refactoring

Check Commands (Analyze Only)

Fix Commands (Apply Changes)

Recommended Workflow with clang-tidy

Conclusion

Beyond new and delete: to Weak Pointer

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

Normal case (no cycle)

The cyclic problem

The Solution: weak_ptr

Using weak_ptr: The .lock() method

Real-World Examples

1. Parent-child relationships

2. Event observers

3. Caches

The shared_ptr.get() -> weak_ptr

Key Takeaways

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

The Decision Workflow (15-Second Check)

The Golden Rule of Refactoring

The Obvious Case — Exclusive Ownership → std::unique_ptr

Shared Ownership → std::shared_ptr

The Observer Case — Breaking Cycles → std::weak_ptr

The No-Ownership Case — Raw References & Raw Pointers

Real Refactoring Example — A Cache System

Common Pitfalls During Refactoring

When Not to Refactor

Conclusion: Ownership Is Documentation

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`