Debug

Inspecting and Modifying Variables While Debugging

Learn how to inspect, evaluate, watch, and safely modify variables during interactive debugging in C, C++, and similar languages.

Variable inspection is the practice of examining program values while execution is paused. A debugger can show local variables, parameters, object fields, pointers, arrays, and calculated expressions. You can also monitor values as they change and, for controlled experiments, temporarily assign new values.

This is useful when the program produces incorrect output, takes an unexpected branch, crashes, or appears to corrupt memory. The goal is to find the earliest point where actual state differs from expected state.

Why Inspect Variables?

Source code describes what should happen, but the debugger shows what did happen at a particular execution point. Examining state can reveal:

• An incorrect assumption about an input, return value, or object field.
• Unexpected control flow caused by a boolean condition, type conversion, or boundary error.
• Invalid input that was not rejected before use.
• A value overwritten by the wrong statement, a buffer overrun, or an ownership error.
• State changed by another function or thread.

A variable is a named program value associated with a type, storage, lifetime, and scope. Its source-level name is not the same thing as its runtime storage location. For example, count is a name in source code, while the running program may store its current integer in a stack slot or processor register. The debugger connects these concepts using debug symbols and machine-code information.

Inspect values at meaningful execution points: immediately before a suspected state transition, at function entry, when an exception occurs, before and inside a loop, or at a breakpoint near the failure. A value inspected after it changes may look correct even though it was wrong earlier.

Program State, Scope, and Lifetime

Scope is the part of the source program where a name can be referenced. Lifetime is the execution interval during which the variable's storage and value are valid. These concepts are related but different: a variable can have a narrow scope and a long lifetime, as with a function-local static variable.

• Local variable: Available inside a function, method, or block. Its lifetime is commonly one invocation or one block, depending on its declaration.
• Parameter: A variable representing an input in the called function. It may contain a copied value, a reference, or a pointer.
• Global variable: Broadly visible program state that commonly lasts for the process lifetime.
• Static variable: A variable with persistent storage duration. It may be limited to one source file, belong to a function, or be associated with a class.
• Member field: State stored inside a structure or class object.
• Temporary expression: A value calculated during an expression, such as price * quantity. It may not have a stable source-level storage location.

Lexical scope follows the nesting of declarations in the source. Shadowing occurs when an inner declaration hides an outer variable with the same name:

int value = 10;
{
    int value = 20; // This declaration shadows the outer value
    // Inspecting "value" here means 20
}
// Inspecting "value" here means 10

A debugger may report that a variable is unavailable when execution is outside its scope, before its declaration has been reached, after its lifetime has ended, or when optimization removed or transformed it. Identical names in different functions or threads are also different variables.

Variable kinds and debugger views

Viewing and Evaluating Values

Debugger interfaces differ, but the underlying actions are consistent:

1. Stop at a breakpoint, exception, function entry, or selected instruction.
2. Select the correct thread and stack frame.
3. Inspect a named variable in the locals, arguments, globals, or watch panel.
4. Expand objects, arrays, and nested members as needed.
5. Evaluate an expression to calculate a related value.
6. Compare actual values with the expected invariant or input.

Common debugger-agnostic actions include:

Inspect variable:       count
List locals:            current frame's local variables
List arguments:         current function's parameters
Evaluate expression:   total + tax
Evaluate condition:    index < limit && item != nullptr
Inspect member:         order.customer.id
Inspect pointer address:buffer
Inspect target:         *buffer, only after validating buffer
Display array range:    elements[0] through elements[9]
Select frame:           caller or callee stack frame
Assign temporary value: limit = 0

These are action descriptions rather than a universal command syntax. Graphical debuggers provide panels and context menus; command-line debuggers provide their own commands. Consult the syntax for the debugger and language being used rather than assuming that one command vocabulary applies everywhere.

Expressions and formats

Expression evaluation can expose a hidden relationship. Evaluate arithmetic, comparisons, casts, function results when safe, and member access. For an unexpected branch, inspect both the complete condition and each operand. A cast can also reveal whether a signed, unsigned, integer, character, or floating-point interpretation explains the result.

