ITM 352 Debugging ITM 352 Port Kazman Debugging

ITM 352 Debugging ITM 352 © Port, Kazman Debugging - 1

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

The Ideal Debugging Process 1. Identify test case(s) that reliably show existence of 2. 3. 4. 5. 6. 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 - 5

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

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

Debugging with Print - 1 q. 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 "hin"). – 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 - 8

Debugging with Print - 2 q. 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 - 9

; ; ; ; ; ; ; ; 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_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 - user-generated error message ; E_USER_WARNING ; E_USER_NOTICE - 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 - 10

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

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

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

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): $%. 2 f', $total_price); ? > ITM 352 © Port, Kazman Debugging - 14

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"> Email: <input name="email" size="25"> <input name="Submit" type="submit" value="Send GET Request"> </form> <? } ? > ITM 352 © Port, Kazman Debugging - 15

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 ? > <form method="GET"> Name: <input name="name"> Email: <input name="email" size="25"> <input name="Submit" type="submit" value="Send GET Request"> </form> <? } ? > ITM 352 © Port, Kazman Debugging - 16

Exercise 4: For Extra Credit To view: http: //itmvm. shidler. hawaii. edu/itm 352/Examples/Debug. txt To run: http: //itmvm. shidler. hawaii. edu/itm 352/Examples/Debug. php ITM 352 © Port, Kazman Debugging - 17