Unformatted text preview:

September 5, 2007 ©2006 Craig Zilles (adaptedfrom slides by Howard Huang)1CS232: Computer Architecture IIFall 2007Avg Time to do MP05101520253035400-1 2-3 4-5 6-7 8-9 10-11Time (hrs)StudentsMP[12] averageSome data from a previous semesterSeptember 5, 2007 Introduction to CS232 2 Have you ever monitored the time you spent on doing your MPs?— And account for time for each type of activity? If so, what do you spend the bulk of your time doing?— (If not, you should; metacognition is important in problem solving)What is responsible for distribution?September 5, 2007 Introduction to CS232 31. Learn necessary material (i.e., attend lecture/section, read book)— May need to revisit after the steps below2. Read (and understand) problem statement3. Plan solution4. Write solution5. Debug solution(Approximate) Problem solving stepsSeptember 5, 2007 Introduction to CS232 4 Debugging isn’t some magical innate characteristic It is a set of tricks that can be learned, practiced and refined.— There are good and bad methodologies— Structured vs. Ad-hoc approaches What follows is a list of tricks from a book entitled:“DEBUGGING: The 9 Indispensable Rules for Finding Even the MostElusive Software and Hardware Problems,” David J. Agans— It is a light read (takes just a couple hours).— If you are spending many hours debugging your MP’s it is probably avery good investment.Debugging is a skill (that can be learned)January 22, 2003 Introduction to CS232 5September 5, 2007 Introduction to CS232 6 Know the fundamentals: That is what I try to give you in lecture, butthat is meant to ease not replace RTFMing. RTFM: Read the documentation for the system that you are workingwith. What you might think is a bug, is actually the correct behavior ofthe system (you might be using it improperly because you don’t knowwhat it is supposed to do).— Read and understand the code we hand out. Look up the details: when you need to use “mul” look it up to seeexactly how it works. Know your tools: learn how to use a debugger.Rule #1: Understand the SystemSeptember 5, 2007 Introduction to CS232 7 Do it again: You need to be able to reproduce the bug to study it (findwhen it occurs) and to be able verify that you fixed it. Stimulate the failure: Spray a hose on a leaky window so you can seewhere it leaks. Start at the beginning: Understand everything that happened that leadto the bug.Rule #2: Make it FailSeptember 5, 2007 Introduction to CS232 8 See the failure: Don’t guess at the source of a bug, actually inspect thesystem to see the bug happening. Build in Instrumentation: Add code in that spits out intermediate statesso you can see when bad things happen. Guess only to focus the search: Go ahead and guess to make the searchfaster, but see the bug before you fix the bug.Rule #3: Quit Thinking and LookSeptember 5, 2007 Introduction to CS232 9 Use a binary search: Guess a number between 1 and 100 with 7 guesses. Determine which side of the bug you are on: If the state is bad whereyou are checking, the bug is upstream. Fix the bugs you know about: Bugs defend and hide one another.Take’em out as soon as you find them.Rule #4: Divide and ConquerSeptember 5, 2007 Introduction to CS232 10 Be Scientific: Change one thing and observe the change in the output. Ifyou change many things at once, you can’t isolate each change’s impact. Grab the Brass Bar: Fully understand the bug, before you changeanything. Random changes are more likely to break things than fix them. Change one test at a time: Undo the first change before making thesecond change, so that you have only one change at a time. What did you change since the last time it worked: If somethingworked before, the bug is probably in what has changed since it worked.Rule #5: Change one Thing at a TimeSeptember 5, 2007 Introduction to CS232 11 Write down: what you did, in what order, and what happened as aresult.Rule #6: Keep an Audit TrailSeptember 5, 2007 Introduction to CS232 12 Question your assumptions: Make sure that your divide-and-conquer istesting the whole space. Start at the beginning: Did you turn it on? Did you initialize everything?Are the inputs good? Test the tool: Are you running the right compiler?Rule #7: Check the PlugSeptember 5, 2007 Introduction to CS232 13 Ask for fresh insights: Sometimes just explaining a problem to someoneelse can help you identify hidden assumptions and possible bug sources. Tap expertise: Go to office hours. Work with fellow students (this iswhy we let you work in groups on the MPs). Report symptoms, not theories: Don’t drag a crowd into your rut. Also,your symptoms need to be more detailed than “it doesn’t work.” Nothing is too unimportant to be mentioned: When explaining theproblem try not to filter out what you deemed as unimportant; the factthat you think it is unimportant might be why you haven’t found the bug.Rule #8: Get a Fresh ViewSeptember 5, 2007 Introduction to CS232 14 Check that it is really fixed: If you followed “Make it fail” you can useyour reproducible test case to verify that it is working. Do so! Fix the process: If you notice that when you write code that you oftenget a certain kind of bug, think if there is a different approach thatavoids that kind of bug.Rule #9: If you didn’t fix it, it ain’t fixed.January 22, 2003 Introduction to CS232 15Finding a path through a maze.September 5, 2007 Introduction to CS232 16 (Insert instrumentation) Setting break points Observe execution state Watch code execute (and make sure it does what you think it should) Conditional break pointsLearn how to use a Debugger.September 5, 2007 Introduction to CS232 17How the class will be organized The textbook provides the most comprehensive coverage Lecture and section will present course material Section problems useful for gauging your understanding of the material— Weekly, graded on effort, and good practice for the exams Machine problems are more open-ended applications of course material— Due most weeks, graded, can be done in groups (1-3 people) Homeworks used for closed-form, quantitative problems— Due occasionally, graded Exams: three in-class midterms and one final See the syllabus:http://www.cs.uiuc.edu/class/cs232/html/info.html Questions?September 5, 2007 Introduction to CS232 18MP’s start next week!! MP#0 will be due


View Full Document

U of I CS 232 - Lecture notes

Documents in this Course
Goal

Goal

2 pages

Exam 1

Exam 1

5 pages

Exam 1

Exam 1

6 pages

Exam 2

Exam 2

6 pages

Exam 1

Exam 1

5 pages

Load more
Download Lecture notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?