Heisenbugs
A heisenbug is a computer bug that disappears or alters its characteristics when it is researched.
One common example is a bug that occurs in a release-mode compile of a program, but not when researched under debug-mode; another is a bug caused by a race condition. The name "heisenbug" is a pun on the "Heisenberg uncertainty principle," a quantum physics
term which is commonly (yet inaccurately) used to refer to the way in
which observers affect the measurements of the things that they are
observing, by the act of observing 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. Another reason is that debuggers commonly provide watches
or other user interfaces that cause 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.
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."[1]
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[2],
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 (http://citeseer.ist.psu.edu/gray85why.html).
Bohrbug
A Bohr bug or bohrbug (named after the Bohr atom model)
is a bug that manifests reliably 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.
Mandelbugs
A mandelbug (named after fractal innovator Benoît Mandelbrot) is a computer bug whose causes are so complex that its behavior appears chaotic. 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 the entire 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.
In a recent column in IEEE Computer [3], 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.
Schroedinbugs
A schroedinbug 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 adds: "Though... this sounds impossible, it happens; some programs have harbored latent schroedinbugs for years."
The name schroedinbug 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 as such 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) cannot actually affect the
operation of a program.
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.
Stotle
A Stotle refers to the incorrect output of a computer program that contains no bug. Named after the famous Greek philosopher Aristotle,
a "Stotle" occurs when some assumed-to-be-correct incorrect input
produces incorrect output. Although this is not a bug in the program
itself, it is a common occurrence in computer science. It was named
after Aristotle because the programmer assumes that the program is at
fault when programming complex algorithms before examining the input.
Many people assumed Aristotle was correct and questioned his
assumptions only after many discontinuities were found.
Phase of the moon bugs
- See also: Time formatting and storage bugs
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.[4]
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 bugs
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 become apparent. 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.
Ghost in the code
A ghost in the code refers to a software bug that is not
identified during normal course of testing. An error might occur only
when a unique data set is entered, or unique circumstances are
encountered. This makes its creators feel like a being with a mind of
its own is controlling or possessing their program (the "ghost"). Once this kind of software bug is identified, it is often difficult for programmers to locate and fix, e.g. "chasing a ghost". 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.
