Software bug: Difference between revisions

Revision as of 01:37, 20 November 2024

Revision as of 04:12, 25 November 2024

Line 116:

Some languages include features that add runtime overhead in order to prevent some bugs. For example, many languages include runtime [[bounds checking]] and a way to handle out-of-bounds conditions instead of crashing.

A [[compiler|compiled]] language allows for detecting some typos (such as a misspelled identifier) before [[Runtime (program lifecycle phase)|runtime]] which is earlier in the [[software development process]] than for an [[Interpreter (computing)|interpreted]] language.

=== Techniques ===

Line 154:

[[Agile software development]] may involve frequent software releases with relatively small changes. Defects are revealed by user feedback.

With [[test-driven development]] (TDD), [[Unit testing|unit teststest]]s are written while writing the production code, and the production code is not considered complete until all tests complete successfully.

=== Static analysis ===

Line 184:

Some contend that locating a bug is something of an art.

It is not uncommon for a bug in one section of a program to cause failures in a different section,{{citation needed|date=November 2012}} thus making it difficult to track, in an apparently unrelated part of the system. For example, an error in a graphics [[Rendering (computer graphics)|rendering]] routine causing a file [[Input/output|I/O]] routine to fail.

Sometimes, the most difficult part of debugging is finding the cause of the bug. Once found, correcting the problem is sometimes easy if not trivial.

Line 194:

Typically, the first step in locating a bug is to reproduce it reliably. If unable to reproduce the issue, a programmer cannot find the cause of the bug and therefore cannot fix it.

Some bugs are revealed by inputs that may be difficult for the programmer to re-create. One cause of the [[Therac-25]] radiation machine deaths was a bug (specifically, a [[race condition]]) that occurred only when the machine operator very rapidly entered a treatment plan; it took days of practice to become able to do this, so the bug did not manifest in testing or when the manufacturer attempted to duplicate it. Other bugs may stop occurring whenever the setup is augmented to help find the bug, such as running the program with a debugger; these are called ''[[heisenbug]]s'' (humorously named after the [[uncertainty principle|Heisenberg uncertainty principle]]).

Since the 1990s, particularly following the [[Ariane 5 Flight 501]] disaster, interest in automated aids to debugging rose, such as [[static code analysis]] by [[abstract interpretation]].<ref>{{Cite web|url=http://christele.faure.pagesperso-orange.fr/polyspace.html|title=PolySpace Technologies history|website=christele.faure.pagesperso-orange.fr|access-date=August 1, 2019}}</ref>

Line 302:

|publisher=[[IEEE]]

|doi=10.1109/ASE.2017.8115662}}</ref>

Such a bug can be from a lack of awareness of the qualities of the data storage such as a [[arithmetic precision|loss of precision]] due to [[rounding]], [[numerical stability|numerically unstable]] algorithms, [[arithmetic overflow]] and [[Arithmetic underflow|underflow]], or from lack of awareness of how calculations are handled by different software coding languages such as [[Division by zero#Computer arithmetic|division by zero]] which in some languages may throw an exception, and in others may return a special value such as [[NaN]] or [[Infinity#Computing|infinity]].

=== Control flow ===

Line 339:

=== Teamwork ===

* Unpropagated updates; e.g. programmer changes "myAdd" but forgets to change "mySubtract", which uses the same algorithm. These errors are mitigated by the [[Don't repeat yourself|Don't Repeat Yourself]] philosophy.

* Comments out of date or incorrect: many programmers assume the comments accurately describe the code.

* Differences between documentation and product.

Line 354:

* In both the 1968 novel ''[[2001: A Space Odyssey (novel)|2001: A Space Odyssey]]'' and the corresponding [[2001: A Space Odyssey|film of the same name]], the spaceship's onboard computer, [[HAL 9000]], attempts to kill all its crew members. In the follow-up 1982 novel, ''[[2010: Odyssey Two]]'', and the accompanying 1984 film, [[2010: The Year We Make Contact|''2010: The Year We Make Contact'']], it is revealed that this action was caused by the computer having been programmed with two conflicting objectives: to fully disclose all its information, and to keep the true purpose of the flight secret from the crew; this conflict caused HAL to become paranoid and eventually homicidal.

* In the English version of the Nena 1983 song ''[[99 Luftballons]]'' (99 Red Balloons) as a result of "bugs in the software", a release of a group of 99 red balloons are mistaken for an enemy nuclear missile launch, requiring an equivalent launch response and resulting in catastrophe.

* In the 1999 American comedy ''[[Office Space]]'', three employees attempt (unsuccessfully) to exploit their company's preoccupation with the Y2K computer bug using a computer virus that sends rounded-off fractions of a penny to their bank account—a long-known technique described as [[Salami slicing tactics|salami slicing]].

* The 2004 novel ''The Bug'', by [[Ellen Ullman]], is about a programmer's attempt to find an elusive bug in a database application.<ref>{{cite book | last=Ullman | first=Ellen | date=2004 | title=The Bug | publisher=[[Picador (imprint)|Picador]] | isbn=978-1-250-00249-5 }}</ref>

* The 2008 Canadian film ''[[Control Alt Delete (film)|Control Alt Delete]]'' is about a computer programmer at the end of 1999 struggling to fix bugs at his company related to the year 2000 problem.