1. ITM Debugging

2. 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

3. 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).

4. 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.
                     

5. 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.

6. The Ideal Debugging Process
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!

7. Debugging Techniques

8. Debugging Techniques, 1 Execution tracing Avoiding bugs
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

9. 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.

10. 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.

11. 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.

12. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Error handling and logging ;
; error_reporting is a bit-field. Or each number up to get desired error
; reporting level
; E_ALL All errors and warnings (doesn't include E_STRICT)
; E_ERROR fatal run-time errors
; E_WARNING run-time warnings (non-fatal errors)
; E_PARSE compile-time parse errors
; E_NOTICE run-time notices (these are warnings which often result
; from a bug in your code, but it's possible that it was
; intentional (e.g., using an uninitialized variable and
; relying on the fact it's automatically initialized to an
; empty string)
; E_STRICT - run-time notices, enable to have PHP suggest changes
; to your code which will ensure the best interoperability
; and forward compatibility of your code
; 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
; E_COMPILE_ERROR - fatal compile-time errors
; E_COMPILE_WARNING - compile-time warnings (non-fatal errors)
; E_USER_ERROR user-generated error message
; E_USER_WARNING - user-generated warning message
; E_USER_NOTICE user-generated notice message ;
; Examples:
; - Show all errors, except for notices and coding standards warnings
;error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT ;
; - Show all errors, except for notices
;error_reporting = E_ALL & ~E_NOTICE
; - Show only errors
;error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
; - Show all errors except for notices and coding standards warnings
error_reporting =E_ALL & ~E_NOTICE & ~E_STRICT
; Print out errors (as a part of the output). For production web sites,
; you're strongly encouraged to turn this feature off, and use error logging
; instead (see below). Keeping display_errors enabled on a production web site
; may reveal security information to end users, such as file paths on your Web
; server, your database schema or other information.
display_errors = On
; Even when display_errors is on, errors that occur during PHP's startup
; sequence are not displayed. It's strongly recommended to keep
; display_startup_errors off, except for when debugging.
display_startup_errors = Off

13. 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.

14. 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.

15. 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";

16. 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);
?>

17. 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>
<input name=" " size="25"><br>
<input name="Submit" type="submit" value="Send GET Request">
</form>
<? } ?>

18. 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>
<input name=" " size="25"><br>
<input name="Submit" type="submit" value="Send GET Request">
</form>
<? } ?>

19. Exercise 4: For Extra Credit
To view: Examples/Debug.txt To run: Examples/Debug.php