Content deleted Content added
Line 48:
* ''{{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.
* ''{{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|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 |url=https://dl.acm.org/citation.cfm?id=358690.358695 |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 }}</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-determinstic, and other hard-to-reproduce defects.
Line 55:
* ''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 |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>
==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.
| |||