ITM 352
Debugging
ITM 352 © Port,Kazman
Debugging - 1
Debugging
 Debugging is a “black art”.
 What we will discuss:
 relation to testing
 why debugging is hard
 types of bugs
 process
 techniques
 tools
 avoiding bugs
ITM 352 © Port,Kazman
Debugging - 2
Debugging and Testing
 Testing and debugging go together like peas in a
pod:
Testing finds errors; debugging repairs them.
 Together these form the "testing/debugging cycle": we
test, then debug, then repeat.
 Any debugging should be followed by a reapplication
of all relevant tests, particularly regression tests. This
helps avoid the introduction of new bugs.
 Testing and debugging need not be done by the same
people (and often should not be).

ITM 352 © Port,Kazman
Debugging - 3
Why Debugging is Hard
 There may be no obvious relationship between the external
manifestation(s) of an error and its internal cause(s)!! 
 Cause and symptom may be in remote parts of the
program. 
 Changes (new features, bug fixes) in program may mask
(or modify) bugs. 
 Symptom may be due to a human mistake or
misunderstanding that is difficult to trace. 
 Bug may be triggered by rare or difficult to reproduce
input sequence, program timing or other external causes.

ITM 352 © Port,Kazman
Debugging - 4
Types of Bugs
 Types of bugs (gotta love em):
 Compile time: syntax, spelling, static type mismatch.
 Design: flawed algorithm.
 Program logic (if/else, loop termination, select case, etc).
 Memory nonsense: null pointers, array bounds, bad types, leaks.
 Interface errors between modules, threads, programs (in particular, with
shared resources: sockets, files, memory, etc).
 Off-nominal conditions: failure of some part of software of underlying
machinery (network, etc).
 Deadlocks: multiple processes fighting for a resource.
ITM 352 © Port,Kazman
Debugging - 5
The Ideal Debugging Process
1.
2.
3.
4.
5.
6.
Identify test case(s) that reliably show existence of
fault (when possible)
Isolate problem to small fragment(s) of program
Correlate incorrect behavior with program logic
Change the program (and check for other parts of
program where same or similar program logic may
also occur)
Regression test to verify that the error has really been
removed - without inserting new errors
Update documentation when appropriate
Not all these steps need be done by the same person!
ITM 352 © Port,Kazman
Debugging - 6
Debugging Techniques
ITM 352 © Port,Kazman
Debugging - 7
Debugging Techniques, 1
 Execution tracing
 running the program
 print
 trace utilities
 single stepping in debugger
 hand simulation/walkthroughs
 Avoiding bugs
 Comment as you code
 Programming conventions
 Reuse of known good code
 Modularization
 Test small pieces before combining them
ITM 352 © Port,Kazman
Debugging - 8
Debugging Techniques, 2
 Interface checking
 check procedure parameter number/type (if not enforced
by compiler) and value
 defensive programming: check inputs/results from other
modules
 documents assumptions about caller/callee relationships
in modules, communication protocols, etc
 Assertions: include range constraints or other
information with data.
 Skipping code: comment out suspect code, then
