8/8/2019 Unusual Software Bug

http://slidepdf.com/reader/full/unusual-software-bug 1/5

Unusual software bug 1

Unusual software bug

Unusual software bugs are a class of software bugs that are considered exceptionally difficult to understand and

repair. There are several kinds, mostly named after scientists who discovered counterintuitive things.

Bohrbug

A bohrbug (named after the Bohr atom model) is a bug that manifests itself consistently under a well-defined (but

possibly unknown) set of conditions. Thus, in contrast with heisenbugs, a bohrbug does not disappear or alter its

characteristics when it is researched. These include the easiest bugs to fix (where the nature of the problem is

obvious), but also bugs that are hard to find and fix and remain in the software during the operational phase.

Sometimes an error might occur only when a unique data set is entered, or unique circumstances are encountered.

These kinds of bugs are often present in parts of source code that are not invoked very often and thus might remain

undetected for an extended period of time, and are sometimes termed a ghost in the code.

For example, an overflow bug in a by-the-book binary search algorithm may exhibit itself only when the data array

under search is very large and the item to be searched for is located near the end of the array. Because programmers

tend to test their work using small arrays of data, and only recently have there existed machines with enough

memory to hold a sufficiently large array, such a bug may go undetected for many years.[1]

Mandelbug

A mandelbug (named after fractal innovator Benoît Mandelbrot) is a computer bug whose causes are so complex

that its behavior appears chaotic or even non-deterministic.[2]

This word also implies that the speaker thinks it is a

bohrbug rather than a heisenbug.

Some use mandelbug to describe a bug whose behavior does not appear chaotic, but whose causes are so complex

that there is no practical solution. An example of this is a bug caused by a flaw in the fundamental design of theentire system.

In the literature, there are inconsistent statements about the relationships between bohrbug, heisenbug, and

mandelbug: According to the above definition, mandelbugs are bohrbugs. Heisenbug and bohrbug are considered

antonyms. Moreover, it is claimed that all heisenbugs are mandelbugs.[3]

In a column in IEEE Computer,[4]

 mandelbug is considered the complementary antonym to bohrbug; i.e., a software

bug is either a bohrbug or a mandelbug. The apparently complex behavior of a mandelbug is assumed to be caused

either by long delays between fault activation and the failure occurrence, or by influences of other software system

elements (hardware, operating system, other applications) on the fault's behavior. Heisenbugs (whose behavior is

influenced by a debugger, or other means of investigating the fault) are mandelbugs.

Heisenbug

A heisenbug (named after the Heisenberg Uncertainty Principle) is a computer bug that disappears or alters its

characteristics when an attempt is made to study it.

One common example is a bug that occurs in a program that was compiled with an optimizing compiler, but not in

the same program when compiled without optimization (e.g., for generating a debug-mode version). Another

example is a bug caused by a race condition. A heisenbug may also appear in a system that does not conform to the

command-query separation design guideline, since a routine called more than once could return different values each

time, generating hard-to-reproduce bugs in a race condition scenario.

The name heisenbug is a pun on the Heisenberg uncertainty principle, a quantum physics concept which is

commonly (yet inaccurately) used to refer to the fact that in the Copenhagen Interpretation model of quantum

8/8/2019 Unusual Software Bug

http://slidepdf.com/reader/full/unusual-software-bug 2/5

Unusual software bug 2

mechanical behaviour, observers affect what they are observing, by the mere act of observing it alone (this is

actually the observer effect, and is commonly confused with the Heisenberg uncertainty principle).

One common reason for heisenbug-like behaviour is that executing a program in debug mode often cleans memory

before the program starts, and forces variables onto stack locations, instead of keeping them in registers. These

differences in execution can alter the effect of bugs involving out-of-bounds member access, incorrect assumptions

about the initial contents of memory, or floating-point comparisons (for instance, when a floating-point variable in a32-bit stack location is compared to one in an 80-bit register). Another reason is that debuggers commonly provide

watches or other user interfaces that cause additional code (such as property accessors) to be executed, which can, in

turn, change the state of the program. Yet another reason is a fandango on core, the effect of a pointer running out of 

bounds. In C++, many heisenbugs are caused by uninitialized variables.

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 an interview Bruce Lindsay tells of being there when the term was first used, and that it was created because

