Debugging Bugs Sources of Bugs Debugging in Software Engineering

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.

Load more