What is a Heisenbug in the context of using a debugger, and when does it matter?

A Heisenbug is a bug whose behavior changes or disappears when you try to observe it, the act of debugging perturbs the system enough to alter the outcome. With GDB on embedded this happens because halting at a breakpoint stops the world: the CPU freezes, but real-world time and some hardware keep going (or the timing relationships change completely), so timing-dependent behavior diverges from a normal run. A race condition between a task and an ISR might never trigger when you single-step because the timing window closes; a communication protocol with tight timing requirements fails or succeeds differently when the core is halted mid-transaction; a watchdog may fire (or be frozen by debug config) changing the flow; and inserting prints similarly shifts timing and code size. So Heisenbugs matter precisely for the class of problems that are about timing and concurrency, races, real-time deadline misses, protocol timing, interrupt interactions, which are exactly the hard embedded bugs. The way to handle them is to avoid halting: use non-intrusive observation like hardware trace (ETM/SWO instrumentation), toggling a GPIO and watching it on a logic analyzer/scope, RTT or buffered logging that doesn't block, or adding counters/timestamps you read out later, techniques that record what happened without stopping the system. The lesson is that a debugger's halt-and-inspect model is powerful for state bugs but can hide timing bugs, so you reach for trace and logging when stopping the program would change the answer.