Heisenberg said, "The more closely you look at one thing, the less closely can you see something else."[5]

This claim of origin is almost certainly wrong, as the term has been used for over two decades. For example, the

earliest Google-archived mention is from the mailing list (later Usenet news group) comp.risks, moderated by Peter

G. Neumann. In RISKS Digest Volume 4 : Issue 34, dated 23 December 1986,[6]

Zhahai Stewart contributes an item

titled "Another heisenbug" noting that many such contributions have appeared in recent issues of RISKS Digest. The

term, and especially the distinction Heisenbug/Bohrbug, was already mentioned in 1985 by Jim Gray in an often

cited paper about software failures.[7]

SchrödinbugA schrödinbug is a bug that manifests only after someone reading source code or using the program in an unusual

way notices that it never should have worked in the first place, at which point the program promptly stops working

for everybody until fixed. The Jargon File[8]

adds: "Though... this sounds impossible, it happens; some programs

have harbored latent schrödinbugs for years."

The name schrödinbug was introduced in the version 2.9.9 of the Jargon file, published in April 1992. It is derived

from the Schrödinger's cat thought experiment. A well-written program executing in a reliable computing

environment is expected to follow the principle of determinism, and that being so the quantum questions of 

observability (i.e., breaking the program by reading the source code) posited by Schrödinger (i.e., killing the cat by

opening the box) affecting the operation of a program is unexpected.

Repairing an obviously defective piece of code is often more important than determining what arcane set of 

circumstances caused it to work at all (or appear to work) in the first place, and why it then stopped. Because of this,

many of these bugs are never fully understood. When bugs of this type are examined in enough detail, they can

usually be reclassified as a bohrbug, heisenbug, or mandelbug.

8/8/2019 Unusual Software Bug

http://slidepdf.com/reader/full/unusual-software-bug 3/5

Unusual software bug 3

Phase of the Moon bug

The phase of the moon is sometimes spouted as a silly parameter on which a bug might depend, such as when

exasperated after trying to isolate the true cause. The Jargon File documents two rare instances in which data

processing problems were actually caused by phase-of-the-moon timing.[9]

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 day, month, year, or century boundary (as with the Year 2000 bug).

Statistical bug

Statistical bugs can only be detected in aggregates and not in single runs of a section of code. These are bugs that

usually affect code that is supposed to produce random or pseudo-random output. An example is code to generate

points uniformly distributed on the surface of a sphere, say, and the result is that there are significantly more points

in the northern hemisphere than the southern one. Tracing in detail through a single run of the point generator can

completely fail to shed light on the location of such a bug because it is impossible to identify the output of any one

run as wrong – 

after all, it's intended to be random. Only when many points are generated does the problem becomeapparent. Popular debugging techniques such as checking pre- and postconditions can do little to help. Similar

problems can also occur in numerical algorithms in which each individual operation is accurate to within a given

tolerance but where numerical errors accumulate only after a large number of runs, especially if the errors have a

systematic bias. A simple example of this is the strfry() function in the GNU C Library.[10]

Noob bug (or Noobug)

Noob bugs are commonly mistaken for any of  the above. On further inspection, generally by a more advanced

computer scientist, they typically turn out to be something fairly obvious albeit easily overlooked by the untrained

(or noob) eye. An example of a noob bug is multiple inclusions (or even multiple copies) of the same file, or any

other similarly incorrect practice (multiple variables with the same name, failing to recompile between program runs,

failing to source/setup an environment correctly etc.). Whilst this leads to unexpected behaviour from the point of 

view of the principal designer, the underlying problem is well understood and therefore classified more generally as

noob.

See also

• Cargo cult programming

• CHESS, a tool for detecting and reproducing Heisenbugs (Windows)

• Memory debugger

• Jinx, a tool that automatically explore executions likely to expose heisenbugs.

References

[1] Joshua Block, "Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken" (http://googleresearch.  blogspot.

com/2006/06/extra-extra-read-all-about-it-nearly.html). Official Google Research Blog, June 2, 2006.

