Bugs

 Term has been around a long time Debugging − Edison − Mark I – moth in machine  Mistake made by programmers  Also (and maybe better) called: − Errors CPSC 315 – Programming Studio − Defects Fall 2011 − Faults

Debugging in Software Sources of Bugs Engineering  Bad Design  Programmer speed has high − Wrong/incorrect solution to problem correlation to debugging speed − From system-level to statement-level − Best debuggers can go up to 10 times  Insufficient Isolation faster − Changes in one area affect another  Typos  Faster finding bugs − Entered wrong text, chose wrong variable  Find more bugs  Later changes/fixes that aren’t complete  − A change in one area affects another Introduce fewer new bugs Ways NOT to Debug An Approach to Debugging

 Guess at what’s causing it 1. Stabilize the error  Don’t try to understand what’s causing it 2. Locate the source  Fix the symptom instead of the cause 3. Fix the defect − Special case code 4.  Blame it on someone else’s code Test the fix − Only after extensive testing/proof 5. Look for similar errors  Blame it on the compiler/computer − Yes, it happens, but almost never is this the real Goal: Figure out why it occurs and fix cause it completely

1. Stabilize the Error 1. Stabilizing the Error

 Find a simple test case to reliably  Converge on the actual (limited) error produce the error − Bad: “It crashes when I enter data” − Narrow it to as simple a case as possible − Better: “It crashes when I enter data in  Some errors resist this non-sorted order” − − Failure to initialize Best: “It crashes when I enter something that needs to be first in sorted order” − Pointer problems  − Timing issues Create hypothesis for cause − Then test hypothesis to see if it’s accurate When it’s Tough to Find 2. Locate the Source Source  This is where good code design helps  Create multiple test cases that cause same error  Again, hypothesize where things are − But, from different “directions” going wrong in code itself  Refine existing test cases to simpler ones − Then, test to see if there are errors  Try to find source that encompasses all coming in there errors − Simple test cases make it easier to check − Could be multiple ones, but less likely  Brainstorm for sources, and keep list to check  Talk to others  Take a break

Alternative to Finding Specific Finding Error Locations Source

 Process of elimination  Brute Force Debugging − Identify cases that work/failed hypotheses − “Guaranteed” to find bug − Narrow the regions of code you need to check − Examples: − Use unit tests to verify smaller sections  Rewrite code from scratch  Automated test suite  Process of expansion:  Full design/code review − Be suspicious of:  Fully output step-by-step status  areas that previously had errors  Don’t spend more time trying to do a “quick”  code that changed recently debug than it would take to brute-force it. − Expand from suspicious areas of code 3. Fix the Defect Fixing the Code

 Make sure you understand the problem  Change only code that you have a − Don’t fix only the symptom good reason to change  Understand what’s happening in the − Don’t just try things till they work program, not just the place the error  Make one change at a time occurred − Understand interactions and dependencies  Save the original code − Be able to “back out” of change

4. Check Your Fix 5. Look for Similar Errors

 After making the change, check that it  There’s a good chance similar errors works on test cases that caused errors occurred in other parts of program  Then, make sure it still works on other  Before moving on, think about rest of cases program − Regression test − Similar routines, functions, copied code − Add the error case to the test suite − Fix those areas immediately Preventing Bugs Debugging Tools Or Finding Difficult Ones  Good Design  Debuggers − Often integrated  Self-Checking code − Can examine state in great detail  Output options  Don’t use debuggers to do “blind probing” − Print statements can be your friend… − 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 way

Non-traditional Debugging Tools  Source code comparators (diff)  Compiler warning messages  Extended syntax/logic checkers  Profilers  Test frameworks