Debugging !!! ? PowerPoint PPT Presentation

presentation player overlay
1 / 20
About This Presentation
Transcript and Presenter's Notes

Title: Debugging !!! ?


1
(No Transcript)
2
(No Transcript)
3
Debugging !!! ?
  • Believe it or not, errors happen
  • The most frustrating part of programming
  • Hunting down an error can be harder and more time
    consuming than the solution to the original
    problem
  • Debugging tools and methodologies are still in
    their infancy
  • Its still an art form must be done manually
  • Cant tell you how to be Da Vinci, but can
    certainly give you a brush and some paint

4
Just use a debugger!
  • Unfortunately, we dont live in that perfect
    world just yet
  • Several problems with debuggers
  • May not be available for several reasons
  • Dont work for complex systems like distributed
    computing
  • Its just plain confusing sometimes
  • Can be thought of more as reverse engineering
    than a straight forward process

5
Methodology
  • Use your brain not your fingers
  • Keep it simple initially
  • Look for simple solutions first
  • The most likely culprit will usually be it
  • Move on to more complex solutions
  • For the most part, try and assume the computer is
    doing its job. Its not wrong
  • There are different kinds of bugs to look for

6
Kinds of Errors
  • Compile time errors
  • Usually pointed out to you, easy to fix
  • Syntactical errors
  • Run time errors
  • System Errors Out of bounds, class cast
    exception, null pointer exception
  • Logic Errors No visible errors, you just get
    the wrong answer
  • Causes of Errors
  • Flawed Logic (semantics)
  • Typos (syntactical)

7
Thought Process
  • Its not working now what?
  • Make sure it is actually a bug
  • Was your solution model flawed?
  • Are you printing what you want to print?
  • Did you forget to save / correct version?
  • Libraries are up to date?
  • Did you forget to end a comment?
  • Was there a crucial input missing?

8
Easy Bugs Lots of Clues
  • How to look for clues?
  • Tip Avoid writing too much before running
  • Did a recent change break the code?
  • Have you seen this bug before? What did you do in
    the past to fix it?
  • Think first, write down on paper what is going on
  • A second set of eyes might be able to see what
    you are missing. You have been staring at it so
    long you might miss something simple.

9
More complex problems
  • Might be system specific, check manuals
  • Narrow down inputs which reproduce the bug. If
    you know which inputs make it fail you can
    pinpoint where the error may be.
  • Are you close to data type limits?
  • Look for suspicious values Powers of 2, weird
    ASCII (more applicable in other languages)
  • Are your data structures valid?
  • Does taking out bits of code make it work?
  • Inserting print statements

10
Foreign/Old Code
  • Get a copy of the design / problem statement
  • Work it out by hand first
  • Group their functions into small bits of readable
    English Formats text, Convert hex to binary
  • Know what it all does before attempting to fix it
  • Sadly Complete rewrites often faster than
    debugging other peoples code
  • Look for examples of hard coding declared
    strings, integers, counters which are defined
    instead of read as input

11
The Art of Print Statements
  • System.out.println(UUUUUUUUUUUUUGH)
  • System.out.println(YESSSSSSSSSSSSSSSS)
  • Usually best way to find errors in small systems,
    especially number-based
  • Things to print
  • Counter values
  • Min/Max values
  • Array indices
  • Data structure values
  • Where to print
  • Before / after declarations/initializations
  • Before / after function calls
  • Before / after entering loops / recursion
  • Before breaking from a loop

12
Java Specific
  • Always give your objects a .toString() or a
    .toDebug() method
  • Make use of Arrays.toString() etc
  • print(Index value) in loops
  • Use iterators where possible
  • Instead of setting your own parameters for a
    prebuilt class, override it
  • If building GUI/JS, use System.err.println()

13
Examples
  • NullPointerExceptions
  • Print statement after initialization or
    immediately before passing into functions
  • ArrayOutOfBounds
  • Lucky if you are using java that they are thrown
  • Print index counters, array values
  • Infinite Loops
  • Do searches for index counter names/updates
  • Wrong answers
  • Go over it again by hand, your solution probably
    is not correct in the first place. Put the code
    on hold

14
Example Mathematics
  • Sine and Cosine mixed up?
  • Negative values?
  • Values close to zero / rounding errors?
  • Adding small values to large values
  • Reversing min / max values?
  • Pass by reference / value?
  • Loops correct?

15
Examples (ctd)
  • Loops / Conditionals
  • Are your counters in the right order?
  • counter vs. counter
  • Multi dimensional do it by hand first
  • Make sure bracketing matches with indenting
  • Copy / Paste changes

16
Life Lessons
  • Format of a file is not standard ascii
  • Format of a file is little endian instead of big
    endian
  • Naming conventions actually matter in fortran
  • Programming in C for the first time arrays do
    not initialize

17
Reverse Engineering
  • Start from the error and work backwards
  • Make sure all your parts work before testing the
    system as a whole
  • Surround the affected area with output
    information / line breaks
  • Edit lines of fluff code out to test the meat
  • Experiment with different input values
  • Fix the code line by line

18
Debugger
  • Built into Eclipse for java
  • GUI / Text based, same idea
  • Only used as a last resort, very time consuming
  • Allow for insertion of break lines to halt code
    execution at any point
  • Allow you to see the contents of any object /
    array / primitive at any time by query
  • Amount of data shown often overwhelming
  • Doesnt provide insight into logical error
  • Still a manual process to find errors

19
How to avoid
  • Dont write 1000 lines before testing
  • Variable names can have meaning
  • Dont hard code ANYTHING. If you must, define all
    of them in the same place where they are easily
    seen / changed
  • Comment everywhere it isnt obvious
  • If its more than a few lines put it in a
    function
  • Always use

20
Personal Horror Stories
  • if (conditional which ran longer than the width
    of my screen)
  • break
  • while (index lt end)
  • go from the end of a string to the front
  • index index -1
  • for (int i0 iltx i) for (int j0 jlty i)
  • Forgot about a hard coded nn matrix read
  • Drew background last in graphics class
  • Spent 4 hours debugging because C didnt flush a
    buffer
  • Tried to do anything in fortran or prolog
Write a Comment
User Comments (0)
About PowerShow.com