Debugging: Difference between revisions

Revision as of 07:06, 25 July 2016

Latest revision as of 09:57, 22 August 2025

(294 intermediate revisions by more than 100 users not shown)

Line 1:

{{Short description|Fixing defects in an engineered system}}

{{redirect|Debug|the shell command|debug (command)|the German magazine|Debug (magazine)|the 2014 film|Debug (film)}}

{{Redirect|Debug}}

{{Software development process|Core activities}}

'''Debugging''' is the process of finding and resolving of defects that prevent correct operation of [[computer software]] or a [[system]]. Debugging tends to be harder when various subsystems are [[Coupling (computer programming)|tightly coupled]], as changes in one may cause bugs to emerge in another.

In [[engineering]], '''debugging''' is the process of finding the [[Root cause analysis|root cause]], [[workaround]]s, and possible fixes for [[bug (engineering)|bugs]].

Numerous books have been written about debugging (see below: [[#Further reading|Further reading]]), as it involves numerous aspects, including [[interactive]] debugging, [[control flow]], [[integration testing]], [[Logfile|log files]], monitoring ([[Application monitoring|application]], [[System Monitoring|system]]), [[memory dump]]s, [[Profiling (computer programming)|profiling]], [[Statistical Process Control]], and special design tactics to improve detection while simplifying changes.

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 debuggers.

==Origin==

[[File:H96566k.jpg|thumb|A computer log entry from the Mark II, with a moth taped to the page]]

==Etymology==

The terms "bug" and "debugging" are popularly attributed to [[Admiral Grace Hopper]] in the 1940s.<ref>[http://foldoc.org/?Grace+Hopper Grace Hopper] from FOLDOC</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 meaning of technical error dates back at least to 1878 and [[Thomas Edison]] (see [[software bug]] for a full discussion), and "debugging" seems to have been used as a term in aeronautics before entering the world of computers. Indeed, 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, NM) used the term in a letter to Dr. [[Ernest Lawrence]] at UC Berkeley, dated October 27, 1944,<ref>http://bancroft.berkeley.edu/Exhibits/physics/images/bigscience25.jpg</ref> regarding the recruitment of additional technical staff.

{{seealso|Bug (engineering)#History}}

[[File:H96566kFirst Computer Bug, 1945.jpg|thumb|A computer log entry from the Mark&nbsp;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 [[Oxford English Dictionary]] entry for "debug" quotes the term "debugging" used 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.&nbsp;50) also refers to debugging, this time of aircraft cameras. Hopper's [[computer bug|bug]] was found on September 9, 1947. The term was not adopted by computer programmers until the early 1950s.

The seminal article by Gill<ref>S. Gill, [http://links.jstor.org/sici?sici=0080-4630%2819510522%29206%3A1087%3C538%3ATDOMIP%3E2.0.CO%3B2-9 The Diagnosis of Mistakes in Programmes on the EDSAC], 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 1952 ACM National Meetings.<ref>Robert V. D. Campbell, [http://portal.acm.org/citation.cfm?id=609784.609786 Evolution of automatic computation], Proceedings of the 1952 ACM national meeting (Pittsburgh), p 29-32, 1952.</ref><ref>Alex Orden, [http://portal.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, [http://portal.acm.org/citation.cfm?id=800259.808982 MANIAC], 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], M.I.T. Press, 1963</ref>

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.

Kidwell's article ''Stalking the Elusive Computer Bug''<ref>Peggy Aldrich Kidwell, [http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&arnumber=728224&isnumber=15706 Stalking the Elusive Computer Bug], IEEE Annals of the History of Computing, 1998.</ref> discusses the etymology of "bug" and "debug" in greater detail.

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"'' quotesuses the term "''debugging" used'' 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.&nbsp;50) also refers to debugging, this time of aircraft cameras. Hopper's [[computer bug|bug]] was found on September 9, 1947. The term was not adopted by computer programmers until the early 1950s.

An article in "Airforce" (June 1945 p.&nbsp;50) refers to ''debugging'' aircraft cameras.

The seminal article by Gill<ref>S. Gill, [httphttps://linkswww.jstor.org/sici?sici=0080-4630%2819510522%29206%3A1087%3C538%3ATDOMIP%3E2.0.CO%3B2-9stable/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, [httphttps://portaldl.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, [httphttps://portaldl.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, [httphttps://portaldl.acm.org/citation.cfm?id=800259.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>

==Scope==

As software and electronic systems have become generally more complex, the various common debugging techniques have expanded with more methods to detect anomalies, assess impact, and schedule [[software patch]]es or full updates to a system. The words "anomaly" and "discrepancy" can be used, as being [[euphemism|more neutral terms]], to avoid the words "error" and "defect" or "bug" where there might be an implication that all so-called ''errors'', ''defects'' or ''bugs'' must be fixed (at all costs). Instead, an [[impact assessment]] can be made to determine if changes to remove an ''anomaly'' (or ''discrepancy'') would be cost-effective for the system, or perhaps a scheduled new release might render the {{Not a typo|change(s)}} unnecessary. Not all issues are [[lifesafety-critical system|safety-critical]] or [[mission-critical]] in a system. Also, it is important to avoid the situation where a change might be more upsetting to users, long-term, than living with the known {{Not a typo|problem(s)}} (where the "cure would be worse than the disease"). Basing decisions of the acceptability of some anomalies can avoid a culture of a "zero-defects" mandate, where people might be tempted to deny the existence of problems so that the result would appear as zero ''defects''. Considering the collateral issues, such as the cost-versus-benefit impact assessment, then broader debugging techniques will expand to determine the frequency of anomalies (how often the same "bugs" occur) to help assess their impact to the overall system.

==Tools==

{{See alsoMain|Debugger}}

[[File:Xbox-Debug-Console-Set.jpg|thumb|right|250px|Debugging on video game consoles is usually done with special hardware such as this [[Xbox (console)|Xbox]] debug unit intended only for developers.]]

{{See also|Debugger}}

Debugging ranges in complexity from fixing simple errors to performing lengthy and tiresome tasks of data collection, analysis, and scheduling updates. The debugging skill of the programmer can be a major factor in the ability to debug a problem, but the difficulty of software debugging varies greatly with the complexity of the system, and also depends, to some extent, on the [[programming language]](s) used and the available tools, such as ''[[debugger]]s''. Debuggers are software tools which enable the [[programmer]] to monitor the [[execution (computerscomputing)|execution]] of a program, stop it, restart it, set [[breakpoint]]s, and change values in memory. The term ''debugger'' can also refer to the person who is doing the debugging.

Generally, [[high-level programming language]]s, such as [[Java (programming language)|Java]], make debugging easier, because they have features such as [[exception handling]] and [[type checking]] that make real sources of erratic behaviour easier to spot. In programming languages such as [[C (programming language)|C]] or [[assembly language|assembly]], bugs may cause silent problems such as [[memory corruption]], and it is often difficult to see where the initial problem happened. In those cases, [[memory debugging|memory debugger]] tools may be needed.

In certain situations, general purpose software tools that are language specific in nature can be very useful. These take the form of ''[[Listlist of tools for static code analysis|static code analysis tools]]''. These tools look for a very specific set of known problems, some common and some rare, within the source code. All such issues detected by these tools would rarely be picked up by a compiler or interpreter, thus they are not syntax checkers, butconcentrating more semanticon checkers.the semantics Some tools claim to be able to detect 300+ unique problems(e. Both commercial and free tools exist in various languagesg. data Theseflow) toolsrather canthan bethe extremely useful when checking very large source treessyntax, whereas itcompilers isand impractical tointerpreters do code walkthroughs. A typical example of a problem detected would be a variable dereference that occurs ''before'' the variable is assigned a value. Another example would be to perform strong type checking when the language does not require such. Thus, they are better at locating likely errors, versus actual errors. As a result, these tools have a reputation of false positives. The old Unix ''[[Lint programming tool|lint]]'' program is an early example.

Both commercial and free tools exist for various languages; some claim to be able to detect hundreds of different problems. These tools can be extremely useful when checking very large source trees, where it is impractical to do code walk-throughs. A typical example of a problem detected would be a variable dereference that occurs ''before'' the variable is assigned a value. As another example, some such tools perform strong type checking when the language does not require it. Thus, they are better at locating likely errors in code that is syntactically correct. But these tools have a reputation of false positives, where correct code is flagged as dubious. The old Unix ''[[lint (software)|lint]]'' program is an early example.

For debugging electronic hardware (e.g., [[computer hardware]]) as well as low-level software (e.g., [[BIOS]]es, [[device driver]]s) and [[firmware]], instruments such as [[oscilloscope]]s, [[logic analyzer]]s or [[in-circuit emulator|in-circuit emulators (ICEs)]] are often used, alone or in combination. An ICE may perform many of the typical software debugger's tasks on low-level [[software]] and [[firmware]].

For debugging electronic hardware (e.g., [[computer hardware]]) as well as low-level software (e.g., [[BIOS]]es, [[device driver]]s) and [[firmware]], instruments such as [[oscilloscope]]s, [[logic analyzer]]s, or [[in-circuit emulator|in-circuit emulators]]s (ICEs)]] are often used, alone or in combination. An ICE may perform many of the typical software debugger's tasks on low-level [[software]] and [[firmware]].

== Typical debugging process ==

Normally the first step in debugging is to attempt to reproduce the problem. This can be a non-trivial task, for example as with [[Parallel computing|parallel processes]] or some [[unusual software bugs]]. Also, specific user environment and usage history can make it difficult to reproduce the problem.

* [[==Debugging patterns]]process==

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 some 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. Such simplification can be made manually, using a [[Divide and conquer algorithm|divide-and-conquer]] approach. The programmer will try to remove some parts of original test case and check if the problem still exists. When debugging the problem in a [[Graphical user interface|GUI]], the programmer can try to skip some user interaction from the original problem description and check if remaining actions are sufficient for bugs to appear.

NormallyThe thedebugging firstprocess stepnormally inbegins debuggingwith isidentifying tothe attemptsteps to reproduce the problem. This can be a non-trivial task, for example asparticularly with [[Parallel computing|parallel processes]] orand some [[unusual software bugsHeisenbug]]s for example. Also,The specific [[user environment]] and usage history can also make it difficult to reproduce the problem.

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 somea 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. SuchSimplification simplification canmay be madedone manually, using a [[Divide -and -conquer algorithm|divide-and-conquer]] approach., Thein which the programmer will tryattempts to remove some parts of original test case andthen checkchecks if the problem still existsoccurs. When debugging the problem in a [[Graphical user interface|GUI]], the programmer can try to skipskipping some user interaction from the original problem description andto check if the remaining actions are sufficient for bugscausing the bug to appearoccur.

After the test case is sufficiently simplified, a programmer can use a [[debugger]] tool to examine program states (values of variables, plus the [[call stack]]) and track down the origin of the problem(s). Alternatively, [[Tracing (software)|tracing]] can be used. In simple cases, tracing is just a few print statements, which output the values of variables at certain points of program execution.{{citation needed|date=February 2016}}

After the test case is sufficiently simplified, a programmer can use a [[debugger]] tool to examine program states (values of variables, plus the [[call stack]]) and track down the origin of the {{Not a typo|problem(s)}}. Alternatively, [[Tracing (software)|tracing]] can be used. In simple cases, tracing is just a few print statements, which output the values of variables at certainparticular points ofduring programthe execution of the program.{{citation needed|date=February 2016}}

== Techniques ==

* ''{{visible anchor|Print debugging}}'' (or tracing) is the act of watching (live or recorded) trace statements, or print statements, that indicate the flow of execution of a process. This 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.

== Techniques ==

* ''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 network. The debugger can then control the execution of the program on the remote system and retrieve information about its state.

* ''Interactive debugging'' uses debugger tools which allow a program's execution to be processed one step at a time and to be paused to inspect or alter its state. Subroutines or function calls may typically be executed at full speed and paused again upon return to their caller, or themselves single stepped, or any mixture of these options. Setpoints may be installed which permit full speed execution of code that is not suspected to be faulty, and then stop at a point that is. Putting a setpoint immediately after the end of a program loop is a convenient way to evaluate repeating code. Watchpoints are commonly available, where execution can proceed until a particular variable changes, and catchpoints which cause the debugger to stop for certain kinds of program events, such as exceptions or the loading of a shared library.

* ''Post-mortem debugging'' is debugging of the program after it has already [[Crash (computing)|crashed]]. Related techniques often include various tracing techniques (for example,<ref>[http://www.drdobbs.com/tools/185300443 Postmortem Debugging, Stephen Wormuller, Dr. Dobbs Journal, 2006]</ref>) and/or 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 process has terminated due to an unhandled exception), or by a programmer-inserted instruction, or manually by the interactive user.

* ''{{visible anchor|Print debugging}}'' (or tracing''[[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. ThisTracing 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.

* ''"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 name="communications of the ACM">{{cite journal | title="Pracniques: The "Wolf Fence" Algorithm for Debugging", | author=E. J. Gauss | year=1982}}</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.

* ''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.

* ''[[Delta Debugging]]''{{snd}} a technique of automating test case simplification.<ref>Andreas Zeller: <cite>Why Programs Fail: A Guide to Systematic Debugging</cite>, Morgan Kaufmann, 2005. ISBN 1-55860-866-4</ref>{{rp|p.123}}<!-- for redirect from 'Saff Squeeze' -->

* ''{{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.

* ''Saff Squeeze''{{snd}} a technique of isolating failure within the test using progressive inlining of parts of the failing test.<ref>[http://www.threeriversinstitute.org/HitEmHighHitEmLow.html Kent Beck, Hit 'em High, Hit 'em Low: Regression Testing and the Saff Squeeze]</ref>

* ''Post-mortem debugging'' is debugging of the program after it has already [[Crashcrash (computing)|crashed]]. Related techniques often include various tracing techniques (forlike exampleexamining log files, outputting a [[call stack]] on the crash,<ref>[http{{cite web|url=https://www.drdobbs.com/tools/postmortem-debugging/185300443 |title=Postmortem Debugging, Stephen Wormuller, |work=Dr. DobbsDobb's Journal, 2006]|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/or 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[[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 name="communications of the ACM">{{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 [[Commitcommit (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.

* ''[[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 Debuggingdebugging]]''{{snd}} a technique of automating test case simplification.<ref>Andreas{{cite book |last=Zeller: <cite>|first=Andreas |date=2005 |title=Why Programs Fail: A Guide to Systematic Debugging</cite>, |publisher=Morgan Kaufmann, 2005. ISBN |isbn=1-55860-866-4}}</ref>{{rp|p.123}}<!-- for redirect from 'Saff Squeeze' -->

* ''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>

===Automatic bug fixing===

{{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 infor 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 book|last1=Tancreti|first1=Matthew|last2=Hossain|first2=Mohammad Sajjad|last3=Bagchi|first3=Saurabh|last4=Raghunathan|first4=Vijay|title=Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems |chapter=Aveksha |date=2011|series=SenSys '11|___location=New York, NY, USA|publisher=ACM|pages=288–301|doi=10.1145/2070942.2070972|isbn=9781450307185|s2cid=14769602}}</ref> and Flocklab.<ref>{{cite book|last1=Lim|first1=Roman|last2=Ferrari|first2=Federico|last3=Zimmerling|first3=Marco|last4=Walser|first4=Christoph|last5=Sommer|first5=Philipp|last6=Beutel|first6=Jan|title=Proceedings of the 12th international conference on Information processing in sensor networks |chapter=FlockLab |date=2013|series=IPSN '13|___location=New York, NY, USA|publisher=ACM|pages=153–166|doi=10.1145/2461381.2461402|isbn=9781450319591|s2cid=447045}}</ref> They all leverage a functionality available on low-cost embedded processors, an On-Chip Debug Module (OCDM), whose signals are exposed through a standard [[JTAG|JTAG interface]]. They are benchmarked based on how much change to the application is needed and the rate of events that they can keep up with.

*to identify and fix bugs in the system (e.g. logical or synchronization problems in the code, or a design error in the hardware);

*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.).

==Anti-debugging==

Anti-debugging is "the implementation of one or more techniques within computer code that hinders attempts at [[reverse engineering]] or debugging a target process".<ref name="veracode-antidebugging">{{cite web |url=httphttps://www.veracode.com/blog/2008/12/anti-debugging-series-part-i/ |title=Anti-Debugging Series -– Part I |last=Shields |first=Tyler |date=2008-12-02 |work=[[Veracode]] |accessdateaccess-date=2009-03-17 |archive-date=2016-10-19 |archive-url=https://web.archive.org/web/20161019075351/http://www.veracode.com/blog/2008/12/anti-debugging-series-part-i |url-status=live }}</ref> It is actively used by recognized publishers in [[copy protection|copy-protection schemas]] schemas, but is also used by [[malware]] to complicate its detection and elimination.<ref name="soft-prot">[{{cite web|url=http://people.seas.harvard.edu/~mgagnon/software_protection_through_anti_debugging.pdf |title=Software Protection through Anti-Debugging Michael N Gagnon, Stephen Taylor, Anup Ghosh]|access-date=2010-10-25|archive-url=https://web.archive.org/web/20111001172453/http://people.seas.harvard.edu/~mgagnon/software_protection_through_anti_debugging.pdf|archive-date=2011-10-01|url-status=dead}}</ref> Techniques used in anti-debugging include:

* API-based: check for the existence of a debugger using system information

* Exception-based: check to see if exceptions are interfered with

* Process and thread blocks: check whether process and thread blocks have been manipulated

* Modified code: check for code modifications made by a debugger handling software breakpoints

* Hardware- and register-based: check for hardware breakpoints and CPU registers

* Timing and latency: check the time taken for the execution of instructions

* Detecting and penalizing debugger<ref name="soft-prot" /><!-- reference does not exist -->

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=httphttps://www.clarchive.cam.ac.ukorg/~rja14details/book.htmlsecurityengineer00ande |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}}

{{Portal|Software Testing}}

* [[Assertion (computingsoftware development)]]

* [[Category:Debugging|* pattern]]

{{Div col||20em}}

* [[Assertion (computing)]]

* [[Debugger]]

* [[Debugging patterns]]

* [[Magic number (programming)#Magic debug values|Magic debug values]]

* [[Shotgun debugging]]

* [[Software bug]]

* [[Software testing]]

* [[ShotgunTime travel debugging]]

* [[Trace table]]

* [[Troubleshooting]]

{{Div col end}}

== References ==

{{Reflist|30em}}

==Further reading==

* {{cite book |last=Agans|first=David J. Agans: <cite>|date=2002|title=Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems</cite>, |publisher=AMACOM, 2002. ISBN |isbn=0-8144-7168-4|url=https://archive.org/details/debugging9indisp0000agan}}

* [[Bill{{cite Blundenbook (author)|Bill last=Blunden]]: <cite>|first=Bill|date=2003|title=Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code</cite>, |publisher=APress, 2003. ISBN |isbn=1-59059-234-4|author-link=Bill Blunden (author)}}

* {{cite book |last1=Ford|first1=Ann R. Ford, |last2=Teorey|first2=Toby J. Teorey: <cite>|date=2002|title=Practical Debugging in C++</cite>, |publisher=Prentice Hall, 2002. ISBN |isbn=0-13-065394-2|url=https://archive.org/details/practicaldebuggi00ford}}

* Thorsten{{cite book |last1=Grötker, Ulrich|first1=Thorsten |last2=Holtmann, Holger|first2=Ulrich |last3=Keding, Markus|first3=Holger |last4=Wloka, <cite>|first4=Markus |date=2012 |title=The Developer's Guide to Debugging, Second Edition</cite>, |publisher=Createspace, 2012. ISBN |isbn=978-1-4701-8552-07}}

* {{cite book |last=Metzger|first=Robert C. Metzger: <cite>|date=2003|title=Debugging by Thinking : A Multidisciplinary Approach</cite>, |publisher=Digital Press, 2003. ISBN |isbn=1-55558-307-5}}

* {{cite book |last=Myers |first=Glenford J Myers:|date=2004 <cite>*|title=The Art of Software Testing</cite>, |publisher=John Wiley & Sons inc, 2004. ISBNInc |isbn=0-471-04328-1 |url=https://archive.org/details/artofsoftwaretes00myer}}

* John{{cite book |last=Robbins: <cite>|first=John |date=2000 |title=Debugging Applications</cite>, |publisher=Microsoft Press, 2000. ISBN |isbn=0-7356-0886-5}}

* {{cite book |last1=Telles |first1=Matthew A. Telles,|last2=Hsieh |first2=Yuan Hsieh:|date=2001 <cite>|title=The Science of Debugging</cite>, |publisher=The Coriolis Group, 2001. ISBN |isbn=1-57610-917-8}}

* Dmitry{{cite book |last=Vostokov: <cite>|first=Dmitry |date=2008 |title=Memory Dump Analysis Anthology, Volume 1</cite>, |publisher=OpenTask, 2008. ISBN |isbn=978-0-9558328-0-2}}

* Andreas{{cite book |last=Zeller: <cite>|first=Andreas|date=2009|title=Why Programs Fail, Second Edition: A Guide to Systematic Debugging</cite>, |publisher=Morgan Kaufmann, 2009. ISBN |isbn=978-0-1237-4515-26}}

Kidwell's* article ''Stalking the Elusive Computer Bug''<ref>Peggy Aldrich Kidwell, [httphttps://ieeexplore.ieee.org/xpldocument/freeabs_all.jsp728224?tp=&arnumber=728224&isnumber=15706 Stalking the Elusive Computer Bug], IEEE Annals of the History of Computing, 1998.</ref> discusses the etymology of "bug" and "debug" in greater detail.

* {{cite journal|last=Artzi|first=Shay|author2=Adam Kiezun |author3=Julian Dolby |author4=Frank Tip |author5=Danny Dig |author6=Amit Paradkar |author7=Michael D. Ernst |year=2008|title=Finding bugs in dynamic web applications|page=261|doi=10.1145/1390630.1390662}}

==External links==

{{wikiquoteWikiquote|Programming#Debugging|Debugging}}

{{wikibooksWikibooks|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

* [httphttps://webwww.archive.org/web/20070218145734/http://www-128cs.ibmusfca.comedu/developerworks~parrt/webdoc/library/wa-debugdebugging.html?ca=dgr-lnxw03Dbug LearnThe the essentialsEssentials of debuggingDebugging]{{snd}} how to improve your debugging skills, a good article at [[IBM]] developerWorks (archived from the original on February 18, 2007)

* [http://www.clarinox.com/docs/whitepapers/EmbeddedDebugger.pdf Plug-in Based Debugging For Embedded Systems]

* [httphttps://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)

{{Authority control}}

[[Category:DebuggersDebugging|* ]]

[[Category:Debugging|*]]