Tuesday, November 6, 2007

A software bug (or "bug") is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy. Reports detailing bugs in a program are commonly known as bug reports, fault reports, problem reports, trouble reports, change requests, and so forth.
Bugs can have a wide variety of effects, with varying levels of inconvenience to the user of the program. Some bugs have only a subtle effect on the program's functionality, and may thus lie undetected for a long time. More serious bugs may cause the program to crash or freeze leading to a denial of service. Others qualify as security bugs and might for example enable a malicious user to bypass access controls in order to obtain unauthorized privileges.
The results of bugs may be extremely serious. A bug in the code controlling the Therac-25 radiation therapy machine was directly responsible for some patient deaths in the 1980s. In 1996, the European Space Agency's US$1 billion prototype Ariane 5 rocket was destroyed less than a minute after launch, due to a bug in the on-board guidance computer program. In June 1994, a Royal Air Force Chinook crashed into the Mull of Kintyre, killing 29. This was initially dismissed as pilot error, but an investigation by Computer Weekly uncovered sufficient evidence to convince a House of Lords inquiry that it may have been caused by a software bug in the aircraft's FADEC. [2] [3]

Bugs are a consequence of the nature of the programming task. Some bugs arise from simple oversights made when computer programmers write source code carelessly or transcribe data incorrectly. Many off-by-one errors fall into this category. Other bugs arise from unintended interactions between different parts of a computer program. This happens because computer programs are often complex, often having been programmed by several different people over a great length of time, so that programmers are unable to mentally keep track of every possible way in which different parts can interact. Many race condition bugs fall into this category.
The computer software industry has put a great deal of effort into finding methods for preventing programmers from inadvertently introducing bugs while writing software. These include:
Bugs are often created by typos that are not caught by the compiler. Various innovations in programming style and defensive programming are designed to make these bugs less likely, or easier to spot.
Bugs often create inconsistencies in the internal data of a running program. Programs can be written to check the consistency of their own internal data while running. If an inconsistency is encountered, the program can immediately halt, so that the bug can be located and fixed. Alternatively, the program can simply inform the user, attempt to correct the inconsistency, and continue running.
There are several schemes for managing programmer activity, so that fewer bugs are produced. Many of these fall under the discipline of software engineering (which addresses software design issues as well.) For example, formal program specifications are used to state the exact behavior of programs, so that design bugs can be eliminated.
Programming languages often include features which help programmers deal with bugs, such as exception handling. In addition, many recently-invented languages have deliberately excluded features which can easily lead to bugs. For example, the Java programming language does not support pointer arithmetic.


Main article: Debugging Debugging
It is common practice for software to be released with known bugs that are considered non-critical. While software products contain an unknown number of unknown bugs when shipped, measurements during the testing may provide a statistically reliable estimate of the number of likely bugs remaining. Most big software projects maintain a list of "known bugs". This list inform users about bugs that are not fixed in the current release, or not fixed at all, and often a workaround is offered additionally.
There are various reasons for such a list:
Given the above, it is often considered impossible to write completely bug-free software of any real complexity. So bugs are categorized by severity, and low-severity non-critical bugs are tolerated, as they do not impact the proper operation of the system, for the majority of users. NASA's SATC managed to reduce number of errors to fewer than 0.1 per 1000 lines of code (SLOC) but this was not felt to be feasible for any real world projects.
One school of thought, popularized by Eric S. Raymond as Linus's Law, holds that popular open-source software holds a better chance of being bug-free than other software, because "given enough eyeballs, all bugs are shallow". This assertion has been disputed, however.

The developers often don't have time to fix all non-severe bugs.
The bug could be fixed in a new version or patch that is not yet released.
The changes to the code required to fix the bug would be large, and would bring with them the chance of introducing other bugs into the system. Managing bugs

Famous computer bugs

NASA Mariner 1 went off-course during launch, due to a missing 'bar' in its FORTRAN software (July 22, 1962).[7]
NASA Apollo 11 landing problem (July 20, 1969).
NASA Voyager 2 (January 25, 1986).
Phobos 1 lost (September 10, 1988).
ESA Ariane 5 Flight 501 self-destruction 40 seconds after takeoff (June 4, 1996).
NASA Mars Climate Orbiter destroyed due to entry of momentum data in imperial units instead of the metric system (September 23, 1999).
Mars Polar Lander lost (December 3, 1999).
NASA Mars Rover freezes due to too many open files in flash memory (January 21, 2004).
NASA Mars Global Surveyor battery failure was the result of a series of events linked to a computer error made five months before (November 2, 2006).[8] Space exploration

The Therac-25 accidents (1985-1987), which caused at least five deaths.
A misuse of medical diagnosis software created by Multidata Systems International, at the National Cancer Society in Panama City, caused, by different estimates, between five and eight cancer patients to die of over-radiation. (2000) Medical

The year 2000 problem, popularly known as the "Y2K bug", spawned fears of worldwide economic collapse and an industry of consultants providing last-minute fixes.
The Pentium FDIV bug. Computing

The 2003 North America blackout was triggered by a local outage that went undetected due to a race condition in General Electric Energy's XA/21 monitoring software. Electric power transmission

AT&T long distance network crash (January 15, 1990), documented in Bruce Sterling's The Hacker Crackdown. Telecommunications

The software error of a MIM-104 Patriot, which ultimately contributed to the deaths of 28 Americans in Dhahran, Saudi Arabia (February 25, 1991).
Chinook crash on Mull of Kintyre: the cause of this event remains a mystery, but strong suspicions have been raised that software problems were a contributory factor. Military

The Missingno. and Glitch City bugs, found in the Pokémon series
The Minus World in NES version of Super Mario Brothers Video games
Malicious software may attempt to exploit known vulnerabilities in a system - which may or may not be bugs. Viruses are not bugs in themselves - they are typically programs that are doing precisely what they were designed to do. However, viruses are occasionally referred to as such in the popular press.

Software bug Security vulnerabilities

Divide by zero
NULL pointer dereference
Infinite loops
Arithmetic overflow or underflow
Exceeding array bounds
Using an uninitialized variable
Accessing memory not owned (Access violation)
Memory leak or Handle leak
Stack overflow or underflow
Buffer overflow
Off by one error
Race condition
Loss of precision in type conversion See also

No comments: