Content deleted Content added
m Reverted edits by 24.44.45.129 (talk): unexplained content removal (HG) (3.4.11) Tags: Rollback Disambiguation links added |
Atomixfart (talk | contribs) m I was trying to save in my archives |
||
| (41 intermediate revisions by 35 users not shown) | |||
Line 1:
{{Short description|
{{Redirect|Debug}}
{{Software development process|Core activities}}
In [[
==Etymology==
{{seealso|
[[File:First Computer Bug, 1945.jpg|thumb|A computer log entry from the Mark II, with a moth taped to the page]]
The term ''bug'', in the sense of defect, dates back at least to 1878 when [[Thomas Edison]] wrote "little faults and difficulties" in his inventions as "Bugs".
The terms "bug" and "debugging" are popularly attributed to [[Admiral Grace Hopper]] in the 1940s.<ref>{{Cite web |url=https://books.google.com/books?id=JT0EAAAAMBAJ&pg=RA1-PA33 |title=InfoWorld Oct 5, 1981 |date=5 October 1981 |access-date=July 17, 2019 |archive-date=September 18, 2019 |archive-url=https://web.archive.org/web/20190918012636/https://books.google.com/books?id=JT0EAAAAMBAJ&pg=RA1-PA33&lpg=RA1-PA33&focus=viewport |url-status=live }}</ref> While she was working on a [[Harvard Mark II|Mark II]] computer at Harvard University, her associates discovered a moth stuck in a relay and thereby impeding operation, whereupon she remarked that they were "debugging" the system. However, the term "bug", in the sense of "technical error", dates back at least to 1878 and [[Thomas Edison]] who describes the "little faults and difficulties" of mechanical engineering as "Bugs".▼
▲
Similarly, the term "debugging" seems to have been used as a term in aeronautics before entering the world of computers. In an interview Grace Hopper remarked that she was not coining the term.{{Citation needed|date=July 2015}} The moth fit the already existing terminology, so it was saved. A letter from [[J. Robert Oppenheimer]] (director of the WWII atomic bomb [[Manhattan Project]] at Los Alamos, New Mexico) used the term in a letter to Dr. [[Ernest Lawrence]] at UC Berkeley, dated October 27, 1944,<ref>{{Cite web |url=https://bancroft.berkeley.edu/Exhibits/physics/images/bigscience25.jpg |title=Archived copy |access-date=2019-12-17 |archive-date=2019-11-21 |archive-url=https://web.archive.org/web/20191121001830/https://bancroft.berkeley.edu/Exhibits/physics/images/bigscience25.jpg |url-status=live }}</ref> regarding the recruitment of additional technical staff.▼
▲Similarly, the term
The [[Oxford English Dictionary]] entry for
The seminal article by Gill<ref>S. Gill, [https://www.jstor.org/stable/98663 The Diagnosis of Mistakes in Programmes on the EDSAC] {{Webarchive|url=https://web.archive.org/web/20200306083748/https://www.jstor.org/stable/98663 |date=2020-03-06 }}, Proceedings of the Royal Society of London. Series A, Mathematical and Physical Sciences, Vol. 206, No. 1087 (May 22, 1951), pp. 538-554</ref> in 1951 is the earliest in-depth discussion of programming errors, but it does not use the term "bug" or "debugging".▼
An article in "Airforce" (June 1945 p. 50) refers to ''debugging'' aircraft cameras.
In the [[Association for Computing Machinery|ACM]]'s digital library, the term "debugging" is first used in three papers from 1952 ACM National Meetings.<ref>Robert V. D. Campbell, [https://dl.acm.org/citation.cfm?id=609784.609786 Evolution of automatic computation] {{Webarchive|url=https://web.archive.org/web/20190918012641/https://dl.acm.org/citation.cfm?id=609784.609786 |date=2019-09-18 }}, Proceedings of the 1952 ACM national meeting (Pittsburgh), p 29-32, 1952.</ref><ref>Alex Orden, [https://dl.acm.org/citation.cfm?id=609784.609793 Solution of systems of linear inequalities on a digital computer], Proceedings of the 1952 ACM national meeting (Pittsburgh), p. 91-95, 1952.</ref><ref>Howard B. Demuth, John B. Jackson, Edmund Klein, N. Metropolis, Walter Orvedahl, James H. Richardson, [https://dl.acm.org/citation.cfm?id=808982 MANIAC] doi=10.1145/800259.808982, Proceedings of the 1952 ACM national meeting (Toronto), p. 13-16</ref> Two of the three use the term in quotation marks.▼
By 1963 "debugging" was a common-enough term to be mentioned in passing without explanation on page 1 of the [[Compatible Time-Sharing System|CTSS]] manual.<ref>[http://www.bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf The Compatible Time-Sharing System] {{Webarchive|url=https://web.archive.org/web/20120527174321/http://www.bitsavers.org/pdf/mit/ctss/CTSS_ProgrammersGuide.pdf |date=2012-05-27 }}, M.I.T. Press, 1963</ref>▼
▲The seminal article by Gill<ref>S. Gill, [https://www.jstor.org/stable/98663 The Diagnosis of Mistakes in Programmes on the EDSAC] {{Webarchive|url=https://web.archive.org/web/20200306083748/https://www.jstor.org/stable/98663 |date=2020-03-06 }}, Proceedings of the Royal Society of London. Series A, Mathematical and Physical Sciences, Vol. 206, No. 1087 (May 22, 1951), pp. 538-554</ref> in 1951 is the earliest in-depth discussion of programming errors, but it does not use the term
▲In the [[Association for Computing Machinery|ACM]]'s digital library, the term
▲By 1963,
==Scope==
Line 38 ⟶ 43:
==Debugging process==
The debugging process normally begins with identifying the steps to reproduce the problem. This can be a non-trivial task, particularly with
After the bug is reproduced, the input of the program may need to be simplified to make it easier to debug. For example, a bug in a compiler can make it [[Crash (computing)|crash]] when parsing a large source file. However, after simplification of the test case, only few lines from the original source file can be sufficient to reproduce the same crash. Simplification may be done manually using a [[Divide-and-conquer algorithm|divide-and-conquer]] approach, in which the programmer attempts to remove some parts of original test case then checks if the problem still occurs. When debugging in a [[Graphical user interface|GUI]], the programmer can try skipping some user interaction from the original problem description to check if the remaining actions are sufficient for causing the bug to occur.
Line 45 ⟶ 50:
==Techniques==
* ''Interactive debugging'' uses debugger tools which allow
* ''{{visible anchor|Print debugging}}'' or ''[[Tracing (software)|tracing]]'' is the act of watching (live or recorded) trace statements, or print statements, that indicate the flow of execution of a process and the data progression. Tracing can be done with specialized tools (like with GDB's trace) or by insertion of trace statements into the source code. The latter is sometimes called ''{{visible anchor|printf debugging}}'', due to the use of the [[printf]] function in C. This kind of debugging was turned on by the command TRON in the original versions of the novice-oriented [[BASIC]] programming language. TRON stood for, "Trace On." TRON caused the line numbers of each BASIC command line to print as the program ran.
* ''Activity tracing'' is like tracing (above), but rather than following program execution one instruction or function at a time, follows program activity based on the overall amount of time spent by the processor/CPU executing particular segments of code. This is typically presented as a fraction of the program's execution time spent processing instructions within defined memory addresses (machine code programs) or certain program modules (high level language or compiled programs). If the program being debugged is shown to be spending an inordinate fraction of its execution time within traced areas, this could indicate misallocation of processor time caused by faulty program logic, or at least inefficient allocation of processor time that could benefit from optimization efforts.
* ''{{visible anchor|Remote debugging}}'' is the process of debugging a program running on a system different from the debugger. To start remote debugging, a debugger connects to a remote system over a communications link such as a local area network. The debugger can then control the execution of the program on the remote system and retrieve information about its state.
* ''Post-mortem debugging'' is debugging of the program after it has already [[crash (computing)|crashed]]. Related techniques often include various tracing techniques like examining log files, outputting a [[call stack]] on the crash,<ref>{{cite web|url=https://www.drdobbs.com/tools/postmortem-debugging/185300443|title=Postmortem Debugging|work=Dr. Dobb's |access-date=2019-12-17|archive-date=2019-12-17|archive-url=https://web.archive.org/web/20191217045909/https://www.drdobbs.com/tools/postmortem-debugging/185300443|url-status=live}}</ref> and analysis of [[memory dump]] (or [[core dump]]) of the crashed process. The dump of the process could be obtained automatically by the system (for example, when the process has terminated due to an unhandled exception), or by a programmer-inserted instruction, or manually by the interactive user.
* ''"Wolf fence" algorithm:'' Edward Gauss described this simple but very useful and now famous algorithm in a 1982 article for [[Communications of the ACM]] as follows: "There's one wolf in Alaska; how do you find it? First build a fence down the middle of the state, wait for the wolf to howl, determine which side of the fence it is on. Repeat process on that side only, until you get to the point where you can see the wolf."<ref>{{cite journal
* ''[[Record and replay debugging]]'' is the technique of creating a program execution recording (e.g. using Mozilla's free [[rr (debugging)|rr]] debugging tool; enabling reversible debugging/execution), which can be replayed and interactively debugged. Useful for remote debugging and debugging intermittent, non-
* ''[[Time travel debugging]]'' is the process of stepping back in time through source code (e.g. using [[Undo (company)|Undo LiveRecorder]]) to understand what is happening during execution of a computer program; to allow users to interact with the program; to change the history if desired and to watch how the program responds.
* ''[[Delta
* ''Saff Squeeze''{{snd}} a technique of isolating failure within the test using progressive inlining of parts of the failing test.<ref>{{cite web|url=http://www.threeriversinstitute.org/HitEmHighHitEmLow.html|archive-url=https://web.archive.org/web/20120311131729/http://www.threeriversinstitute.org/HitEmHighHitEmLow.html|url-status=dead|archive-date=2012-03-11|title=Kent Beck, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze}}</ref><ref>{{cite web |last1=Rainsberger |first1=J.B. |title=The Saff Squeeze |url=https://blog.thecodewhisperer.com/permalink/the-saff-squeeze |website=The Code Whisperer |date=28 March 2022 |access-date=28 March 2022}}</ref>
* ''Causality tracking'': There are techniques to track the cause effect chains in the computation.<ref>{{cite journal|last=Zeller|first=Andreas|date=2002-11-01|title=Isolating cause-effect chains from computer programs|journal=ACM SIGSOFT Software Engineering Notes|volume=27|issue=6|pages=1–10|doi=10.1145/605466.605468|s2cid=12098165|issn=0163-5948}}</ref> Those techniques can be tailored for specific bugs, such as null pointer dereferences.<ref name="BondNethercote2007">{{cite book |last1=Bond|first1=Michael D.|title=Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07|last2=Nethercote|first2=Nicholas|last3=Kent|first3=Stephen W.|last4=Guyer|first4=Samuel Z.|last5=McKinley|first5=Kathryn S.|chapter=Tracking bad apples|year=2007|pages=405|doi=10.1145/1297027.1297057|isbn=9781595937865|s2cid=2832749}}</ref>
{{excerpt|Automatic bug fixing}}
==Debugging for embedded systems==
In contrast to the general purpose computer software design environment, a primary characteristic of embedded environments is the sheer number of different platforms available to the developers (CPU architectures, vendors, operating systems, and their variants). Embedded systems are, by definition, not general-purpose designs: they are typically developed for a single task (or small range of tasks), and the platform is chosen specifically to optimize that application. Not only does this fact make life tough for embedded system developers, it also makes debugging and testing of these systems harder as well, since different debugging tools are needed for different platforms.
Despite the challenge of heterogeneity mentioned above, some debuggers have been developed commercially as well as research prototypes. Examples of commercial solutions come from [[Green Hills Software]],<ref>{{cite web|url=https://www.ghs.com/products/supertraceprobe.html|title=SuperTrace Probe hardware debugger|website=www.ghs.com|access-date=2017-11-25|archive-date=2017-12-01|archive-url=https://web.archive.org/web/20171201031136/https://www.ghs.com/products/supertraceprobe.html|url-status=live}}</ref> [[Lauterbach GmbH]]<ref>{{cite web|url=https://www.lauterbach.com|title=Debugger and real-time trace tools|website=www.lauterbach.com|access-date=2020-06-05|archive-date=2022-01-25|archive-url=https://web.archive.org/web/20220125072945/https://www.lauterbach.com/frames.html?home.html|url-status=live}}</ref> and Microchip's MPLAB-ICD (for in-circuit debugger). Two examples of research prototype tools are Aveksha<ref>{{cite
In addition to the typical task of identifying bugs in the system, embedded system debugging also seeks to collect information about the operating states of the system that may then be used to analyze the system: to find ways to boost its performance or to optimize other important characteristics (e.g. energy consumption, reliability, real-time response, etc.).
Line 73 ⟶ 81:
* Detecting and penalizing debugger<ref name="soft-prot"/>
An early example of anti-debugging existed in early versions of [[Microsoft Word]] which, if a debugger was detected, produced a message that said, "The tree of evil bears bitter fruit. Now trashing program disk.", after which it caused the floppy disk drive to emit alarming noises with the intent of scaring the user away from attempting it again.<ref name="SecurityEngineeringRA">{{cite book |url=https://archive.org/details/securityengineer00ande |url-access=registration |author=Ross J. Anderson |title=Security Engineering |isbn=0-471-38922-6 |page=684 |author-link=Ross J. Anderson |date=2001-03-23 |publisher=Wiley }}</ref><ref name="toastytech">{{cite web |url=http://toastytech.com/guis/word1153.html |title=Microsoft Word for DOS 1.15 |access-date=2013-06-22 |archive-date=2013-05-14 |archive-url=https://web.archive.org/web/20130514033750/http://toastytech.com/guis/word1153.html |url-status=live }}</ref>
==See also==
{{Div col|colwidth=20em}}
* [[Assertion (software development)]]
▲* [[Automatic bug fixing]]
* [[Debugging pattern]]
* [[Magic number (programming)#Magic debug values|Magic debug values]]
Line 109 ⟶ 116:
{{Wikibooks|Computer Programming Principles|Maintaining/Debugging|Debugging}}
* [http://www.dumpanalysis.org/ Crash dump analysis patterns]{{snd}} in-depth articles on analyzing and finding bugs in crash dumps
* [https://
* [http://www.clarinox.com/docs/whitepapers/EmbeddedDebugger.pdf Plug-in Based Debugging For Embedded Systems]
* [https://web.archive.org/web/20120112200659/http://www.byteparadigm.com/embedded-systems-test-and-debug---about-digital-input-generation-135.html Embedded Systems test and debug – about digital input generation]{{snd}} results of a survey about embedded system test and debug, Byte Paradigm (archived from the original on January 12, 2012)
| |||