How to isolate cause of failure?

2006.10.31 최윤라

Contents Introduction Isolating relevant input Isolating relevant states Isolating the error Experiments Conclusions

✘

1.The programmer creates a defect – an error in the code.

2.When executed, the defect creates an infection – an error in the state.

3.The infection propagates.

4.The infection causes a failure.

✘

✘

✘

✘ ✘

Variables

This infection chain must be traced back – and broken.

t

Introduction - From Defect to Failure

Explaining Counterexamples Error explanation:

Provides an explanation of a counterexample trace: a story about causality.

Fault localization: Tells where the bug might be.

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

Automated Tests

Allow for reuse of tests Allow tests that are difficult to carry

out manually Make tests repeatable Increase confidence in software

Isolating Relevant Input

Failure cause

Alternateworld

empty: GCC works fineActual world

fail.c: GCC crashes

Cause:fail.c

Causes as Differences

Actual Causes

Actual cause

“The” cause (actual cause) is a minimal difference

Alternate worldActual world

Isolating Causes

Mixed world

✔✘

Test

?

Alternate worldActual world

Isolating Causes

Mixed world

✔✘

Test

?

“+ 1.0”

Delta Debugging

Configuration

Goal

• isolates failure-inducing difference

•

• : 1-minimal

Delta Debugging (cont.)

dd algorithm

Isolating Relevant States

Differences accumulate during execution:

How do we isolate the relevant state differences?

Memory Graph Extract program

states as graph. Vertices are

variables, edges are references.

Structural differences between memory graphs

Isolating the GCC Cause-Effect HOWCOME components

The process in a Nutshell

Comparable States? Current PC and backtrace of the two locations must be

identical.

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

Isolating Errors Narrowing at conbine_instructions

Narrowing down relevant events

Experiments

www.askigor.org

Submit buggy pgm

Specify invocations

Click on “Debug it”

Diagnosis comes via e-mail

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!