When it’s Tough to Find Source - ecology lab



DebuggingAbout Debugging(the point of this lecture)Debugging is not a random processYou can approach debugging systematicallyBugsTerm has been around a long timeEdisonMark I – moth in machineMistake made by programmersAlso (and maybe better) called:ErrorsDefectsFaultsSources of BugsBad DesignWrong/incorrect solution to problemFrom system-level to statement-level Insufficient IsolationChanges in one area affect anotherTyposEntered wrong text, chose wrong variableLater changes/fixes that aren’t completeEspecially problem with insufficient isolationChange process gets interrupted, or not all effects are consideredDebugging in Software EngineeringProgrammer speed has high correlation to debugging speedBest debuggers can go up to 10 times fasterFaster 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 causeSpecial case codeBlame it on someone else’s codeOnly after extensive testing/proofBlame it on the compiler/computerYes, it happens, but almost never is this the real causeStudent Debugging (what I’ve heard)Something’s not workingI don’t know why my code’s not working I tried changing x and y and it seemed to make it work but this other part’s broken My code keeps giving me the wrong thing here and I don’t understand whyI didn’t really understand that part of the codeAn Orderly Approach to DebuggingStabilize the errorLocate the sourceFix the defectTest the fixLook for similar errorsGoal: Figure out why it occurs and fix it completelyStabilize the ErrorFind a simple test case to reliably produce the errorNarrow it to as simple a case as possibleSome errors resist thisFailure to initializePointer problemsTiming issuesConverge on the actual (limited) errorBad: “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 causeThen test hypothesis to see if it’s accurateLocate the SourceThis is where good code design helps Again, hypothesize where things are going wrong in code itselfThen, test to see if there are errors coming in thereSimple test cases make it easier to checkWhen it’s Tough to Find SourceCreate multiple test cases that cause same errorBut, from different “directions”Refine existing test cases to simpler onesTry to find source that encompasses all errorsCould be multiple ones, but less likelyBrainstorm for sources, and keep list to checkTalk to othersTake a breakFinding Error LocationsProcess of eliminationIdentify cases that work/failed hypothesesNarrow the regions of code you need to checkUse unit tests to verify smaller sections Process of expansion:Be suspicious of:areas that previously had errorscode that changed recentlyExpand from suspicious areas of codeAlternative to Finding Specific SourceBrute Force Debugging“Guaranteed” to find bug Examples:Rewrite code from scratchAutomated test suiteFull design/code reviewFully output step-by-step statusDon’t spend more time trying to do a “quick” debug than it would take to brute-force it.Fix the DefectMake sure you understand the problemDon’t fix only the symptomUnderstand what’s happening in the program, not just the place the error occurredUnderstand interactions and dependenciesSave the original codeBe able to “back out” of changeChange only code that you have a good reason to changeDon’t just try things till they workMake one change at a timeWhen Checking Your FixAfter making the change, check that it works on test cases that caused errors Then, make sure it still works on other casesRegression testAdd the error case to the test suiteLook for Similar ErrorsThere’s a good chance similar errors occurred in other parts of program Before moving on, think about rest of programSimilar routines, functions, copied codeFix those areas immediatelyPreventing Bugs Or Finding Difficult OnesGood DesignSelf-Checking codeAssert statementsOutput optionsPrint statements can be your friend…Debugging ToolsDebuggersOften integratedCan examine state in great detailDon’t use debuggers to do “blind probing”Can be far less productive than thinking harder and adding output statementsUse 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 frameworksSourceJohn Keyser and Tanzir ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download