A computer log entry from the Mark II, with a moth taped to the page
The termbug, in the sense of defect, dates back at least to 1878 whenThomas Edison wrote "little faults and difficulties" in his inventions as "Bugs".
A popular story from the 1940s is fromAdmiral Grace Hopper.[1] While she was working on aMark II computer at Harvard University, her associates discovered amoth stuck in a relay that impeded operation and wrote in a log book "First actual case of a bug being found". Although probably ajoke, 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 termdebugging was used in aeronautics before entering the world of computers. A letter fromJ. Robert Oppenheimer, director of theWWII atomic bombManhattan Project at Los Alamos, used the term in a letter to Dr.Ernest Lawrence at UC Berkeley, dated October 27, 1944,[2] regarding the recruitment of additional technical staff.TheOxford English Dictionary entry fordebug uses the termdebugging 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 todebugging aircraft cameras.
The seminal article by Gill[3] in 1951 is the earliest in-depth discussion of programming errors, but it does not use the termbug ordebugging.
In theACM's digital library, the termdebugging is first used in three papers from 1952 ACM National Meetings.[4][5][6] Two of the three use the term in quotation marks.
By 1963debugging was a common-enough term to be mentioned in passing without explanation on page 1 of theCTSS manual.[7]
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 schedulesoftware patches or full updates to a system. The words "anomaly" and "discrepancy" can be used, as beingmore neutral terms, to avoid the words "error" and "defect" or "bug" where there might be an implication that all so-callederrors,defects orbugs must be fixed (at all costs). Instead, animpact assessment can be made to determine if changes to remove ananomaly (ordiscrepancy) would be cost-effective for the system, or perhaps a scheduled new release might render the change(s) unnecessary. Not all issues aresafety-critical ormission-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 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 zerodefects. 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.
Debugging on video game consoles is usually done with special hardware such as thisXbox debug unit intended for developers.
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 theprogramming language(s) used and the available tools, such asdebuggers. Debuggers are software tools which enable theprogrammer to monitor theexecution of a program, stop it, restart it, setbreakpoints, and change values in memory. The termdebugger can also refer to the person who is doing the debugging.
Generally,high-level programming languages, such asJava, make debugging easier, because they have features such asexception handling andtype checking that make real sources of erratic behaviour easier to spot. In programming languages such asC orassembly, bugs may cause silent problems such asmemory corruption, and it is often difficult to see where the initial problem happened. In those cases,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 ofstatic code analysis tools. These tools look for a very specific set of known problems, some common and some rare, within the source code, concentrating more on the semantics (e.g. data flow) rather than the syntax, as compilers and interpreters do.
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 occursbefore 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 Unixlint program is an early example.
The debugging process normally begins with identifying the steps to reproduce the problem. This can be a non-trivial task, particularly withparallel processes and someHeisenbugs for example. The specificuser 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 itcrash 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 adivide-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 aGUI, 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.
After the test case is sufficiently simplified, a programmer can use a debugger tool to examine program states (values of variables, plus thecall stack) and track down the origin of the problem(s). Alternatively,tracing can be used. In simple cases, tracing is just a few print statements which output the values of variables at particular points during the execution of the program.[citation needed]
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.
Print debugging ortracing 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 calledprintf debugging, due to the use of theprintf function in C. This kind of debugging was turned on by the command TRON in the original versions of the novice-orientedBASIC 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.
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 alreadycrashed. Related techniques often include various tracing techniques like examining log files, outputting acall stack on the crash,[8] and analysis ofmemory dump (orcore 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 forCommunications 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."[9] This is implemented e.g. in theGitversion control system as the commandgit bisect, which uses the above algorithm to determine whichcommit introduced a particular bug.
Record and replay debugging is the technique of creating a program execution recording (e.g. using Mozilla's freerr 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. usingUndo 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 debugging – a technique of automating test case simplification.[10]: p.123
Saff Squeeze – a technique of isolating failure within the test using progressive inlining of parts of the failing test.[11][12]
Causality tracking: There are techniques to track the cause effect chains in the computation.[13] Those techniques can be tailored for specific bugs, such as null pointer dereferences.[14]
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 fromGreen Hills Software,[19]Lauterbach GmbH[20] and Microchip's MPLAB-ICD (for in-circuit debugger). Two examples of research prototype tools are Aveksha[21] and Flocklab.[22] They all leverage a functionality available on low-cost embedded processors, an On-Chip Debug Module (OCDM), whose signals are exposed through a standardJTAG 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.
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 is "the implementation of one or more techniques within computer code that hinders attempts atreverse engineering or debugging a target process".[23] It is actively used by recognized publishers incopy-protection schemas, but is also used bymalware to complicate its detection and elimination.[24] 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
An early example of anti-debugging existed in early versions ofMicrosoft 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.[25][26]
^Howard B. Demuth, John B. Jackson, Edmund Klein, N. Metropolis, Walter Orvedahl, James H. Richardson,MANIAC doi=10.1145/800259.808982, Proceedings of the 1952 ACM national meeting (Toronto), p. 13-16
^Bond, Michael D.; Nethercote, Nicholas; Kent, Stephen W.; Guyer, Samuel Z.; McKinley, Kathryn S. (2007). "Tracking bad apples".Proceedings of the 22nd annual ACM SIGPLAN conference on Object oriented programming systems and applications - OOPSLA '07. p. 405.doi:10.1145/1297027.1297057.ISBN9781595937865.S2CID2832749.
^Tancreti, Matthew; Hossain, Mohammad Sajjad; Bagchi, Saurabh; Raghunathan, Vijay (2011). "Aveksha".Proceedings of the 9th ACM Conference on Embedded Networked Sensor Systems. SenSys '11. New York, NY, USA: ACM. pp. 288–301.doi:10.1145/2070942.2070972.ISBN9781450307185.S2CID14769602.
^Lim, Roman; Ferrari, Federico; Zimmerling, Marco; Walser, Christoph; Sommer, Philipp; Beutel, Jan (2013). "FlockLab".Proceedings of the 12th international conference on Information processing in sensor networks. IPSN '13. New York, NY, USA: ACM. pp. 153–166.doi:10.1145/2461381.2461402.ISBN9781450319591.S2CID447045.
