a watchpoint

A breakpoint says 'stop when execution reaches this place'. But sometimes you do not care where the code is - you care about a value. Suppose a counter that should always be small somehow becomes huge, and you have no idea which of a hundred lines did it. A watchpoint is the tool: instead of watching a location in the code, it watches a piece of data in memory, and tells the debugger 'stop the instant this variable's value changes', no matter where in the program that change happens.

Concretely, you point a watchpoint at a variable or a memory address - in gdb, 'watch count'. From then on, whenever the program writes a new value to that location, the debugger pauses and shows you the old value, the new value, and exactly which line made the change. You can also watch for reads (a read watchpoint) or any access. Modern CPUs help do this cheaply: they have a few special debug registers that the hardware checks on every memory access, so a hardware watchpoint barely slows the program down. If you ask to watch more locations than the hardware supports, the debugger may fall back to a software watchpoint that single-steps the whole program and re-checks the value each step - correct, but dramatically slower.

Why it matters: watchpoints are the right weapon for 'who is corrupting this?' bugs - a field that gets mysteriously overwritten, a pointer that turns NULL out of nowhere, a value clobbered by a buffer overflow from an unrelated array. You let the program run, and the debugger stops you at the exact write that did the damage, so you can read the backtrace and see the culprit. The catch is scope and lifetime: a watchpoint on a local variable becomes meaningless once that function returns and the variable's stack slot is gone, so the debugger will remove it; watching a heap address stays valid as long as that memory does.