Common types of computer bugs (5)
Why are there Bugs in Software?
(Continued from previous question...)
Common types of computer bugs (5)
Bit rot is a colloquial computing term used to facetiously describe the spontaneous degradation of a software program over time. The term implies that software can literally wear out or rust like a physical tool. Bit rot is also used to describe the discredited idea  that a computer's memory may occasionally be altered by cosmic rays. More commonly, bit rot refers to the decay of physical storage mediums.
When a program that has been running correctly for an extended time suddenly malfunctions for no apparent reason, programmers often jokingly attribute the failure to bit rot. Such an effect may be due to a memory leak or other nonobvious software bug. Many times, although there is no obvious change in the program's operating environment, a subtle difference has occurred that is triggering a latent software error.
Bit rot is often defined as the event in which the small electric charge of a bit in memory disperses, possibly altering program code.
Bit rot can also be used to describe the very real phenomenon of data stored in EPROMs gradually decaying over the duration of many years, or in the decay of data stored on CD or DVD disks or other types of consumer storage.
The cause of bit rot varies depending on the medium. Floppy disk and Magnetic Tape storage may experience bit rot as bits lose magnetic orientation. In CDs and DVDs the breakdown of the material onto which the data is stored may cause bit rot. This can be mitigated by storing disks in a dark, cool location with low humidity. Archival quality disks are also available. Old punch cards may experience a more literal form of bit rot, as the paper onto which the programs are stored begins to rot.
Rarely, bit rot is referred to as the process by which data becomes inaccessible due to the lack of working devices to read old data storage formats. (For example, a game stored on a Floppy Disk may be referred to as having succumbed to bit rot if the user no longer possesses a floppy disk drive to read the disk). See also: Link rot, Code rot
Unusual software bugs are more difficult to understand and repair than ordinary software bugs. There are several kinds, mostly named after scientists who discovered counterintuitive things.
A heisenbug is a computer bug that disappears or alters its characteristics when it is researched.
Common examples are bugs that occur in a release-mode compile of a program but do not occur when researched under debug-mode, or some bugs caused by a race condition. The name is a pun on the physics term "Heisenberg Uncertainty principle", which is popularly believed to refer to the way observers affect the observed in quantum mechanics.
In an interview in ACM Queue vol. 2, no. 8 - November 2004 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."
A Bohr bug (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.
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 Bohr bug 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.
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.
Appearance in Fiction
In the independent movie 'Schrödinger's Cat', a Schroedinbug is found in the programming of American defense systems, causing a catastrophic security failure.
(Continued on next question...)
Other Interview Questions