debug

A photo of the apocryphally "first" real bug, which was debugged in 1947

Debugging is a methodical process of finding and reducing the number of bugs, or defects, in a computer program or a piece of electronic hardware thus making it behave as expected. Debugging tends to be harder when various subsystems are tightly coupled, as changes in one may cause bugs to emerge in another.

Origin

There is some controversy over the origin of the term "debugging."

The terms "bug" and "debugging" are both popularly attributed to Admiral Grace Hopper in the 1940s^[1]. While she was working on a 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. The moth fit the already existing terminology, so she saved it.

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, Hopper's bug was found 9 September 1947. The term was not adopted by computer programmers until the early 1950s. The seminal article by Gill ^[2] in 1951 is the earliest in-depth discussion of programming errors, but it does not use the term "bug" or "debugging". In the ACM's digital library, the term "debugging" is first used in three papers from 1952 ACM National Meetings.^[3][4][5] 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 CTSS manual.^[6]

Kidwell's article Stalking the Elusive Computer Bug^[7] discusses the etymology of "bug" and "debug" in greater detail.

Tools

Debugging is, in general, a lengthy and tiresome task. The debugging skill of the programmer is probably the biggest factor in the ability to debug a problem, but the difficulty of software debugging varies greatly with the programming language used and the available tools, such as debuggers. Debuggers are software tools which enable the programmer to monitor the execution of a program, stop it, re-start it, set breakpoints, change values in memory and even, in some cases, go back in time. The term debugger can also refer to the person who is doing the debugging.

Generally, high-level programming languages, such as Java, make debugging easier, because they have features such as exception handling that make real sources of erratic behaviour easier to spot. In lower-level programming languages such as C or 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 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 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, but more semantic checkers. Some tools claim to be able to detect 300+ unique problems. Both commercial and free tools exist in various languages. These tools can be extremely useful when checking very large source trees, where it is impractical to 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 program is an early example.

For debugging electronic hardware (e.g., computer hardware) as well as low-level software (e.g., BIOSes, device drivers) and firmware, instruments such as oscilloscopes, logic analyzers or 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.

Debugging process

Print debugging is the act of watching (live or recorded) trace statements, or print statements, that indicate the flow of execution of a process.

Often the first step in debugging is to attempt reproduce the problem. This can be a non-trivial task, for example in case of parallel processes or some unusual software bugs. Also specific user environment and usage history can make it difficult to reproduce the problem.

After the bug is reproduced, the input of the program needs to be simplified to make it easier to debug. For example, a bug in a compiler can make it 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 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 GUI, the programmer will try to skip some user interaction from the original problem description and check if remaining actions are sufficient for bug to appear. To automate test case simplification, delta debugging methods can be used.^[8]

After the test case is sufficiently simplified, a programmer can use a debugger to examine program states (values of variables, the call stack) and track down the origin of the problem. Alternatively tracing can be used. In simple case, tracing is just a few print statements, which output the values of variables in certain points of program execution.

Remote debugging is the process of debugging a program running on a system different than the debugger. To start remote debugging, debugger connects to a remote system over a network. Once connected, debugger can control the execution of the program on the remote system and retrieve information about its state.

Post-mortem debugging is the act of debugging the core dump of process. The dump of the process space may be obtained automatically by the system, or manually by the interactive user. Crash dumps (core dumps) are often generated after a process has terminated due to an unhandled exception.

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".^[9] The types of technique are:

• 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

Debugging can be inhibited by using one or more of the above techniques. There are enough anti-debugging techniques available to sufficiently protect software against most threats.^[10]

See also

Software Testing portal

• Software bug
• Magic debug values
• Assertion (computing)
• Software testing

Notes

References

• Andreas Zeller: Why Programs Fail: A Guide to Systematic Debugging, Morgan Kaufmann, 2005. ISBN 1-55860-866-4

Further reading

• David J. Agans: Debugging: The Nine Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, AMACOM, 2002. ISBN 0-8144-7168-4
• Bill Blunden: Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code, APress, 2003. ISBN 1-59059-234-4
• Ann R. Ford, Toby J. Teorey: Practical Debugging in C++, Prentice Hall, 2002. ISBN 0-13-065394-2
• Thorsten Grötker, Ulrich Holtmann, Holger Keding, Markus Wloka, The Developer's Guide to Debugging, Springer, 2008. ISBN 1-40205-539-0
• Robert C. Metzger: Debugging by Thinking : A Multidisciplinary Approach, Digital Press, 2003. ISBN 1-55558-307-5
• Glenford J Myers: *The Art of Software Testing, John Wiley & Sons inc, 2004. ISBN 0-471-04328-1
• John Robbins: Debugging Applications, Microsoft Press, 2000. ISBN 0-7356-0886-5
• Matthew A. Telles, Yuan Hsieh: The Science of Debugging, The Coriolis Group, 2001. ISBN 1-57610-917-8
• Dmitry Vostokov: Memory Dump Analysis Anthology, Volume 1, OpenTask, 2008. ISBN 978-0-9558328-0-2

External links

Wikiquote has a collection of quotations related to: Debugging

The Wikibook Computer Programming Principles has a page on the topic of Debugging

• Debugging tools at the Open Directory Project
• Algorithmic and Automatic Debugging - extensive collection of links to debugging tools and methods
• Crash dump analysis patterns - In-depth articles on analyzing and finding bugs in crash dumps
• Debugging Tools for Windows
• GDB: The GNU Project Debugger
• DDD/DataDisplayDebugger