The Art Of Debugging

3,620 views
3,395 views

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,620
On SlideShare
0
From Embeds
0
Number of Embeds
54
Actions
Shares
0
Downloads
499
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

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>

×