Debugging Tools and Techniques
SWEBOK Ch. 13 Sections 5
SWEBOK Ch. 13 Sections 5
SWEBOK Chapter 13 Section 5
Once a program is coded and compiled (compilation will be discussed in section 10), the next step is debugging, which is a methodical process of finding and reducing the number of bugs or faults in a program. The purpose of debugging is to find out why a program doesn’t work or produces a wrong result or output. Except for very simple programs, debugging is always necessary .
SWEBOK Chapter 13 Section 5.1
When a program does not work, it is often because the program contains bugs or errors that can be either syntactic errors, logical errors, or data errors. Logical errors and data errors are also known as two categories of “faults” in software engineering terminology (see topic 1.1, Testing-Related Terminology, in the Software Testing KA).
Syntax errors are simply any error that prevents the translator (compiler/interpreter) from successfully parsing the statement. Every statement in a program must be parse-able before its meaning can be understood and interpreted (and, therefore, executed). In high-level programming languages, syntax errors are caught during the compilation or translation from the high-level language into machine code. For example, in the C/C++ programming language, the statement “123=constant;” contains a syntax error that will be caught by the compiler during compilation.
Logic errors are semantic errors that result in incorrect computations or program behaviors. Your program is legal, but wrong! So the results do not match the problem statement or user expectations. For example, in the C/C++ programming language, the inline function “int f(int x) {return f(x-1);}” for computing factorial x! is legal but logically incorrect. This type of error cannot be caught by a compiler during compilation and is often discovered through tracing the execution of the program (Modern static checkers do identify some of these errors. However, the point remains that these are not machine checkable in general).
Data errors are input errors that result either in input data that is different from what the program expects or in the processing of wrong data.
SWEBOK Chapter 13 Section 5.2
Debugging involves many activities and can be static, dynamic, or postmortem. (In this context, static means while the code is not running.) Static debugging usually takes the form of code review, while dynamic debugging usually takes the form of tracing and is closely associated with testing. Postmortem debugging is the act of debugging the core dump (memory dump) of a process. Core dumps are often generated after a process has terminated due to an unhandled exception. All three techniques are used at various stages of program development.
The main activity of dynamic debugging is tracing, which is executing the program one piece at a time, examining the contents of registers and memory, in order to examine the results at each step. There are three ways to trace a program.
Single-stepping: execute one instruction at a time to make sure each instruction is executed correctly. This method is tedious but useful in verifying each step of a program. (This can also be done by hand / on paper for many problems.)
Breakpoints: tell the program to stop executing when it reaches a specific instruction. This technique lets one quickly execute selected code sequences to get a high-level overview of the execution behavior.
Watch points: tell the program to stop when a register or memory location changes or when it equals to a specific value. This technique is useful when one doesn’t know where or when a value is changed and when this value change likely causes the error.
Print statements: sometimes it is quicker and easier to add some print statements instead of using breakpoints. Print statements can be used to show if program execution reached a certain code block, like "I'm in the if", or the result of an expression, like cout << "a * b / c is " << a * b / c; Comment out the print statements or delete them when the issue is resolved.
Pair programming: get another set of eyes on your code, you might be overlooking something that someone else sees.
Track bugs: in Javadoc style comment for the file and / or a tracking system like Issues in GitHub or Jira
SWEBOK Chapter 13 Section 5.3
Debugging can be complex, difficult, and tedious. Like programming, debugging is also highly creative (sometimes more creative than programming). Thus some help from tools is in order. For dynamic debugging, debuggers are widely used and enable the programmer to monitor the execution of a program, stop the execution, restart the execution, set breakpoints, change values in memory, and even, in some cases, go back in time.
For static debugging, there are many static code analysis tools, which look for a specific set of known problems within the source code. 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. The UNIX lint program is an early example.