An Introduction to Debugging

1. An Introduction to Debugging CPS120 Introduction to Computer Science Lecture 5

2. Compiling and Debugging • Executable code will not be created until you correct all of the syntax errors in your source code

3. 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

4. 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

5. 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.

6. Debugging Objective • Find the line(s) containing the syntax error(s) using the compiler's chosen line and error messages as a starting point

7. 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

8. Debugging Steps • Proofread before compiling • Compile • 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

9. Debugging Steps • 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 top-down 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

10. Debugging Aids • 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 • Some errors are so severe, they stop the compiler from continuing so more errors may appear after you successfully fix one or more

11. 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

12. Sample Debugging Comment cuot << "This is a line of code"<< endl; /*************Debug************* Error is undeclared identifier • Checked syntax for endl • Check syntax for screen output -- cuot is misspelled */

13. Debugging Checklist • 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 • Verify syntax with a reference book, not just visually -- Don’t trust your eyes; you see what is supposed to be there • 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

14. Debugging Checklist • 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 // • 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

15. 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

16. 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

17. 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

18. 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

19. 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 self-checking 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

20. Most Common Bugs • 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

21. Most Common Bugs • 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

22. Most Common Bugs • 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 • Uninitialized variable • Unmatched parenthesis • Unterminated strings • Using "=" when "= =" is intended • Using "&" when "&&" is intended • "while" used improperly instead of "if"