1. Fluency with Information Technology
7th Edition
Chapter 6
An Introduction to Debugging

2. Learning Objectives
1.1 Explain how ordinary precision differs from computer precision
1.2 Describe the six-step strategy for debugging
1.3 Apply the debugging strategy to a web page's HTML code
1.4 Learn how to approach debugging when you don't understand the system
1.5 Appreciate the problems of making perfectly reliable computing systems

3. 1.1 Precision: The High Standards of Computing
Computers do exactly what they are told
They know what we said, not what we meant
In this chapter:
The importance of saying precisely what we mean
The process of figuring out what we said that we didn’t mean

4. Be Accurate Be aware of some potential mistakes
Recognizing mistaken substitutions: l for 1, O for 0, \ for /, and so forth
Knowing that certain fonts can be very confusing: Corbel zero (o) and oh (o)
Respecting upper- and lowercase in pathnames ( not the same as
Respecting upper- and lowercase in passwords

5. Be Observant
A principle of computing is that you should expect feedback when interacting with software
We rely on this feedback (busy icons, etc.)
By paying attention to feedback, we can catch errors as we make them

6. Debugging: What's the Problem?
Debugging is a process by which one figures out why something isn’t working properly
Debugging relies mostly on logical reasoning and is learned through experience

7. Debugging in Everyday Life
Debugging is troubleshooting
Humans do it all the time (why didn’t the car start? why didn’t the alarm go off?)
Faults and failures in everyday life usually involve devices that are working systems with a broken or worn-out part
The system is properly designed and constructed, but some part failed

8. Debugging in Information Technology
Debugging in computation is different
We may have entered wrong data or wrong configuration information into a working system
When it’s corrected, the system works
Or we might have a logical design error
We don’t get what we think we should get
However, always begin by assuming the system is correct and working

9. We command the computer to do tasks and we input the information
Whose Problem Is It?
When debugging a computing system, we are almost always part of the problem
We command the computer to do tasks and we input the information
While human errors occur more often, sometimes it isn't us: both hardware and software errors do happen

10. Using the Computer to Debug
For some bugs, we can use a workaround
Bypassing the error with an alternative approach and continue to use the system
Debugging is tricky
Not only is the computer unable to debug itself, we can’t debug it directly
We have to follow a series of steps for the best outcome
By asking the right questions, we can focus on the issue and discover a solution quickly

11. 1.2 The Six-Step Strategy for Debugging
Confirm the error is reproducible
Determine exactly what the problem is
Check all of the possible error sources
Isolate the problem: What is and isn't working
When you reach a dead end, reassess
Make predictions and verify

12. Debugging Step #1: Reproducible Errors
Remember that computers are deterministic -- they do exactly the same thing every time if given the same input
Start by trying to reproduce the error by reproducing the input

13. Debugging Step #2: Identify the Problem
The computer may perform a sequence of operations after an error
These operations must be eliminated first as the focal point of the debugging
Determining the exact problem is critical to finding the right solution

14. Debugging Step #3: Check the Error Sources
Some sources of errors may be "obvious"
What kinds of errors are obvious depends on the problem
Check inputs, connections, links, previous behavior, etc.

15. Debugging Step #4: Isolate the Problem
Divide the operation into those parts that are working and those that are not
Theorize about where the problem is located
Gather more information if needed
Limit the number of untested assumptions you make
Eliminate as many possibilities as you can to focus on the failing part

16. Debugging Step #5: Reassess
If you reached a dead end, or you tried a fix that didn't work
Look at the information you know again
Ask where you might have made incorrect assumptions
Step through the process again

17. Debugging Step #6: Step through the Process from Start to Finish
Make predictions about what should happen
Test your predictions
Verify the results
Compare what should be happening with what you observe is happening

18. 1.3 Debugging an HTML Page: A Case Study
Imagine we've been asked to create an HTML page
We know what that page is supposed to look like
The HTML we have written isn't displaying properly (this "buggy" HTML code can be found at pearsonhighered.com/cs- resources)

19. Figure 6.3 The Target Page
The target page displayed (correctly) with the Firefox web browser.

20. Figure 6.4 The Incorrect Page in Firefox
The buggy page displayed with Firefox; notice the differences with Figure 6.3.

21. Figure 6.3 Our (Partial) Buggy HTML Code
The buggy HTML (this file is also found at pearsonhiighered.com/cs-resources).

22. Debugging HTML
Begin by looking at the output (the display of the incorrect HTML) across multiple browsers
Open the HTML code file with different web browsers
Note that the four browsers display the buggy page differently, but should show the page exactly the same
Sometimes it's easier to find a specific bug by comparing how different browsers display it

23. Debugging HTML: Reproduce the Error
Now that we know there are bugs, follow the debugging steps
Recall that the first step is to reproduce the error, so close the browser and reopen the file
We still see the errors

24. Debugging HTML: Determine the Exact Problem
Review the displayed page
When there are multiple bugs, pick one to concentrate on
Begin with the missing book cover image

25. Debugging HTML: Check the Obvious
What are the most obvious problems with a missing image?
The file is not where it should be, so the browser can’t find it
Check to see that the image is in the pic folder, which it is
Misspelling the filename
Note that pic is not in the path:
<img src="jjkKindGrace.jpg" alt="JJK Autobiography" width="100" style="float: right;" />
Once the path is fixed, the image appears

26. Debugging HTML: Isolate the Problem(s)
Keep looking for what's working and what isn't
Focus on one problem at a time
If removing an element restores other formatting, then we have found the element that is stopping the styling
Also check any removed elements for typos, matching braces, closing semicolons, etc.

27. Debugging HTML: Reassess and Step Through
Once some bugs are fixed, others may be revealed
Reassess your work as you go, checking for incorrect assumptions
Step through the debugging process again, until your predicted output matches the actual output
Review your debugged page against the debug review in the book

28. 1.4 Debugging a System You May Not Understand
There are many complex steps between you computer and a printer to get documents to print
What do you do when you try to print something, and nothing happens?
Reproduce the error,
Understand the problem, and
Check the obvious causes

29. Debugging Printer Output: First Steps
Reproduce the error
Trying again to print the same document doesn't work
Determine the exact problem
Any other issues that have happened after the printing problem need to be eliminated
Check the obvious
checking the printer’s control panel, the paper, the cartridges, the cable connections, the file to be printed, the installation of the printer driver

30. Debugging Printer Output: Next Steps
Isolate the problem
Can others print to this printer?
Can you print a different document?
If you use a different printer, can you print the document?
If you unplug the printer entirely and try to print, do you get any warning messages?
Reassess and go through the steps again, checking and testing your assumptions

31. Debugging Printer Output: Review
Even if you weren't sure of some of the processes involved in printing, using debugging to isolate the problem and eliminate possible solutions can still result in success

32. 1.5 Ensuring Software Reliability
Software contains bugs, and crashes or unexpected behavior can be frustrating
Most errors are just an annoyance, but what about computers that control critical systems, like life support, airplane flight, nuclear power plant monitors, missile guidance, etc.?
Errors in critical systems are potentially much more serious

33. Software Runs on Hardware, Which Can Fail
Hardware can fail, but there are some preventive actions that can be taken:
Redundancy, where multiple computers in a safety- critical system can perform computations, is one fix
Burn-in, where a computer is initialized and allowed to run for a short time before it is put into critical service
Most errors show up after few hours of operation
A computer that has a record of successful operation is likely to continue to operate successfully

34. What About Software? Programmers begin with a specification
The specification doesn’t say how the behavior is to be achieved, just what it should be
Using sample inputs, outputs can be checked against the specification
If they do not match, there is a bug and the program must be fixed
A program is said to be correct if its behavior exactly matches its specification

35. Software Failures We can't prove a program's specification is correct
We can't establish the correctness of a program by testing
We can't say for sure we've eliminated every bug
Which means we can't know if a program is correct, even if it is

36. Software Failures: What Can We Do?
What about the fact that we can’t prove that software is correct?
Accept that software may contain bugs
However, poorly tested software is simply unprofessional
Be cautious and informed users, and take our business to those who produce the best product
For critical systems, consider safe software

37. Safe Software
Safe software changes the focus from worry about program correctness to concern about the consequences
Testing gives confidence that software works under normal circumstances
Since it is difficult to test software under unusual circumstances, the emphasis shifts to how software handles those circumstances

38. Two Designs: Fail-Soft and Fail-Safe Software
Fail-soft means that the program continues to operate, providing a possibly degraded level of functionality
Fail-safe means that the system stops functioning to avoid causing harm
The strategy is to continue to operate as long as service is safely provided

39. Software Reliability: Community Debugging
Another way to improve software reliability is to use community debugging
If your problem has surfaced before, then a web search should locate a place where the solution is discussed
If you can't find the solution to your specific problem, asking the community is a good tactic to keep in mind

40. Summary
We learned:
The importance of accuracy and precision in computing
The six-step debugging strategy works for both simple and complex problems, even when we don't know how a system works
Making safe and reliable computing systems is challenging, and requires both debugging and design approaches to have the right approach