An Introduction to Debugging CPS120 Introduction to Computer Science

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 The equivalent of the use of to, two and too in English.

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

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

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

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 Checked syntax for endl Check syntax for screen output -- cuot is misspelled */

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

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

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