Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Art Of Debugging

5,198 views

Published on

Published in: Technology
  • Be the first to comment

The Art Of Debugging

  1. 1. <ul><ul><li>The Art of Debugging </li></ul></ul><ul><ul><li>Svilen Ivanov </li></ul></ul><ul><ul><li>(svilen@netclime.com) </li></ul></ul>
  2. 2. Bugs and Debugging <ul><li>What are bugs, anyway? </li></ul><ul><ul><li>Bugs are undesirable behavior of the system </li></ul></ul><ul><ul><li>Bugs are requirements, architecture, design and implementation errors in software system </li></ul></ul><ul><li>Debugging is the process of understanding the behavior of the system to facilitate the removal of bugs </li></ul><ul><li>Why “bug”? </li></ul><ul><ul><li>A moth caught in a relay in a early computer system </li></ul></ul>
  3. 3. The Nature of the Bugs <ul><li>Bugs happen for a reason </li></ul><ul><li>Bugs are reproducible </li></ul><ul><ul><li>Sometimes “hard” but not impossible </li></ul></ul><ul><li>Bugs usually manifest themselves when there is a change </li></ul><ul><li>Bugs attract bugs </li></ul><ul><li>Bugs demonstrate lack of understanding </li></ul><ul><li>Hard codes are hard to write no matter what </li></ul><ul><ul><li>NVP – N-Version programming example </li></ul></ul>
  4. 4. Debugging Process <ul><li>The algorithm: </li></ul><ul><ul><li>Gather information </li></ul></ul><ul><ul><ul><li>personal observation; similar problems; interview with reporter </li></ul></ul></ul><ul><ul><ul><li>log files; environment; test cases that fail; recent changes </li></ul></ul></ul><ul><ul><li>Form a hypothesis </li></ul></ul><ul><ul><li>Test your hypothesis – don't assume it; prove it! </li></ul></ul><ul><ul><ul><li>You cannot accurately estimate the time it takes to fix the bug until you have verified a hypothesis for its cause </li></ul></ul></ul><ul><ul><li>Iterate until a proven hypothesis is found </li></ul></ul><ul><ul><li>Propose a solution. </li></ul></ul><ul><ul><li>Iterate until solution is proven </li></ul></ul><ul><ul><li>Regression test </li></ul></ul>
  5. 5. Psychology of Debugging <ul><li>Fix the problem, not the blame </li></ul><ul><li>A debugging mindset </li></ul><ul><ul><li>Don't panic! :) </li></ul></ul><ul><li>Where to start? </li></ul><ul><ul><li>Make sure the code compiles cleanly at highest warning level ( use strict; use warnings; use diagnostics; in Perl) </li></ul></ul><ul><ul><li>Gather all relevant data – you may need to interview the user who reported the bug to gather more data </li></ul></ul><ul><ul><li>Test boundary conditions brutally </li></ul></ul><ul><ul><li>Use realistic end-user usage patterns </li></ul></ul>
  6. 6. Debugging Strategies (1) <ul><li>Visualize your data </li></ul><ul><ul><li>Add simple trace statements </li></ul></ul><ul><ul><li>Use Data Display Debugger (ddd) </li></ul></ul>Original width [1024], height [768] Resizing [2] times New width [384], height [640]
  7. 7. Debugging Strategies (2) <ul><li>Tracing </li></ul><ul><ul><li>trace the program execution flow (when time is critical – concurrent processes, event-base applications) </li></ul></ul><ul><ul><li>use consistent format </li></ul></ul><ul><ul><ul><li>for example you can track automatically resource leaks </li></ul></ul></ul><ul><ul><li>Devel::StackTrace </li></ul></ul>Trace begun at AppLogic/UDL/Entity.pm line 256 AppLogic::UDL::Entity::Write('AppLogic::UDL::Entity=HASH(0x858e7f8)', 0, 0, 'ARRAY(0x8586b68)', 'HASH(0x82c3370)') called at AppLogic/ADL.pm line 861 AppLogic::ADL::SaveApplication('AppLogic::ADL=HASH(0x857eff0)', 'ikea-mini', 'HASH(0x827f3e4)') called at request.pl line 526 main::ModeSaveApp(1, 'HASH(0x8537ff8)', 'CGI::Session=HASH(0x84fc46c)') called at request.pl line 115
  8. 8. Debugging Strategies (3) <ul><li>Rubber ducking </li></ul><ul><ul><li>explain the problem to someone (something :) else </li></ul></ul><ul><ul><li>do not omit assumptions </li></ul></ul><ul><li>The bug is probably in your code </li></ul><ul><ul><li>it is possible that bug is in OS, compiler or third-party product – but this should not be your first though </li></ul></ul><ul><ul><li>start looking from the last change before system “stopped working” even it is not related to current problem </li></ul></ul><ul><ul><li>the fall back – binary search </li></ul></ul>
  9. 9. Debugging Strategies (4) <ul><li>Simplify the reproducibility </li></ul><ul><ul><li>easier to retry the test </li></ul></ul><ul><ul><li>lowers the features you check for correctness </li></ul></ul><ul><li>Leaps of Faith </li></ul><ul><li>Change one variable of the time </li></ul><ul><ul><li>otherwise you don't know which change fixed the problem </li></ul></ul><ul><ul><li>restore original before making new change </li></ul></ul><ul><li>Check recent changes </li></ul><ul><ul><li>check revision history, CVS log file </li></ul></ul><ul><ul><li>examine diff s of problematic areas </li></ul></ul><ul><ul><li>ask developers </li></ul></ul>
  10. 10. Debugging Strategies (5) <ul><li>Cleanup “dead code” in the system </li></ul><ul><ul><li>it is blindfolding you </li></ul></ul><ul><li>Question assumptions Result: </li></ul>my ($i, $j) = (1, 2); print_out_i_and_j($i, $j); $i += 3; $j += 4; print &quot;after: i=[$i] j=[$j] &quot;; print_out: i=[1] j=[2] after: i=[5] j=[5]
  11. 11. Debugging Strategies (6) <ul><li>Question assumptions - answer </li></ul><ul><li>Look at untested code </li></ul><ul><ul><li>Use code coverage to determine what's being used </li></ul></ul><ul><ul><li>checkout the Perl modules Test::Strict, Devel::Cover, Test::Pod::Coverage </li></ul></ul><ul><li>Code elimination </li></ul><ul><ul><li>you are admitting you haven't got the clue what is going on </li></ul></ul>sub print_out_i_and_j($$) { print &quot;print_out: i=[$_[0]] j=[$_[1]] &quot;; $_[0]++; # adjust offset in file $_[1]--; # adjust line count }
  12. 12. Debugging Checklist <ul><li>Is the problem being reported is a direct result from a bug or symptom? </li></ul><ul><li>Is the bug in th OS or in your code? </li></ul><ul><li>If the code passes unit test, are the tests complete? </li></ul><ul><li>Does the conditions that caused this bug exists else in the system? </li></ul>
  13. 13. What's Next <ul><li>How to learn from bugs </li></ul><ul><ul><li>improve testing, automation </li></ul></ul><ul><li>Risk management </li></ul><ul><li>Proper bug reporting </li></ul>

×