Transcript An Introduction to Debugging - Washtenaw Community College

An Introduction to Debugging
CPS120
Introduction to Computer Science
Lecture 5
Compiling and Debugging
Executable code will not be created
until you correct all of the syntax errors
in your source code
Syntax & Logic Errors
A syntax error is simply the violation of the
rules of a language; misuse of structure and
form in programming or a violation of the
compiler’s rules. These errors are detected by
the compiler
Also know as 'fatal compilation errors'
A logic error is a mistake that complies with
the rules of the compiler that causes the
program to generate incorrect output
Linker Errors
Not all syntax errors are detectable by the
compiler
These errors do not become apparent until files
are put together to create an executable
These errors are not linked to a specific line of
code
Look for the name of the variable and see what lines of
code it occurs on using EDIT and FIND
LNIK2001: unresolved external
LNK1120: unresolved externals
Debugging
Debugging is the process of locating and
fixing or bypassing bugs (errors) in
computer program code or the
engineering of a hardware device.
To debug a program or hardware device is
to start with a problem, isolate the source
of the problem, and then fix it.
Debugging Objective
1. Find the line(s) containing the syntax
error(s) using the compiler's chosen line
and error messages as a starting point
Debugging is an Art
Compilers often miss reporting an actual error
and report on subsequent lines which are
effected by error but may be completely
correct
After encountering a real syntax error,
compilers often generate many incorrect
syntax error messages
Different compilers produce different errors
and warnings for the same errors in the same
program
Debugging Steps
1. Proofread before compiling
2. Compile
3. Correct all the obvious errors
Start at the beginning of the list of errors and warnings
A single syntax error may cause the compiler to believe
numerous other syntax errors are occurring
Look at the error lines and if you see the error, fix it.
Otherwise, leave it for later. It may vanish when you fix
something else
Don’t worry if more errors appear. Some errors mask
other errors
Debugging Steps
4.
5.
6.
7.
8.
Recompile when you have fixed what you
recognize
Repeat 3 & 4 until no further errors are obvious
Attempt to solve the remaining errors in a topdown fashion
Solve whatever errors you can without
spending long periods of time on any given
error
Recompile whenever you feel you don’t see any
further solutions
Debugging Aids
1.
In the Visual C++ (and other GUI-based compilers)
double-clicking on an error message move the
cursor to the line where the compiler detected the
error
This may not be the actual line where the error occurred –
don’t trust the compiler on lines
Work from the beginning of the program, because
in most compilers, the errors are detected from the
beginning to end, sequentially
3. Some errors are so severe, they stop the compiler
from continuing so more errors may appear after
you successfully fix one or more
2.
A Debugging Mindset
Assume your syntax is wrong. Look it
up!
Add working comments as you change things
If you are 100% sure a line is correct,
then search for a syntax error in the
lines ABOVE that line
Start with the immediately previous line
and work backward
Never make a change you can’t explain
Sample Debugging Comment
cuot << "This is a line of code"<< endl;
/*************Debug*************
Error is undeclared identifier
1. Checked syntax for endl
2. Check syntax for screen output
-- cuot is misspelled
*/
Debugging Checklist
1.
Visually verify the spelling and case of keywords and
identifiers
-- Remember, in the editor, keywords are blue, literals are
black and comments are green
-- Look for problems with l and 1 and o and 0
2.
Verify syntax with a reference book, not just visually
-- Don’t trust your eyes; you see what is supposed to be
there
3.
4.
Try to find an example in the reference book that
does something similar and compare the code
Verify that the necessary delimiters used for that line
are there
-- Check the lines above and below as well
Debugging Checklist
5.
6.
Without looking at your source code or notes,
rewrite the instruction on a piece of paper and then
compare it to your actual code; don’t cheat
Verify that the line is really the source of the error
by commenting the line using //
a)
b)
c)
d)
Don’t worry about other errors that result from this
If the error disappears, it probably results from the line
you are working on
If it moves to the next line it is probably caused earlier in
the code
Remember that the compiler cannot be trusted to pinpoint
lines
Warnings
Actions that may represent problems but do
not cause the compiler to flag an error
Don’t ignore warnings
Most common warning is a ‘typecasting’ warning
Indicates that the conversion of one type of a number
was moved to a number (variable) of a different type
without inclusion of a typecasting operation
E.G. – Moving a float to an integer variable
Common Causes for Warnings
An equal sign used in an expression is
actually an assignment operator, not the
relational operator testing for equality
Loops where one condition could never
logically be executed
Testing a variable that has not received
a value yet
Disk Space Issues
If the floppy is full or becomes full during the
compilation process, the compile will fail with
an error message such as:
fatal error C1033: cannot open program database
A very cryptic message like this can result
If you are not able to view all of the
intermediate files created in a compile,
suspect a space error
Semantic Error Detection
Use the tracing method to display the value
of critical variables
Make the error reproducible
Get a stack trace of function calls to verify
sequencing
Correct the error immediately when you find
it and check if you made it somewhere else
Examine your last code changes for errors
Ensure that you have saved and run the
corrected programs
Error Prevention & Testing
Use good design and programming style
Don't use global variables
Study your code before typing and running it
Have someone else look at it
Make your program self-documented
Program defensively – put in assertions and selfchecking code and comment them out
Test your code at boundary values for variables
Log your bugs
Test code in pieces using "stubs"
Consider – correctness, reliability, utility and
performance
Most Common Bugs
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Array as a parameter handled improperly
Array index out of bounds
Call-by-value used instead of call-by reference for function
parameters to be modified
Comparison operators misused
Compound statement not used
Dangling else
Division by zero attempted
Division using integers so quotient gets truncated
Files not closed properly (buffers not flushed)
Infinite loop
Global variables used
Most Common Bugs
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
IF-ELSE not used properly
Left side of assignment not an L-value
Loop has no body
Missing "&" or missing "const" with a call-by-reference
function parameter
Missing bracket for body of function or compound statement
Mission reference to namespace
Missing return statement in a value-returning function
Missing semi-colon in simple statement, function prototypes,
struct definitions or class definitions
Mismatched data types in expressions
Operator precedence misunderstood
Most Common Bugs
26.
Off-by-one error in a loop
Overused (overloaded) local variables names
Pointers not set properly or overwritten in error
Return with value attempted in void function
Undeclared variable name
27.
Uninitialized variable
28.
Unmatched parenthesis
Unterminated strings
Using "=" when "= =" is intended
Using "&" when "&&" is intended
"while" used improperly instead of "if"
22.
23.
24.
25.
29.
30.
31.
32.