Inspecting Complex Data

• Structures and classes: Expand fields recursively, then inspect the fields relevant to the invariant. Distinguish user-visible fields from compiler-generated padding, vtable pointers, reference counters, and other implementation details.
• Arrays and collections: Start with a small bounded range, such as ten elements around the current index. Check the length, capacity, index, and element type before expanding further.
• Unions: Inspect the active interpretation. The same storage can represent different types, so an apparently strange value may result from viewing the wrong member.
• Strings: A character array may include a terminator that is not part of the visible text. Check the buffer boundary, length, encoding, and whether the debugger is displaying bytes, code units, or decoded characters.
• Pointers: Inspect the pointer value first. Dereference it only when the address is non-null, within a valid object, correctly aligned for its type, and still within the object's lifetime.
• Linked structures: Follow only a few nodes at a time and stop if a pointer repeats, leaves the expected region, or becomes invalid. Cycles and corrupted links can otherwise produce overwhelming output.

Bounded memory and array displays reduce noise and lower the chance of attempting to read outside valid storage. A pointer's address, the address of the pointer variable, and the value stored at the target are three different observations.

Stack Frames, Threads, and Identical Names

A stack frame is the per-call execution record containing arguments, locals, return information, and related state. Each active function call has its own frame. Selecting a caller frame changes which locals and parameters the debugger can resolve.

main:       input = 12
  calls calculate(input)
calculate:  input = 12       // pass-by-value copy
  calls adjust(&input)
adjust:     input points to calculate's input

With pass-by-value, changing the callee's parameter normally does not change the caller's source variable. With a reference or pointer argument, the callee may change the caller's object. Compare the relevant values in both frames instead of assuming that equal names refer to equal storage.

Threads have separate stacks and therefore separate locals, but they may share globals and heap objects. Select the thread that encountered the failure before evaluating a name. If another thread can mutate the same object, a value may change between pauses; use thread-aware stepping, synchronization analysis, or a watchpoint where supported.

Watching Changing Values

A watch expression is an expression displayed automatically whenever execution stops. For a loop, useful watches might include index, accumulator, limit, and items[index]. Watch expressions help show the iteration in which the first unexpected value appears.

A watchpoint, also called a data breakpoint, stops execution when a memory location or supported expression is accessed or modified. A write watchpoint stops on changes, a read watchpoint stops when the location is read, and an access watchpoint covers reads and writes where the debugger and platform support those modes.

Watchpoints commonly use limited hardware resources. Some debuggers fall back to software monitoring, which can be much slower. Watch a small, stable field or address, remove unnecessary watchpoints, and use a conditional breakpoint or targeted logging when appropriate.

Modifying Variables Safely

Most interactive debuggers provide an assignment action for a variable, member, or valid memory location. For example, you might temporarily set retry_count = 0, change an input to a boundary value, or alter a flag to test a branch.

Legitimate uses include:

• Testing whether a suspected branch explains the symptom.
• Bypassing a known-bad input to explore later code.
• Checking whether a threshold or boundary is responsible.
• Narrowing the location of a fault before changing source code.

Do not casually change ownership flags, allocation metadata, reference counts, object invariants, synchronization state, or shared data while another thread is running. Changing a pointer does not make its target valid. After an experiment, restart or rerun from a clean state and confirm the cause with a source-level fix and a reproducible test.

Memory and Pointer Safety

A pointer stores a memory address. Dereferencing accesses the object at that address. These are separate operations: inspect ptr to see the address, and inspect *ptr only after validating the target.

• Null pointer: Represents no valid target and must not be dereferenced.
• Uninitialized pointer: Has not been assigned a defined address.
• Dangling pointer: Retains an address after its object has been destroyed or released.
• Out-of-range pointer: Points outside the valid bounds of the intended object or array.
• Invalid pointer: Cannot safely be used as an address for the expected object.

Check address formatting, alignment, allocation ownership, object lifetime, and buffer boundaries. Suspicious repeated byte patterns, sentinel values, a pointer just beyond an array, or two unrelated owners pointing to the same mutable object can indicate corruption or unexpected aliasing. Inspecting memory itself can also fault if the address is unmapped, so use bounded reads.

