1. ITM 352 © Port,KazmanDebugging - 1 ITM 352 Debugging

2. ITM 352 © Port,KazmanDebugging - 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. ITM 352 © Port,KazmanDebugging - 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. ITM 352 © Port,KazmanDebugging - 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. ITM 352 © Port,KazmanDebugging - 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. ITM 352 © Port,KazmanDebugging - 6 The Ideal Debugging Process 1. Identify test case(s) that reliably show existence of fault (when possible) 2. Isolate problem to small fragment(s) of program 3. Correlate incorrect behavior with program logic 4. Change the program (and check for other parts of program where same or similar program logic may also occur) 5. Regression test to verify that the error has really been removed - without inserting new errors 6. Update documentation when appropriate Not all these steps need be done by the same person!

7. ITM 352 © Port,KazmanDebugging - 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

8. ITM 352 © Port,KazmanDebugging - 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.

9. ITM 352 © Port,KazmanDebugging - 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.

10. ITM 352 © Port,KazmanDebugging - 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.

11. ITM 352 © Port,KazmanDebugging - 11 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; 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

12. ITM 352 © Port,KazmanDebugging - 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.

13. ITM 352 © Port,KazmanDebugging - 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.

14. ITM 352 © Port,KazmanDebugging - 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";

15. ITM 352 © Port,KazmanDebugging - 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); ?>

16. ITM 352 © Port,KazmanDebugging - 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 { ?> Name: Email:

17. ITM 352 © Port,KazmanDebugging - 17 Exercise 3: Print Statements Help! <?php if (array_key_exists($_GET, 'Submit') { $j = ""; print(“The variables submitted via GET: "); foreach($_GET as $key => $i){ print("$key=$j "); if ($j = "Tyler") echo "Found him!"; } } else ?> Name: Email:

18. ITM 352 © Port,KazmanDebugging - 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