Content deleted Content added
Citation bot (talk | contribs) Removed URL that duplicated identifier. | Use this bot. Report bugs. | Suggested by Dominic3203 | Linked from User:LinguisticMystic/cs/outline | #UCB_webform_linked 494/2277 |
Atomixfart (talk | contribs) m I was trying to save in my archives |
||
| (5 intermediate revisions by 5 users not shown) | |||
Line 3:
{{Software development process|Core activities}}
In [[engineering]], '''debugging''' is the process of finding the [[Root cause analysis|root cause]], [[workaround]]s, and possible fixes for [[bug (engineering)|bugs]].
For [[software]], debugging tactics can involve [[interactive]] debugging, [[control flow]] analysis, [[Logfile|log file analysis]], monitoring at the [[application monitoring|application]] or [[system monitoring|system]] level, [[memory dump]]s, and [[profiling (computer programming)|profiling]]. Many [[Programming language|programming languages]] and [[Programming tool|software development tools]] also offer programs to aid in debugging, known as
==Etymology==
Line 15:
A popular story from the 1940s is from [[Admiral Grace Hopper]].<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 that impeded operation and wrote in a log book "First actual case of a bug being found". Although probably a [[word play|joke]], conflating the two meanings of bug (biological and defect), the story indicates that the term was used in the computer field at that time.
Similarly, the term ''debugging'' was used in aeronautics before entering the world of [[Computer|computers]]. A letter from [[J. Robert Oppenheimer]], director of the [[WWII]] atomic bomb [[Manhattan Project]] at Los Alamos, 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.
The [[Oxford English Dictionary]] entry for ''debug'' uses the term ''debugging'' in reference to airplane engine testing in a 1945 article in the Journal of the Royal Aeronautical Society.
An article in "Airforce" (June 1945 p. 50) refers to ''debugging'' aircraft cameras.
Line 21:
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''.
In the [[Association for Computing Machinery|ACM]]'s digital library, the term ''debugging'' is first used in three papers from the 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
==Scope==
Line 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 54:
* ''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 |title=Pracniques: The 'Wolf Fence' Algorithm for Debugging |author=E. J. Gauss |journal=Communications of the ACM |year=1982 |volume=25 |issue=11 |page=780 |doi=10.1145/358690.358695|s2cid=672811 |doi-access=free }}</ref> This is implemented e.g. in the [[Git (software)|Git]] [[version control system]] as the command ''git bisect'', which uses the above algorithm to determine which [[commit (data management)|commit]] introduced a particular bug.
* ''[[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-deterministic, and other hard-to-reproduce defects.
| |||