Eric Roberts Handout #9CS 106B April 6, 2009Debugging C++Parts of this handout were written by Julie Zelenski.As soon as we started programming, we found to our surprise thatit wasn’t as easy to get programs right as we had thought. We hadto discover debugging. I can remember the exact instant when Irealized that a large part of my life from then on was going to bespent in finding mistakes in my own programs.— Maurice Wilkes, 1949The purpose of this handout is twofold: to give you a sense of the philosophy ofdebugging and to teach you how to use some of the practical tools that make debuggingeasier. To become an expert debugger, you will need to learn how to use the debuggerenvironment that comes with your programming environment. The details of using adebugger differ enormously from system to system. This handout, therefore, issupplemented with two specialized handouts on the web site: one for debugging withXcode (Handout #9M) and one for debugging with Visual Studio (Handout #9P). Evenso, it is even more important that you understand how to employ general debuggingstrategies that transcend any particular platform.The philosophy of debuggingWith method and logic one can accomplish anything.— Agatha Christie, Poirot Investigates, 1924Debugging is one of the most creative and intellectually challenging aspects ofprogramming. It can also be one of the most frustrating. To a large extent, the problemsthat people face debugging programs are not so much technical as they are psychological.To turn you into successful debuggers, I have to get you to think in a different way.There is no cookbook approach to debugging, although Nick Parlante’s rules in Figure 1will probably help. What you need is insight, creativity, logic, and determination.The programming process leads you through a series of tasks and roles:Design — ArchitectCoding — EngineerTesting — VandalDebugging — DetectiveThese roles require you to adopt distinct strategies and goals, and it is often difficult toshift your perspective from one to another. Although debugging is extremely difficult, itcan be done. It will at times take all of the skill and creativity at your disposal, but youcan succeed if you are methodical and don’t give up on the task.Debugging is an important skill that you will use every day if you continue in computerscience or any related field. Even though it is the last of the tasks in the list, it is certainlynot the least important. Debugging will almost always require more time than the firstthree tasks combined. Therefore, you should always plan ahead and allow sufficient timefor testing and debugging, as it is required if you expect to produce high-quality software.In addition, you should make a concentrated effort to develop these skills now, as theywill be even more important as programs become more complicated later in the quarterand if you do any programming in your career.– 2 –Figure 1. The Eleven Truths of Debugging1. Intuition and hunches are great—you just have to test them out. When a hunchand a fact collide, the fact wins.2. Don’t look for complex explanations. Even the simplest omission or typo can leadto very weird behavior. Everyone is capable producing extremely simple and obviouserrors from time to time. Look at code critically—don’t just sweep your eye over thatseries of simple statements assuming that they are too simple to be wrong.3. The clue to what is wrong in your code is in the values of your variables and theflow of control. Try to see what the facts are pointing to. The computer is not trying tomislead you. Work from the facts.4. Be systematic. Be persistent. Don’t panic. The bug is not moving around in yourcode, trying to trick or evade you. It is just sitting in one place, doing the wrong thingin the same way every time.5. If you code was working a minute ago, but now it doesn’t—what was the last thingyou changed? This incredibly reliable rule of thumb is the reason your section leadertold you to test your code as you go rather than all at once.6. Do not change your code haphazardly trying to track down a bug. This is sort oflike a scientist who changes more than one variable at a time. It makes the observedbehavior much more difficult to interpret, and you tend to introduce new bugs.7. If you find some wrong code which does not seem to be related to the bug youwere tracking, fix the wrong code anyway. Many times the wrong code was related toor obscured the bug in a way you had not imagined.8. You should be able to explain in Sherlock Holmes style the series of facts, tests,and deductions which led you to find a bug. Alternately, if you have a bug but can’tpinpoint it, then you should be able to give an argument to a critical third partydetailing why each one of your procedures cannot contain the bug. One of thesearguments will contain a flaw since one of your procedures does in fact contain a bug.Trying to construct the arguments may help you to see the flaw.9. Be critical of your beliefs about your code. It’s almost impossible to see a bug in aprocedure when your instinct is that the procedure is innocent. In that case, only whenthe facts have proven without question that the procedure is the source of the problemwill you be able to see the bug.10. You need to be systematic, but there is still an enormous amount of room forbeliefs, hunches, guesses, etc. Use your intuition about where the bug probably is todirect the order that you check things in your systematic search. Check the proceduresyou suspect the most first. Good instincts will come with experience.11. Debugging depends on an objective and reasoned approach. It depends on overallperspective and understanding of the workings of your code. Debugging code is morementally demanding than writing code. The longer you try to track down a bug withoutsuccess, the less perspective you tend to have. Realize when you have lost theperspective on your code to debug. Take a break. Get some sleep. You cannot debugwhen you are not seeing things clearly. Many times a programmer can spend hours lateat night hunting for a bug only to finally give up at 4:00A.M. The next day, they find thebug in 10 minutes. What allowed them to find the bug the next day so quickly? Maybethey just needed some sleep and time for perspective. Or maybe their subconsciousfigured it out while they were asleep. In any case, the “go do something else for awhile, come