Caiwangqin's blog: Unusual software bug

Unusual software bug

2007年5月8日星期二

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.

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. Many Heisenbugs are caused by uninitialized variables. Once you have identified the problem as a Heisenbug, it is usually easy and trivial to find the error and fix it.

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]

Bohrbug

A Bohr bug or Bohrbug (named after the Bohr atom model) is a bug that, in contrast with heisenbugs, 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. They may never be fixed, but if the operation is retried or the system is rebooted, the bugs may not manifest themselves as failures. Manifestation is dependent on the software reaching very rare states.

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.

It can be argued, according to same principle as the Turing test, that if there is no way for a judge to differentiate between a bug whose behavior appears chaotic and a bug whose behavior actually is chaotic, then there is no relevance in the distinction between mandelbug and heisenbug, since there is no way to tell them apart.

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 .

Schroedinbugs

A Schroedinbug is a bug that manifests itself apparently only after the software is used in an unusual way or seemingly at the point in time that a programmer reading the source code notices that the program should never have worked in the first place, at which point the program stops working entirely until the mysteriously now non-functioning code is repaired. FOLDOC, in a statement of apparent jest, adds: “Though… this sounds impossible, it happens; some programs have harboured 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. However, quickly repairing an obviously defective piece of code is often more important than attempting to determine by what arcane set of circumstances it accidentally worked in the first place or exactly why it stopped. By declaring that the code could never have worked in the first place despite evidence to the contrary, the complexity of the computing system is causing the programmer to fall back on superstition.

For example, a database program may have initially worked on a small number of records, including test data used during development, but broke once the amount of data reached a certain limit, without this cause being at all intuitive. A programmer without knowing the cause, and who didn’t bother to consider the normal uptick in the database size as a factor in the breakage, could label the defect a schroedinbug.

Phase of the moon 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.^[2]

In general, programs which 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).