2.9.1. Debugging Logical Errors

The compiler component produces diagnostics announcing and roughly locating syntax errors, while the linker or loader announces assembly errors but with little location information. Both errors prevent the compiler from creating an executable file. Logical errors, however, are different: the program compiles and runs, but its actions or output are incorrect. Programmers either failed to solve the original problem correctly or failed to translate the solution into a program correctly. In short, the program does exactly what it was "told" to do, putting the error beyond the compiler's detection.

A program's logical correctness assumes a meaning that lies within the software developer's mind, above a program's arithmetic and logical operations. Consequently, only a developer can determine if a program is logically correct. Developers test and validate program operation against a set of test cases - a set of input values and their corresponding output. However, when a program fails a test case, the failure only indicates a logical error, not where it's located. Software developers must locate logical errors.

A simple but concrete example illustrates the three-step process, making it easier to understand. The first version of the ftoc.cpp program had a logical error. Locating the logical error demonstrates the three steps. The first step, calculating intermediate values throughout the program, is necessary for both the manual and debugger approaches. For the simple ftoc demonstration, the example can calculate all the values. For larger programs, developers may calculate a few values in an attempt to bracket the error - identify a location where the values are correct and a location where they are not. Once bracketed, they calculate more detailed values within the brackets.

Formula	Test Case 1	Test Case 2
\[c = {5 \over 9} (f - 32) \]	Input Expression Expected Output 32         f 32     5/9 0.555556     f-32 0     5/ 9*(f-32) 0         0	Input Expression Expected Output 212         f 212     5/9 0.555556     f-32 180     5/9*(f-32) 100         100

Locating A Logical Error: Manually Instrumenting The Code

The first (primitive) approach is conceptually easy to follow, can be used with any development environment, and illuminates the operations that the debugger automates. To instrument code means to add statements to it that support operations beyond its primary purpose.

#include <iostream>
using namespace std;

int main()
{
	double	f;
	cout << "Enter a temperature in Fahrenheit: ";
	cin >> f;

	cout << "f = " << f << endl;
	cout << "5/9 = " << 5 / 9 << endl;
	cout << "f-32 = " << f - 32 << endl;
	double c = 5 / 9 * (f - 32);
	cout << "c = " << c << endl;

	cout << "The temperature in Celsius = " << c << endl;

	return 0;
}

The original example ran the test cases with uninstrumented code. Despite having a logical error, the first test case produced the correct output and "passed" the test. However, the second test case failed, initiating the current debugging activity. This situation underscores the importance of using multiple test cases to validate even simple code. Comparing the instrumented code's output with the expected intermediate values for either test case locates the error.

Locating A Logical Error: Using A Debugger

Manual instrumentation and the debugger each have their relative advantages and disadvantages. Manual instrumentation doesn't require programmers to learn a new tool, but it does require them to change the code, independently of correcting it, before and after locating the error. Furthermore, they must edit and recompile the program whenever they want to examine a different part of it - a tedious process. They must also remember to remove the instrumentation before deploying the program.

Most modern integrated development environments (IDEs) include a debugger that allows developers to examine the values stored in variables or calculated by expressions, automating step 2 of the three-step process. Debuggers require programmers to learn a complex tool. Although most debuggers are similar, each one may have a unique interface and behavior. IDEs typically provide controls that switch the final executable between a release and debugging version. The compiler automatically instruments the debugging version, which the debugger runs as an interpreter, eliminating the needs to recompile the program to examine different parts of it, and to "clean up" the program once debugging is finished.

The following examples use one version of Visual Studio to demonstrate various ways to examine code with a debugger. However, most debuggers use the same terminology and provide similar features.

Examining Expressions

#include <iostream>
using namespace std;

int main()
{
    double  f;
    cout << "Enter a temperature in Fahrenheit: ";
    cin >> f;

    double  c = 5 / 9 * (f - 32);

    cout << "The temperature in Celsius = " << c << endl;

    return 0;
}

	Highlight (left-click and drag) the expression whose value you want to see. Place the mouse pointer inside the highlighted region. The expression and its current value appear next to the cursor.

Debugger Shortcuts

(a)	(b)	(c)

One Breakpoint, Multiple Statement Values

Although the ftoc program contained multiple expressions to explore, it only had one statement that could harbor the sought-after logical error. For longer programs, it's easier to start with complete statements. Consequently, we interpret "intermediate results" as each statement that calculates a significant value. Once this process identifies a failing statement, we can focus on its individual expressions as needed. The following figures use an abridged version of the payment.cpp program to illustrate manual instrumentation and using the debugger to examine intermediate statements.

int  n = years * 12;
double  r = apr / 12;

double	payment = p * r / (1 - pow(1 + r, -n));
cout << "Monthly Payment: " << payment << endl;

return 0;

int	n = years * 12;
cout << "n = " << n << endl;
double	r = apr / 12;
cout << "r = " << r << endl;

double	payment = p * r / (1 - pow(1 + r, -n));
cout << "Monthly Payment: " << payment << endl;

Examining Statements With Tracepoints

Using tracepoints to examine program statements has advantages and disadvantages. Creating them requires the same effort as creating breakpoints following Figure 5, steps 1-3, but they don't support the shortcut described in Figure 9, step 1. Where breakpoints only pause a program to let programmers examine it, tracepoints allow more precise control: programmers can set conditions that control tracepoint activation and the actions the tracepoints take. The following figures illustrate tracepoint actions.

A sequence of configured tracepoints can display information like the manually instrumented code illustrated in Figure 8(b). The configuration uses a simple but arcane language, and configuring each tracepoint is a bit tedious; but unlike manually instrumented statements, tracepoints are quick and easy to remove. The language lets programmers specify labeling text that the debugger displays verbatim and variables whose values replace them in the output. Tracepoints are most useful for debugging branches, loops, and functions - topics covered in later chapters.

(a)	(b)