Heisenbug

In computer programming jargon, a heisenbug is a software bug that seems to disappear or alter its behavior when one attempts to study it.[1] The term is a pun on the name of Werner Heisenberg, the physicist who first introduced the uncertainty principle, and it is a reference to the observer effect, which states that the act of observing a system inevitably alters its state. In electronics, the traditional term is probe effect, where attaching a test probe to a device changes its behavior. The term has been criticized because it confuses Heisenberg's uncertainty principle (to which it owes the name) with the observer effect in quantum mechanics, which are two different concepts.[2]

Similar terms, such as "bohrbug", "mandelbug",[3][4][5] "hindenbug", and "schrödinbug"[6][7] (see the section on related terms) have been occasionally proposed for other kinds of unusual software bugs, sometimes in jest.[8][9]

## Contents

* 1 Examples
* 2 Related terms
* 3 Etymology
* 4 Resolution
* 5 See also
* 6 References
* 7 External links

## Examples

Heisenbugs occur because common attempts to debug a program, such as inserting output statements or running it with a debugger, usually have the side-effect of altering the behavior of the program in subtle ways, such as changing 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 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 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 . Similarly, heisenbugs may be caused by side-effects in test expressions used in runtime assertions in languages such as C and C++, where the test expression is not evaluated when assertions are turned off in production code using the `NDEBUG` 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 an invalid pointer (which may point to a different place when debugging). Debuggers also commonly allow the use of breakpoints or provide other user interfaces that cause additional source code (such as property accessors) to be executed stealthily, which can, in turn, change the state of the program.[10]

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 as race 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 the observer effect in information technology. Frustrated programmers may humorously blame a heisenbug on the phase of the moon,[11] or (if it has occurred only once) may explain it away as a soft error due to alpha particles or cosmic rays affecting the hardware, a well-documented phenomenon known as single event effects.

## Related terms

A bohrbug, by way of contrast, is a "good, solid bug". Like the deterministic Bohr atom model, they do not change their behavior and are relatively easily detected.[12][13]

A schrödinbug or schroedinbug (named after Erwin Schrödinger and his thought 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.[6]

A hindenbug[14] (named after the Hindenburg disaster) is a bug with catastrophic behavior.

A higgs-bugson[15][16] (named after the Higgs 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).

## Etymology

The earliest known appearance is from 1983, in an ACM publication.[17]

The term was used in 1985 by Jim Gray, in a paper about software failures,[18] and is sometimes mistakenly attributed to him because of this publication. It was used in 1986 by Jonathan Clark and Zhahai Stewart on the mailing list (later Usenet news group) comp.risks.[19]

Bruce Lindsay, a researcher at IBM, affirmed in a 2004 ACM Queue interview that he was present when the Heisenbug was originally defined,[20] but did not state when this occurred.

## Resolution

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.[21]

## See also

* Cargo cult programming
* Jinx Debugger—a tool that automatically explores executions likely to expose Heisenbugs
* Memory debugger

## References

1. ↑ "The Jargon File: heisenbug". http://catb.org/jargon/html/H/heisenbug.html.
2. ↑ Pike, Rob (2010-08-27). "Know your science" (in en). https://commandcenter.blogspot.com/2010/08/know-your-science.html.
3. ↑ "The Jargon File: Mandelbug". Catb.org. http://catb.org/jargon/html/M/mandelbug.html.
4. ↑ Raymond, Eric S.; The New Hacker's Dictionary, 3rd edition, 1996
5. ↑ Clarke, Arthur C., The Ghost from the Grand Banks, Bantam Books, 1990
6. ↑ 6.0 6.1 "The Jargon File: Schroedinbug". Catb.org. http://www.catb.org/jargon/html/S/schroedinbug.html.
7. ↑ Raymond, Eric S.; The New Hacker's Dictionary, 3rd edition, 1996
8. ↑ The following article investigates the various definitions of bohrbug, mandelbug and heisenbug proposed in the literature, as well as the statements made about the relationships between these fault types: Grottke, Michael; and Trivedi, Kishor S.; Software Faults, Software Aging and Software Rejuvenation, Journal of the Reliability Engineering Association of Japan, Vol. 27, No. 7, pp. 425–438, 2005.
9. ↑ Grottke, Michael; and Trivedi, Kishor S.; Fighting Bugs: Remove, Retry, Replicate, and Rejuvenate, IEEE Computer vol. 40, no. 2 (February 2007), pp. 107–109
10. ↑ "Java toString() override with initialization as a side effect"
11. ↑ CATB.org, "phase of the moon"
12. ↑ Goshgarian, Gary; Exploring Language, HarperCollins College Publishers, 1995
13. ↑ "Such transient software failures have been given the whimsical name 'Heisenbug' because they disappear when reexamined. By contrast, 'Bohrbugs' are good solid bugs." (IEEE Computer Group News, Volume 24, Numbers 7–12, 1991)
14. ↑ "Hinden Bug". http://c2.com/cgi/wiki?HindenBug.
15. ↑ "New Programming Jargon". 20 July 2012. https://blog.codinghorror.com/new-programming-jargon/.
16. ↑ "20 Hilarious Programming Jargon Phrases You Should Use When Talking to Engineers". https://www.businessinsider.com/20-hilarious-programming-jargon-phrases-you-should-know-when-talking-to-engineers-2012-7.
17. ↑ Proceedings of the ACM SIGSOFT/SIGPLAN Software Engineering Symposium on High-Level Debugging, Pacific Grove, California, March 20–23, 1983, Association for Computing Machinery, 1983, Google Books search:

> 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, in Proceedings of the IEEE 5th International Conference on Distributed Computing Systems (ICDCS), IEEE Computer Society, Computer Society Press, 1985, pp. 515-522 Google Books search:

> This the Heisenberg Uncertainty Principle as applied to Debugging, sometimes called the "Heisenbug" Principle [ACM83].

18. ↑ Gray, Jim (1985). "Why Do Computers Stop And What Can Be Done About It?". Technical Report 85.7. Tandem Computers. https://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.59.6561.
19. ↑ (16 December 1986) RISKS DIGEST 4.30 \- (23 December 1986) RISKS DIGEST 4.34, moderated by Peter G. Neumann
20. ↑ ""A Conversation with Bruce Lindsay", ACM Queue vol. 2, no. 8 - November 2004". Queue.acm.org. https://queue.acm.org/detail.cfm?id=1036486.
21. ↑ P., Birman, Kenneth (2005). Reliable distributed systems : technologies, Web services, and applications. New York: Springer. ISBN 0387276017. OCLC 225378026.

## External links

* The Heisenberg Debugging Technology
* A Story About Magic
* OpenOffice won't print on Tuesdays, a heisenbug that took almost nine months to solve.

0.00

(0 votes)

Original source: https://en.wikipedia.org/wiki/Heisenbug. Read more

|

Retrieved from "https://handwiki.org/wiki/index.php?title=Heisenbug&oldid=4227059"