cpp-debugging

C++ Debugging

systematic-debugging gives you the language-neutral method. This skill adds the native C++ toolchain and runtime techniques that matter once the bug involves crashes, corrupted memory, UB, or platform-specific debugger state.

When to Use

• A C++ process crashes with a segmentation fault, access violation, or abort
• The bug depends on object lifetime, ownership, or move/copy behavior
• Behavior changes between debug and release builds
• AddressSanitizer, UndefinedBehaviorSanitizer, or a debugger is needed to see the failure clearly
• A native test hangs, deadlocks, or corrupts memory without a clear stack trace

When NOT to Use

Instead of cpp-debugging	Use
You still do not have a stable reproduction or root-cause workflow	systematic-debugging
The failure is a build, compile, or link error	fix-build-errors
The issue is performance-only, not correctness	performance-optimization

Prerequisites

• A reproducible failing command, test, or executable
• A debug-capable build with symbols
• Access to the relevant debugger or sanitizer-enabled toolchain
• Enough context to tell whether the bug is runtime, lifetime, concurrency, or build-related

Workflow

1. Rebuild for diagnosis, not speed

Start with a debuggable build before chasing the crash:

# CMake
cmake -S . -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build --config Debug

# Clang/GCC direct build example
clang++ -std=c++20 -g -O0 -Wall -Wextra -Wpedantic main.cpp -o app.exe

Guidelines:

• enable symbols (-g, /Zi)
• reduce or disable optimization while reproducing (-O0, /Od)
• keep warnings enabled
• reproduce with the same inputs that fail in CI or production-like runs

2. Capture the exact failing surface

# Run the failing binary or test under the same conditions each time
ctest --test-dir build --output-on-failure

# Or run the specific executable directly
.\build\app.exe