[2] The Jargon File - mandelbug (http://catb. org/jargon/html/M/mandelbug.  html)

[3] [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: M. Grottke and K. S. Trivedi, Software Faults, Software Aging and

Software Rejuvenation. Journal of the Reliability Engineering Association of Japan, Vol. 27, No. 7, pp. 425-438, 2005.]

[4] IEEE Computer vol. 40, no. 2 - February 2007 (http://www. computer.  org/portal/site/computer/menuitem.

5d61c1d591162e4b0ef1bd108bcd45f3/index.   jsp?&pName=computer_level1_article&TheCat=1065&path=computer/homepage/Feb07&

file=softwaretech. xml&xsl=article.xsl)

[5] ACM Queue vol. 2, no. 8 - November 2004 (http://acmqueue.com/modules. php?name=Content&pa=showpage&pid=233&page=5)

8/8/2019 Unusual Software Bug

http://slidepdf.com/reader/full/unusual-software-bug 4/5

Unusual software bug 4

[6] Risks-List on Google Groups RISKS DIGEST 4.34 (http://groups. google.  com/group/mod.  risks/browse_thread/thread/ 

83a6ad844eda93e0/5e061e6da0c2dbfc?lnk=st&q=heisenbug&rnum=896#5e061e6da0c2dbfc)

[7] "Why Do Computers Stop And What Can Be Done About It?" (http://citeseer.ist.psu. edu/gray85why.  html). 1985. .

[8] http://www. catb.  org/jargon/html/S/schroedinbug.html

[9] CATB.org, "phase of the moon" (http://www.catb.org/jargon/html/P/phase-of-the-moon. html)

[10] strfry() gives skewed distributions (http://sourceware.org/bugzilla/show_bug. cgi?id=4403)

External links

• The Jargon File has entries on heisenbug (http://www.catb. org/jargon/html/H/heisenbug.html), Bohr bug

(http://www.  catb. org/jargon/html/B/Bohr-bug.  html), mandelbug (http://www.  catb. org/jargon/html/M/ 

mandelbug. html) and schroedinbug (http://www.  catb.org/jargon/html/S/schroedinbug.  html), and phase of 

the moon (http://www.  catb. org/jargon/html/P/phase-of-the-moon.  html)

• The Heisenberg Debugging Technology (http://sourceware. org/gdb/talks/esc-west-1999/)

• Testing parallel programs (http://multicore. ning.com/profiles/blogs/testing-parallel-programs)

This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed 

under the GFDL.

8/8/2019 Unusual Software Bug

http://slidepdf.com/reader/full/unusual-software-bug 5/5

Article Sources and Contributors 5

Article Sources and ContributorsUnusual software bug  Source: http://en.wikipedia.org/w/index.php?oldid=399570029 Contributors: 5 albert square, Aaronbrick, Abu badali, Aeolian145, Ahaig, Ais523, AliveFreeHappy,

Alksub, Andiiiiiiiiii, AndreaPersephone, Andreas Kaufmann, Antonielly, Apankrat, Asmeurer, Balabiot, Barrymyles, Beland, Bevo, Bfg, Boing! said Zebedee, Booyabazooka, Branger, Bryan

Derksen, Bumbulski, Canadian Monkey, Cavac, Chrismacgr, Cosini Zeno, Cybercobra, Czambra, Dannythorpe, Dar7yl, Darekun, David R. Ingham, DenisHowe, Eaglizard, Eastlaw, Erkan

Yilmaz, Esrob, Eyu100, Furrykef, Fuzlogic, Gnp, Hairy Dude, Happygiraffe, HarmonicFeather, Hbf, Holme053, Hooperbloob, Hope.forever.ends, Jdiemer, Jmlptzlp, Joeblakesley, Kaagle,

Keenan Pepper, Ketiltrout, LinguistAtLarge, Lionel Elie Mamane, Mckaysalisbury, Michael Hardy, Mortenj1638, MrH, Murray Langton, NJGW, Nataxia, OranL, Ospalh, PhilKnight, Pichpich,

Pinecar, Pinkadelica, Prgrmr@wrk, Pseudomonas, Ptrb, Rhebus, RobinHood70, Segv11, SethTisue, Sigfpe, Sintaku, Spyforthemoon, Steven Weston, Tedder, Thumperward, Tigrisek, Timwi,

Trivialist, Uucp, Walter Görlitz, Wizard191, 93 anonymous edits

License

Creative Commons Attribution-Share Alike 3.0 Unportedhttp://creativecommons.org/licenses/by-sa/3.0/