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.

  • 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 the released version compile of a program, but not in 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 gu

  • Bohrbug

A Bohr bug or bohrbug (named after the Bohr atom model) is a bug that makes itself manifest 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.

  • Mandelbug

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.

  • Schroedinbug

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 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) cannot actually affect the operation of a program.

  • 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.

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 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.

  • Vorführeffekt

A Vorführeffekt (German for presentation/demonstration effect) is a common type of bug that is first discovered when the software is demonstrated to someone else. This type of bug is usually traced to insufficient test cases and/or use of synthetically generated test data. Many programmers test for all kind of unusual bugs but rely on experience and formal design methods to handle common cases.

An example of this kind of bug would be a program that asks for the user's name: the programmer always tests with his own name; when a potential customer enters his (longer) name, the program crashes.

While the programming bug itself is a "normal" bug in most of the cases, it may be classified as heisenbug, because the developer might not be able to identify the causes of the bug because of the insufficient testing procedures (e.g., the bug manifests only when other people use the software).

extraido de la wiki!

Comments

Popular posts from this blog

Como configurar el control de directv para que funcione con el Tv

Las Tutucas y todo lo demás

Python Ipdb Cheatsheet