Heisenbug is a whimsical computer programming jargon term for a software bug that seems to disappear when one attempts to study it.[1] The term is a pun on the name of Werner Heisenberg, the physicist who is commonly associated to the observer effect of quantum mechanics; which states that the act of observing a system inevitably alters its state.
Other similar terms, such as bohrbug, mandelbug[2], and schrödinbug[3] have been occasionally been proposed for other kinds of unusual software bugs, usually in jest[4][5]; however (unlike Heisenbug) they are not widely known or used.
Contents |
Heisenbugs occur because common attempts to debug a program, such as inserting output statements or running it in a debugger, usually modify the code, change the memory 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 optimizing compiler, but not when the same program when compiled without optimization (as one often does in order to examine it with a debugger). While debugging, values that an optimized program would normally be kept in registers are often pushed to main memory. This may affect, for instance, the result of floating-point comparisons, since the value in memory may have smaller range and accuracy than the value in the register. In these cases, the bug is in the optimizing compiler and not in the program.
Other common causes of heisenbugs are using the value of a non-initialized variable (which may change its address and/or initial value during debugging), or following an invalid pointer (which may point to a different place when debugging).
Time can also be a factor in heisenbugs. 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 as race conditions may not reproduce 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.
In general, programs that exhibit time-dependent behavior are vulnerable to time-dependent failures. These could occur during a certain part of a scheduled process, or at special times, such as on leap days or when a process crosses a daylight saving time, day, month, year, or century boundary (as with the Year 2000 bug).
Heisenbugs can be viewed as instances of the observer effect in information technology. Frustrated programmers may humorously blame a heisenbug on the phase of the moon[6], or (if it has occurred only once) may explain it away as a soft error due to alpha particles or cosmic rays.
The term was used in 1985 by Jim Gray, in a paper about software failures[7] and also in 1986 by Zhahai Stewart on the mailing list (later Usenet news group) comp.risks.[8] Bruce Lindsay offered an alternative history.[9]