How to isolate cause of failure?

1. How to isolate cause of failure? 2006.10.31 최윤라

2. Contents • Introduction • Isolating relevant input • Isolating relevant states • Isolating the error • Experiments • Conclusions

3. ✘ ✘ ✘ ✘ ✘ This infection chain must be traced back – and broken. ✘ Introduction - From Defect to Failure • The programmer creates a defect– an error in the code. • When executed, the defect creates an infection –an error in the state. • The infection propagates. • The infection causes a failure. Variables t

4. Explaining Counterexamples • Error explanation: • Provides an explanation of a counterexample trace: a story about causality. • Fault localization: • Tells where the bug might be.

5. Related Works • Testing/automated debugging in general: • Renieris, Reiss: Fault Localization with Nearest Neighbor Queries (ASE 03) • Wotawa, others: Model based diagnosis of program errors • Slicing (dynamic/static) • Model checking: • Jin, Ravi, Somenzi: Fate and Free Will (TACAS 02) • Ball, Naik, Rajamani: From Symptom to Cause (POPL 03) • Groce, Visser: Error Explanation with Distance Metrics (TACAS 04) • Also, Chechik, et al.: proof-like counterexamples, temporal queries

6. Automated Tests • Allow for reuse of tests • Allow tests that are difficult to carry out manually • Make tests repeatable • Increase confidence in software

7. Failure cause Isolating Relevant Input

8. Causes as Differences Actual world empty: GCC works fine Alternate world fail.c: GCC crashes Cause: fail.c

9. Actual Causes “The” cause (actual cause) is a minimal difference Actual cause

10. ✔ ? Isolating Causes Alternate world Actual world ✘ Test Mixed world

11. Isolating Causes Alternate world Actual world “+ 1.0” ✔ ✘ ? Test Mixed world

12. Delta Debugging Configuration Goal • isolates failure-inducing difference • : 1-minimal

13. Delta Debugging (cont.) dd algorithm

14. Isolating Relevant States • Differences accumulate during execution: • How do we isolate the relevant state differences?

15. Memory Graph • Extract program states as graph. • Vertices are variables, edges are references.

16. Structural differences between memory graphs

17. Isolating the GCC Cause-Effect • HOWCOME components

18. The process in a Nutshell • Comparable States? • Current PC and backtrace of the two locations must be identical.

19. GCC cause-effect chain • HOWCOME starts with three events, occurring in both r and r • After the program start • When cc1 reaches the function main • In the middle of the program run • When cc1 reaches combine_instructions • Shortly before the failure • When cc1 reaches if_then_else_cond

20. Isolating Errors • Narrowing at conbine_instructions • Narrowing down relevant events

21. Experiments

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

23. Conclusions • Pros • Cause-effect chains explain the causes of program failures automatically and effectively. • Systematic experimentation leads to much higher precision than “classical analysis”. • Via automation, debugging becomes a well-understood, systematic discipline. • Cons • We need a passing executions as a reference. • Large testing costs can be prohibitive • Preventing bugs is still an issue!