ITM 352 Debugging

1. ITM 352Debugging

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

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

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

8. 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 information (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.

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

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

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

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

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

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

15. 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> <? } ?>

16. 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> <? } ?>

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