The Art of Debugging Svilen Ivanov (svilen@netclime.com)

The Art of Debugging

Svilen Ivanov

(svilen@netclime.com)

Bugs and Debugging What are bugs, anyway? Bugs are undesirable behavior of the system Bugs are requirements, architecture, design and implementation errors in software system Debugging is the process of understanding the behavior of the system to facilitate the removal of bugs Why “bug”? A moth caught in a relay in a early computer system

What are bugs, anyway?

Bugs are undesirable behavior of the system

Bugs are requirements, architecture, design and implementation errors in software system

Debugging is the process of understanding the behavior of the system to facilitate the removal of bugs

Why “bug”?

A moth caught in a relay in a early computer system

The Nature of the Bugs Bugs happen for a reason Bugs are reproducible Sometimes “hard” but not impossible Bugs usually manifest themselves when there is a change Bugs attract bugs Bugs demonstrate lack of understanding Hard codes are hard to write no matter what NVP – N-Version programming example

Bugs happen for a reason

Bugs are reproducible

Sometimes “hard” but not impossible

Bugs usually manifest themselves when there is a change

Bugs attract bugs

Bugs demonstrate lack of understanding

Hard codes are hard to write no matter what

NVP – N-Version programming example

Debugging Process The algorithm: Gather information personal observation; similar problems; interview with reporter log files; environment; test cases that fail; recent changes Form a hypothesis Test your hypothesis – don't assume it; prove it! You cannot accurately estimate the time it takes to fix the bug until you have verified a hypothesis for its cause Iterate until a proven hypothesis is found Propose a solution. Iterate until solution is proven Regression test

The algorithm:

Gather information

personal observation; similar problems; interview with reporter

log files; environment; test cases that fail; recent changes

Form a hypothesis

Test your hypothesis – don't assume it; prove it!

You cannot accurately estimate the time it takes to fix the bug until you have verified a hypothesis for its cause

Iterate until a proven hypothesis is found

Propose a solution.

Iterate until solution is proven

Regression test

Psychology of Debugging Fix the problem, not the blame A debugging mindset Don't panic! :) Where to start? Make sure the code compiles cleanly at highest warning level ( use strict; use warnings; use diagnostics; in Perl) Gather all relevant data – you may need to interview the user who reported the bug to gather more data Test boundary conditions brutally Use realistic end-user usage patterns

Fix the problem, not the blame

A debugging mindset

Don't panic! :)

Where to start?

Make sure the code compiles cleanly at highest warning level ( use strict; use warnings; use diagnostics; in Perl)

Gather all relevant data – you may need to interview the user who reported the bug to gather more data

Test boundary conditions brutally

Use realistic end-user usage patterns

Debugging Strategies (1) Visualize your data Add simple trace statements Use Data Display Debugger (ddd) Original width [1024], height [768] Resizing [2] times New width [384], height [640]

Visualize your data

Add simple trace statements

Use Data Display Debugger (ddd)

Debugging Strategies (2) Tracing trace the program execution flow (when time is critical – concurrent processes, event-base applications) use consistent format for example you can track automatically resource leaks Devel::StackTrace 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

Tracing

trace the program execution flow (when time is critical – concurrent processes, event-base applications)

use consistent format

for example you can track automatically resource leaks

Devel::StackTrace

Debugging Strategies (3) Rubber ducking explain the problem to someone (something :) else do not omit assumptions The bug is probably in your code it is possible that bug is in OS, compiler or third-party product – but this should not be your first though start looking from the last change before system “stopped working” even it is not related to current problem the fall back – binary search

Rubber ducking

explain the problem to someone (something :) else

do not omit assumptions

The bug is probably in your code

it is possible that bug is in OS, compiler or third-party product – but this should not be your first though

start looking from the last change before system “stopped working” even it is not related to current problem

the fall back – binary search

Debugging Strategies (4) Simplify the reproducibility easier to retry the test lowers the features you check for correctness Leaps of Faith Change one variable of the time otherwise you don't know which change fixed the problem restore original before making new change Check recent changes check revision history, CVS log file examine diff s of problematic areas ask developers

Simplify the reproducibility

easier to retry the test

lowers the features you check for correctness

Leaps of Faith

Change one variable of the time

otherwise you don't know which change fixed the problem

restore original before making new change

Check recent changes

check revision history, CVS log file

examine diff s of problematic areas

ask developers

Debugging Strategies (5) Cleanup “dead code” in the system it is blindfolding you Question assumptions Result: my ($i, $j) = (1, 2); print_out_i_and_j($i, $j); $i += 3; $j += 4; print "after: i=[$i] j=[$j]
"; print_out: i=[1] j=[2] after: i=[5] j=[5]

Cleanup “dead code” in the system

it is blindfolding you

Question assumptions Result:

Debugging Strategies (6) Question assumptions - answer Look at untested code Use code coverage to determine what's being used checkout the Perl modules Test::Strict, Devel::Cover, Test::Pod::Coverage Code elimination you are admitting you haven't got the clue what is going on sub print_out_i_and_j($$) { print "print_out: i=[$_[0]] j=[$_[1]]
"; $_[0]++; # adjust offset in file $_[1]--; # adjust line count }

Question assumptions - answer

Look at untested code

Use code coverage to determine what's being used

checkout the Perl modules Test::Strict, Devel::Cover, Test::Pod::Coverage

Code elimination

you are admitting you haven't got the clue what is going on

Debugging Checklist Is the problem being reported is a direct result from a bug or symptom? Is the bug in th OS or in your code? If the code passes unit test, are the tests complete? Does the conditions that caused this bug exists else in the system?

Is the problem being reported is a direct result from a bug or symptom?

Is the bug in th OS or in your code?

If the code passes unit test, are the tests complete?

Does the conditions that caused this bug exists else in the system?

What's Next How to learn from bugs improve testing, automation Risk management Proper bug reporting

How to learn from bugs

improve testing, automation

Risk management

Proper bug reporting