1. Debugging Mohammad Zikky, M.T

2. 2 Debugging Introduction (1 of 2)  Debugging is methodical process for removing mistakes in a program  So important, whole set of tools to help. Called "debuggers"  Trace code, print values, profile  Integrated Development Environments (IDEs) (such as Flash and Game Maker) have one built in  A good debugger is really useful...

3. 3 Debugging Introduction (2 of 2)  But debugging still frustrating  Beginners don't know how to proceed  Even advanced can get "stuck"  Don't know how long it takes to find  Variance can be high  But can treat them in aggregate for predictions  What are some tips?  What methods can be applied? IMGD 1001

4. 4 Outline  Five-step debugging process  Prevention  Debugging tips IMGD 1001

5. 5 Similar steps to Scientific Method  Evaluation  Conjecture/speculation  Deduction  Test  check, repeat  Let’s do one IMGD 1001

6. 6 The Problem: Bubble Sort  We need a routine to sort a list  Algorithm:  Compare adjacent entries in the list  If they’re out of order, swap them  Move on to the next pair  Repeat until the list is sorted  Yes, this is vague  But you might be lucky to get this much description of an algorithm in your code! IMGD 1001

7. 7 Work Through …  Consider array: 3512  Evaluate, then Conjecture/Deduction, then Fix, then Test IMGD 1001

8. 8 The Five Step Debugging Process 1. Reproduce the problem consistently 2. Collect clues 3. Pinpoint the error 4. Repair the problem 5. Test the solution

9. 9 Step 1: Reproduce the Problem Consistently Sample repro steps: 1. Start a single player game 2. Choose Skirmish/fighting on map 44 3. Find the enemy camp 4. From a distance, use projectile weapons to attack the enemies at the camp 5. Result: 90 percent of the time the game crashes

10. 10 Step 2: Collect Clues  Each clue a chance to rule out a cause  Projectile weapons, distance  Each clue a chance to narrow down the list of suspects  Collision detection system, vectors?  Realize that some clues can be misleading and should be ignored  Skirmish mode...

11. 11 Step 3: Pinpoint the Error Two main methods: 1. Propose a Hypothesis  You have an idea what is causing the bug  Design tests to prove or disprove your hypothesis 2. Divide and Conquer  Narrow down what could be causing the bug  Eliminate possibilities from the top down or  Backtrack from the point of failure upward  Turn off parts, asserts, traces

12. 12 Step 4: Repair the Problem  Propose solution  Consider implications at point in project  Programmer who wrote the code should ideally fix the problem (or at least be consulted)  Explore other ways the bug could occur  Ensure underlying problem fixed and not just a symptom of the problem

13. 13 Step 5: Test the Solution  Verify the bug was fixed  Check original repro steps  Ideally have someone else independently verify the fix  Make sure no new bugs were introduced  At the very end of the project, have other programmers review the fix

14. 14 Expert Debugging Tips  Question assumptions  Minimize interactions and interference  Minimize randomness  Break complex calculations into steps  Check boundary conditions  Disrupt parallel computations  Exploit tools in the debugger  Check code that has recently changed  Explain the bug to someone else  Debug with a partner  Take a break from the problem  Get outside help

15. 15 Tough Debugging Scenarios  Bug exists in Release but not Debug  Uninitialized data or optimization issue  Bug exists on final hardware, not dev-kit  Find out how they differ – usually memory size or disc emulation  Bug disappears when changing something innocuous  Timing or memory overwrite problem  Intermittent problems  Record as much info when it does happen  Unexplainable behavior  Retry, Rebuild, Reboot, Reinstall  Internal compiler errors  Full rebuild, divide and conquer, try other machines  Suspect it’s not your code  Check for patches, updates, or reported bugs  Contact console maker, library maker, or compiler maker

16. 16 Understanding the Underlying System  Knowing C or C++ not enough  Know how the compiler implements code  Know the details of your hardware  Especially important for console development  Know how assembly works and be able to read it  Helps with optimization bugs or compiler issues

17. 17 Adding Infrastructure to Assist in Debugging  Alter game variables during gameplay  Visual AI diagnostics  Logging capability  Recording and playback capability  Track memory allocation  Print as much information as possible on a crash  Educate your entire team  testers, artists, designers, producers

18. 18 Prevention of Bugs  Set compiler to highest warning level  Set compiler warnings to be errors  Compiler on multiple compilers  Write your own memory manager  Use asserts to verify assumptions  Initialize variables when they are declared  Bracket loops and if statements  Use cognitively different variable names  Avoid identical code in multiple places  Avoid magic (hardcoded) numbers  Verify code coverage when testing