1 / 17

ITM 352 Debugging

ITM 352 Debugging. 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. Debugging and Testing. Testing and debugging go together like peas in a pod:

ruthdbrown
Download Presentation

ITM 352 Debugging

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related