heisenbug

programming

A bug that changes behaviour or disappears when you try to observe it.

Named after the uncertainty principle, a heisenbug is the kind that vanishes under a debugger, or only shows up in production, because the act of watching (extra logging, slower timing, a breakpoint) perturbs the timing or memory conditions that cause it. Its opposite, always reproducible, is a bohrbug.

A heisenbug disappears when you try to observe it. Attach a debugger and the program behaves; add a print statement and the fault vanishes; run it under a profiler and everything is fine. The name borrows Heisenberg's uncertainty principle as a joke, and the mechanism underneath is entirely mundane.

Observation changes timing, and timing is usually the bug. A debugger serializes threads that were racing, a print statement adds microseconds that let the slower thread finish first, and a debug build initializes memory that a release build leaves full of whatever was there before. The bug did not hide; you changed the conditions that produced it.

That is why the diagnosis is a strong signal rather than a frustration. A fault that evaporates under observation is almost certainly a race condition, an uninitialized read, or a dependency on undefined behaviour that the optimizer treats differently. The productive response is to stop trying to catch it live and instead reason about the concurrency, enable sanitizers that detect the class rather than the instance, and add logging that records without altering timing. Chasing it interactively is chasing your own instrument.

Also known as: heisenbug, heisenberg bug

← All glossary entries