1 / 85

Tracking Down Bugs

Tracking Down Bugs. Benny Vaksendiser. Overview. Motivation Isolating Cause-Effect Chains from Computer Programs Visualization of Test Information to Assist Fault Localization Dynamically Discovering Likely Program Invariants to Support Program Evolution

osborn
Download Presentation

Tracking Down Bugs

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. Tracking Down Bugs Benny Vaksendiser

  2. Overview • Motivation • Isolating Cause-Effect Chains from Computer Programs • Visualization of Test Information to Assist Fault Localization • Dynamically Discovering Likely Program Invariants to Support Program Evolution • Automatic Extraction of Object-Oriented Component Interfaces • Comparison • Summary • References

  3. Motivation • Improve software quality. • Reduce the number of delivered faults. • Lowering maintenance cost.

  4. Motivation Lowering Maintenance Cost • The cost for maintaining software represents more than 90%. • Debugging is a high consuming task.

  5. Why Debugging So Hard? • Complexity of software. • Fixing unfamiliar code. • Finding the cause of a bug isn’t trivial. • “Corner places”. • Undocumented code. • Documentation often incomplete or wrong. • Lack of a guiding tool.

  6. Isolating Cause-Effect Chains from Computer Programs Andreas Zeller professor atUniversität des Saarlandesin Saarbrücken, Germany

  7. Isolating Cause-Effect Chains from Computer ProgramsAndreas Zeller A passing run and a failing run Delta Debugging algorithm Isolating the cause of the failing run

  8. Failing Run double mult(double z[], int n){ int i,j; i=0; for(j=0;j<n;j++){ i=i+j+1; z[i]=z[i]*(z[0]+1.0); } return z[n]; } Compiling fail.c, the GNU compiler (GCC) crashes: linux$ gcc-2.95.2 -O bug.c gcc: Internal error: program cc1 got fatal signal 11 What’s the error that causes this failure?

  9. Cause What’s the cause for the GCC failure? The cause of any event (“effect”) is a preceding event without which the effect would not have occurred. — Microsoft Encarta To prove causality, we must show that: 1. The effect occurs when the cause occurs –failing run. 2. The effect does not occur when the cause does not occur – passing run. General technique: Experimentation—constructing a theory from a series of experiments (runs) Can’t we automate experimentation?

  10. Isolating Failure Causes

  11. Isolating Failure Causes

  12. Isolating Failure Causes

  13. Isolating Failure Causes

  14. Isolating Failure Causes +1.0 is the failure cause –after only 19 tests

  15. What’s going on in GCC?

  16. What’s going on in GCC?

  17. What’s going on in GCC?

  18. What’s going on in GCC?

  19. What’s going on in GCC? To fix the failure, we must break this cause-effect chain.

  20. Small Cause, Big Effect How do we isolate the relevant state dierences?

  21. Memory Graphs • Vertices are variables. • Edges are references.

  22. The GCC Memory Graph

  23. The Process in a Nutshell

  24. The Process in a Nutshell

  25. The Process in a Nutshell

  26. The GCC Cause-Effect Chain

  27. www.askigor.org Submit buggy program Specify invocations Click on “Debug it” Diagnosis comes via e-mail

  28. Visualization of Test Information to Assist Fault Localization 24th International Conference on Software Engineering USA, May 2002 Mary Jean Harrold John T. Stasko James A. Jones College of Computing Georgia Institute of Technology

  29. Visualization of Test Information to Assist Fault LocalizationJames A. Jones, Mary Jean Harrold, John Stasko Higher frequency of execution of a statement of program by failure test cases Higher probability of having fault in the statement

  30. Discrete Approach • Input • Source code • For each test case • its pass/fail status • statements that it executes • Display statements in program according to the test cases that execute them Statements executed by: Only passed test cases Both passed & failed test cases Only failed test cases

  31. Example

  32. Example

  33. Example

  34. Problem • Not very helpful! • Does not capture the relative frequency.

  35. Continuous Approach • Distribute statements executed by both passed and failed test cases over spectrum. • Indicate the relative success rate of each statement by its hue. Only passed test cases Both passed & failed test cases Only failed test cases Discrete Approach: Continuous Approach:

  36. Continuous Approach - Hue Indicate the relative success rate of each statement by its hue.

  37. Continuous Approach - Brightness Statements executed more frequently are rendered brighter

  38. Back To Example

  39. Scalability }

  40. Limitations • Data related Bugs. • Very test case depended.

  41. Future Work • What other views and analyses would be useful? • What is the maximum practical number of faults for which this technique works? • Visualization on higher-level representations of the code. • Using visualization in other places.

  42. Tarantula

  43. Dynamically Discovering Likely Program Invariants to Support Program Evolution IEEE Transactions on Software Engineering 2001 Michael D. Ernst David Notkin Jake Cockrell William G. Griswold Dept. of Computer Science & Engineering University of Washington Dept. of Computer Science & Engineering University of California San Diego

  44. Dynamically Discovering Likely Program Invariants to Support Program EvolutionMichael D. Ernst, William G. Griswold, Jake Cockrell, David Notkin Problem • Invariants are useful. • Programmers (usually) don’t write invariants. • Solution • Dynamic Invariant Detection. • Automatic tool: “Daikon“.

  45. Example • example from “The Science of Programming,” by Gries, 1981.

  46. Example • 100 randomly-generated arrays • Length is uniformly distributed from 7 to 13 • Elements are uniformly distributed from –100 to 100 • Daikon discovers invariant by • running the program on this test set • monitoring the values of the variables

  47. Example Invariants produced by Daikon • 100 randomly-generated arrays • Length is uniformly distributed from 7 to 13 • Elements are uniformly distributed from –100 to 100 • Daikon discovers invariant by • running the program on this test set • monitoring the values of the variables

  48. Architecture

  49. Instrumentation • At program points of interest: • Function entry points • Loop heads • Function exit points • Output values of all `interesting' variables • Scalar values (locals, globals, array subscript expressions, etc.) • Arrays of scalar values • Object addresses/ids • More kinds of invariants checked for numeric types

  50. Types of Invariants Variables x, y, z ; constants a, b, c • Invariants over any variable x • Constant value: x = a • Uninitialized: x = uninit • Small value set: x {a, b, c} • variable takes a small set of values • Invariants over a single numeric variable: • Range limits: x  a, x  b, a  x  b • Nonzero: x  0 • Modulus: x = a (mod b) • Nonmodulus: x  a (mod b) • reported only if x mod b takes on every value other than a

More Related