DebuggingBugsSources of BugsDebugging in Software EngineeringWays NOT to DebugAn Approach to Debugging1. Stabilize the Error1. Stabilizing the Error2. Locate the SourceWhen it’s Tough to Find SourceFinding Error LocationsAlternative to Finding Specific Source3. Fix the DefectFixing the Code4. Check Your Fix5. Look for Similar ErrorsPreventing Bugs Or Finding Difficult OnesDebugging ToolsNon-traditional Debugging ToolsDebuggingCPSC 315 – Programming StudioSpring 2009BugsTerm has been around a long timeMark I – moth in machineMistake made by programmersAlso (and maybe better) called:ErrorsDefectsFaultsSources of BugsBad DesignWrong/incorrect solution to problemFrom system-level to statement-levelInsufficient IsolationChanges in one area affect anotherTyposEntered wrong text, chose wrong variableLater changes/fixes that aren’t completeA change in one area affects anotherDebugging in Software EngineeringProgrammer speed has high correlation to debugging speedBest debuggers can be more than to 10 times as fastFaster finding bugsFind more bugsIntroduce fewer new bugsWays NOT to DebugGuess at what’s causing itDon’t try to understand what’s causing itFix the symptom instead of the causeSpecial case codeBlame it on someone else’s codeOnly after extensive testing/proofBlame it on the compiler/computerYes, it happens, but almost never is this the real causeAn Approach to Debugging1. Stabilize the error2. Locate the source3. Fix the defect4. Test the fix5. Look for similar errorsGoal: Figure out why it occurs and fix it completely1. Stabilize the ErrorFind a simple test case to reliably produce the errorNarrow it to as simple a case as possibleSome errors resist thisFailure to initializePointer problemsTiming issues1. Stabilizing the ErrorConverge on the actual (limited) errorBad: “It crashes when I enter data”Better: “It crashes when I enter data in non-sorted order”Best: “It crashes when I enter something that needs to be first in sorted order”Create hypothesis for causeThen test hypothesis to see if it’s accurate2. Locate the SourceThis is where good code design helpsAgain, hypothesize where things are going wrong in code itselfThen, test to see if there are errors coming in thereSimple test cases make it easier to checkWhen it’s Tough to Find SourceCreate multiple test cases that cause same errorBut, from different “directions”Refine existing test cases to simpler onesTry to find source that encompasses all errorsCould be multiple ones, but less likelyBrainstorm for sources, and keep list to checkTalk to othersTake a breakFinding Error LocationsProcess of eliminationIdentify cases that work/failed hypothesesNarrow the regions of code you need to checkUse unit tests to verify smaller sectionsProcess of expansion:Be suspicious of:areas that previously had errorscode that changed recentlyExpand from suspicious areas of codeAlternative to Finding Specific SourceBrute Force Debugging“Guaranteed” to find bugExamples:Rewrite code from scratchAutomated test suiteFull design/code reviewFully output step-by-step statusDon’t spend more time trying to do a “quick” debug than it would take to brute-force it.3. Fix the DefectMake sure you understand the problemDon’t fix only the symptom (e.g. no magic “subtract one here” fixes)Understand what’s happening in the program, not just the place the error occurredUnderstand interactions and dependenciesSave the original codeBe able to “back out” of changeFixing the CodeChange only code that you have a good reason to changeDon’t just try things till they workMake one change at a time4. Check Your FixAfter making the change, check that it works on test cases that caused errorsThen, make sure it still works on other casesRegression testAdd the error case to the test suite5. Look for Similar ErrorsThere’s a good chance similar errors occurred in other parts of programBefore moving on, think about rest of programSimilar routines, functions, copied codeFix those areas immediatelyPreventing BugsOr Finding Difficult OnesGood DesignSelf-Checking codeOutput optionsPrint statements can be your friend…Debugging ToolsDebuggersOften integratedCan examine state in great detailDon’t use debuggers to do “blind probing” Can be far less productive than thinking harder and adding output statementsUse as “last resort” to identify sources, if you can’t understand another wayNon-traditional Debugging ToolsSource code comparators (diff)Compiler warning messagesExtended syntax/logic checkersProfilersTest