Debug Symbols and Optimized Builds

Debug symbols are build metadata that maps machine instructions and storage to source files, lines, functions, types, and variable names. The symbol files must match the exact executable under investigation. Source mappings alone cannot make unrelated binaries trustworthy.

Optimization transforms code to improve speed or size. The compiler may inline a function, reorder instructions, keep a value in a register, eliminate a variable, merge equivalent values, or represent a source expression only temporarily. As a result, a debugger may show an unavailable value, a stale value, or a location that does not correspond neatly to the source line.

When reliable source-level inspection matters, use a debug-oriented build with debug symbols and low or disabled optimization, as appropriate for the language and toolchain. Preserve the executable and matching symbols. A release-like build can still be necessary for a production-only failure, but use surrounding observable state, registers, disassembly, logs, and control flow as advanced fallback evidence rather than trusting one variable display.

Practical Debugging Scenarios

Incorrect loop result

Set a breakpoint before the loop and another within its body. Inspect the index, bound, accumulator, and current element. Add a watch expression for the accumulator and relevant element. Step through the smallest useful unit and identify the first iteration where the result differs from expectation. Check off-by-one boundaries and whether the bound changes during the loop.

Unexpected conditional branch

Evaluate the complete boolean condition and each operand separately. Display integer values in decimal and hexadecimal, and inspect the types. This can expose signed-versus-unsigned comparisons, a character being mistaken for an integer, or a conversion that changes the result. Temporarily change an input variable to test whether the branch causes the symptom, then rerun from a clean state.

Null or invalid pointer crash

Stop before the dereference and inspect the pointer address without reading its target. Determine whether it is null, uninitialized, dangling, out of bounds, or incorrectly aligned. Move up the call stack to find where the pointer should have been initialized and compare ownership and lifetime expectations with the actual path.

Unexpected object-field mutation

Inspect the object before and after the suspect operation. If the damaged field's writer is unknown, create a watchpoint on the field or its underlying storage. When execution stops, inspect the statement, selected frame, and thread that performed the write. Remove the watchpoint when finished because frequent writes can slow execution.

Wrong value in a caller

Select the caller and callee frames and compare similarly named parameters. Determine whether the argument was passed by value, reference, or pointer. A callee's local copy may change without changing the caller, while a reference or pointer can mutate shared storage.

A Repeatable Variable-Debugging Workflow

1. Start with the observed incorrect output, crash, exception, or unexpected branch.
2. Set a breakpoint before the suspected state transition rather than after the symptom.
3. Select the correct thread and frame.
4. Inspect inputs, parameters, relevant locals, object members, pointers, and invariants.
5. Evaluate the full condition and use suitable formats for numbers, flags, characters, strings, and addresses.
6. Step through the smallest useful unit while watching state changes.
7. Compare actual values with expected values and record the earliest divergence.
8. Use a watchpoint when the writer of a corrupted field or memory location is unknown.
9. Temporarily modify a value only for a controlled experiment, then restart from clean state.
10. Change the source, add a reproducible test, and confirm that the original failure is fixed.

Troubleshooting Quick Reference

• The debugger says a variable does not exist: Confirm the selected thread and frame, stop inside the relevant function after the declaration, list available locals, check for shadowing, and verify that symbols match the executable.
• A value is optimized out: Reproduce with a debug-oriented build, verify build identity, and inspect surrounding state instead of relying on one unavailable value.
• The value appears correct but behavior is wrong: Move the breakpoint earlier, inspect every operand and dependent member, change display formats, and consider another thread's writes.
• A watchpoint fails or causes a large slowdown: Remove unused watchpoints, watch a smaller stable location, and use a conditional breakpoint or targeted logging if hardware resources are limited.
• Dereferencing causes unreadable memory or another fault: Inspect the address first, verify object lifetime and allocation ownership, trace pointer assignments, and use memory-safety diagnostics when available.

Related Debugging Topics

For a broader view of runtime inspection, see debugger views. For runtime profiling and diagnostic data, see profiling information and the command-line profiling view.