Debugging C++ and Undefined Behavior

A compiler error prevents translation, a linker error prevents the final executable, a runtime failure interrupts execution, and a logic error produces the wrong result. C++ also has undefined behavior: the program violates a rule for which the standard imposes no required outcome.

Classification determines the first evidence to inspect. Read compiler and linker messages exactly. For a crash, capture the input, exception or signal, and call stack. For wrong output, compare state against a hand-worked example.

Reading outside a container, using an object after its lifetime ends, signed integer overflow, and reading an uninitialized fundamental value are common sources of undefined behavior. The compiler may assume these cases never occur while optimizing valid programs.

Do not reason from one observed run. Correct the violated precondition or lifetime. Standard containers, bounds-aware access during investigation, RAII, and strong types reduce the surface area but do not remove the need for contracts.

Set a breakpoint just before the suspected decision or access. Step Over executes a call without entering it; Step Into follows the call; Step Out returns to its caller. Watches track expressions, and the call stack explains how execution reached the current line.

Temporary stream output can also expose state in constrained environments. Record only values tied to a hypothesis, then remove the noise. Change one cause at a time and rerun the original failing input plus nearby boundaries.

for (std::size_t index{}; index <= values.size(); ++index)
{
  std::cerr << "index=" << index
            << ", size=" << values.size() << '\n';
  std::cout << values[index] << '\n'; // invalid when index == size
}

Strong warning levels catch suspicious conversions, shadowed names, missing returns, and other defects before runtime. Treat new warnings as work to understand, not messages to suppress reflexively. Different compilers find different issues, so portable projects benefit from more than one toolchain in continuous integration.

Sanitizers complement warnings by instrumenting an executable. They are not proofs of correctness: they detect exercised failures. Combine them with boundary tests, debugger inspection, code review, and clear ownership.