check if error remains.
ITM 352 © Port,Kazman
Debugging - 9
Debugging with Print - 1
How debugging with “print” (or “echo”)
can be made more useful:
– print variables other than just those you think
suspect (use var_dump() or print_r() )
– print valuable statements (not just "hi\n").
– use exit() to concentrate on a part of a program.
– move print through a through program to track
down a bug.
ITM 352 © Port,Kazman
Debugging - 10
Debugging with Print - 2
Building debugging with print into a
program:
– print messages, variables in useful places
throughout program.
– turn debugging messages on or off as needed
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 'on');
– possibly use a global find/replace to
insert/remove debug statements.
ITM 352 © Port,Kazman
Debugging - 11
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error handling and logging ;
; Examples:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; - Show all errors, except for notices and coding standards warnings
;error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
; error_reporting is a bit-field. Or each number up to get desired error
;
; reporting level
; - Show all errors, except for notices
; E_ALL
- All errors and warnings (doesn't include E_STRICT)
; E_ERROR
- fatal run-time errors
; E_WARNING
; E_PARSE
; E_NOTICE
- run-time warnings (non-fatal errors)
- compile-time parse errors
- run-time notices (these are warnings which often result
;error_reporting = E_ALL & ~E_NOTICE
;
; - Show only errors
;error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
;
;
from a bug in your code, but it's possible that it was
; - Show all errors except for notices and coding standards warnings
;
intentional (e.g., using an uninitialized variable and
error_reporting =E_ALL & ~E_NOTICE & ~E_STRICT
;
relying on the fact it's automatically initialized to an
;
empty string)
; Print out errors (as a part of the output). For production web sites,
; E_STRICT - run-time notices, enable to have PHP suggest changes
; you're strongly encouraged to turn this feature off, and use error logging
;
to your code which will ensure the best interoperability
;
and forward compatibility of your code
; instead (see below). Keeping display_errors enabled on a production web
site
; E_CORE_ERROR
- fatal errors that occur during PHP's initial startup
; E_CORE_WARNING
;
- warnings (non-fatal errors) that occur during PHP's
initial startup
; may reveal security information to end users, such as file paths on your
Web
; server, your database schema or other information.
display_errors = On
; E_COMPILE_ERROR - fatal compile-time errors
; E_COMPILE_WARNING - compile-time warnings (non-fatal errors)
; Even when display_errors is on, errors that occur during PHP's startup
; E_USER_ERROR
; sequence are not displayed. It's strongly recommended to keep
; E_USER_WARNING
; E_USER_NOTICE
- user-generated error message
- user-generated warning message
- user-generated notice message
; display_startup_errors off, except for when debugging.
display_startup_errors = Off
;
ITM 352 © Port,Kazman
Debugging - 12
Avoiding Bugs in the First Place
 Coding style: use clear, consistent style and
useful naming standards.
 Document everything that is non-obvious, from
architecture and interface specification
documents to comments on code lines.
 Hold code reviews.
 Program defensively.
 Use/implement exception handling liberally;
think constantly about anomalous conditions.
 Be suspicious of cut/paste.
ITM 352 © Port,Kazman
Debugging - 13
Code Reviews
 Primary programmer(s) for some piece of code presents and




explains that code, line by line.
Audience of programmers experienced in language, code's
general domain. Audience may also contain designers, testers,
customers and others less versed in code but concerned with
quality and consistency.
Review is a dialogue: audience pushes presenters to reevaluate
and rationalize their implementation decisions.
Extremely useful: reviews often turn up errors, inconsistencies,
inefficiencies and unconsidered exceptional conditions.
Also useful in familiarizing a project team with a member's
code.
ITM 352 © Port,Kazman
Debugging - 14
Exercise: Debug the Following
$product = array('name' => 'small gumball', price =>
'$0.34');
$tax_rate = 0.045;
$total = $product['price'] + $tax_rate *
$product['price'];
echo "A $product['name'] costs $total";
ITM 352 © Port,Kazman
Debugging - 15
Exercise 2: Debug the Following
<?php
$prices = array(5.95, 3.00, 12.50);
$total_price = 0;
$tax_rate = 1.08; // 8% tax
foreach ($prices as $price)
{
$total_price = $price * $tax_rate;
}
printf('Total price (with tax): $%.2f', $total_price);
?>
ITM 352 © Port,Kazman
Debugging - 16
Exercise 3: Debug the Following
<?php
if (array_key_exists($_GET, 'Submit')
{
$j = "";
foreach($_GET as $key => $i)
{
if ($j = "Tyler") echo "Found him!";
}
}
else {
?>
<form method="GET">
Name: <input name="name"><br>
Email: <input name="email" size="25"><br>
<input name="Submit" type="submit" value="Send GET Request">
</form>
<? } ?>
ITM 352 © Port,Kazman
Debugging - 17
Exercise 3: Print Statements Help!
<?php
if (array_key_exists($_GET, 'Submit')
{
$j = "";
print(“The variables submitted via GET:<br>");
foreach($_GET as $key => $i)
{
print("$key=$j<br>");
if ($j = "Tyler") echo "Found him!";
}
} else
?>
<form method="GET">
Name: <input name="name"><br>
Email: <input name="email" size="25"><br>
<input name="Submit" type="submit" value="Send GET Request">
</form>
<? } ?>
ITM 352 © Port,Kazman
Debugging - 18
Exercise 4: For Extra Credit
To view:
http://itm-vm.shidler.hawaii.edu/itm352/
Examples/Debug.txt
To run:
http://itm-vm.shidler.hawaii.edu/itm352/
Examples/Debug.php
ITM 352 © Port,Kazman
Debugging - 19