Incomputer programming jargon, aheisenbug is asoftware bug that seems to disappear or alter its behavior when one attempts to study it.[1] The term is apun on the name ofWerner Heisenberg, thephysicist who first asserted theobserver effect ofquantum mechanics, which states that the act of observing a system inevitably alters its state. In electronics, the traditional term isprobe effect, where attaching atest probe to a device changes its behavior.
Similar terms, such asbohrbug,mandelbug,[2][3][4]hindenbug, andschrödinbug[5][6] (see the section onrelated terms) have been occasionally proposed for other kinds of unusual software bugs, sometimes in jest.[7][8]
Heisenbugs occur because common attempts to debug aprogram, such as insertingoutput statements orrunning it with adebugger, usually have the side-effect of altering the behavior of the program in subtle ways, such as changing thememory addresses of variables and the timing of its execution.
One common example of a heisenbug is a bug that appears when the program is compiled with an optimizingcompiler, but not when the same program is compiled without optimization (as is often done for the purpose of examining it with a debugger). While debugging, values that an optimized program would normally keep inregisters are often pushed to main memory. This may affect, for instance, the result offloating-point comparisons, since the value in memory may have smaller range and accuracy than the value in the register[citation needed]. Similarly, heisenbugs may be caused by side-effects in test expressions used in runtimeassertions in languages such asC andC++, where the test expression is not evaluated when assertions are turned off in production code using theNDEBUG macro.
Other common causes of heisenbugs are using the value of a non-initialized variable (which may change its address or initial value during debugging), or following aninvalidpointer (which may point to a different place when debugging). Debuggers also commonly allow the use ofbreakpoints or provide other user interfaces that cause additionalsource code (such as property accessors) to be executed stealthily, which can, in turn, change the state of the program.[9]
End-Users can experience a heisenbug when the act of making a screenshot of the heisenbug for observation fixes the heisenbug and the screenshot shows a perfectly working state. This effect can happen when complex stacks of software work together, for example a web browser using a hardware graphic card acceleration which causes rendering errors on the physical screen that do not show on a screenshot.
Time can also be a factor in heisenbugs, particularly with multi-threaded applications. Executing a program under control of a debugger can change the execution timing of the program as compared to normal execution. Time-sensitive bugs, such asrace conditions, may not occur when the program is slowed down by single-stepping source lines in the debugger. This is particularly true when the behavior involves interaction with an entity not under the control of a debugger, such as when debugging network packet processing between two machines and only one is under debugger control.
Heisenbugs can be viewed as instances of theobserver effect in information technology. Frustrated programmers may humorously blame a heisenbug on thephase of the moon,[10] or (if it has occurred only once) may explain it away as asoft error due toalpha particles orcosmic rays affecting the hardware, a well-documented phenomenon known assingle event effects.
Abohrbug, by way of contrast, is a "good, solid bug". Like the deterministicBohr atom model, they do not change their behavior and are relatively easily detected.[11][12]
Amandelbug (named afterBenoît Mandelbrot'sfractal) is a bug whose causes are so complex it defies repair, or makes its behavior appearchaotic or evennon-deterministic.[2] The term also refers to a bug that exhibits fractal behavior (that is,self-similarity) by revealing more bugs (the deeper a developer goes into the code to fix it the more bugs they find).[citation needed]
Aschrödinbug orschroedinbug (named afterErwin Schrödinger and histhought experiment) is a bug that manifests itself in running software after a programmer notices that the code should never have worked in the first place.[5]
Ahindenbug[13] (named after theHindenburg disaster) is a bug with catastrophic behavior.
Ahiggs-bugson[14][15] (named after theHiggs boson particle) is a bug that is predicted to exist based upon other observed conditions (most commonly, vaguely related log entries and anecdotal user reports) but is difficult, if not impossible, to artificially reproduce in a development or test environment. The term may also refer to a bug that is obvious in the code (mathematically proven), but which cannot be seen in execution (yet difficult or impossible to actually find in existence).
The term was used in 1985 byJim Gray, in a paper about software failures[16] (and is sometimes mistakenly attributed to him because of this publication) and also in 1986 by Jonathan Clark and Zhahai Stewart on the mailing list (laterUsenet news group)comp.risks.[17]
Bruce Lindsay, a researcher atIBM, affirmed in a 2004ACM Queue interview that he was present when the Heisenbug was originally defined.[18]
An earlier appearance inACM publications is from 1983.[19]
Heisenbugs are difficult to identify and fix; often attempting to resolve them leads to further unexpected behavior. Because the problem manifests as the result of a separate, underpinning bug, the behavior can be hard to predict and analyze during debugging. Overall the number of heisenbugs identified should decrease as a piece of software matures.[20]
This is the Heisenberg Uncertainty Principle as applied to debugging (an instance of such a bug was called a "Heisenbug" by one participant.)
Also cited in LeBlanc, Richard J.; Robbins, Arnold D.;Event-Driven Monitoring of Distributed Programs, inProceedings of the IEEE 5th International Conference on Distributed Computing Systems (ICDCS), IEEE Computer Society, Computer Society Press, 1985, pp. 515-522Google Books search:
This the Heisenberg Uncertainty Principle as applied to Debugging, sometimes called the "Heisenbug" Principle [ACM83].
{{cite book}}: CS1 maint: multiple names: authors list (link)