Locating Causes of Program Failures

1
Locating Causes of Program Failures

• Paper by
• Holger Cleve and Andreas Zeller
• Professor Ingolf Krueger
• Presented by Vina Ermagan

Locating causes of program failuresHolger
Cleve - Andreas Zeller - Saarland University,
Saarbrücken, GermanyICSE'05
2
Out Line

• Define the goals and point of view.
• A sample failure.
• Search over space.
• Search over time.
• Case study the GCC.
• Complexity.

3
Program failures?

• In principle, a defect in the code creates a
  failure or infection in the program state, which
  then propagates, until it becomes an observable
  failure.
• Main Idea trace back the infection chain to
  find the defect
• 1) To prove that I and I are infected show
  that they violate the specification!!
• 2) To prove that I causes I show that effect
  I does not occur if cause I does not occur.

4
Search Environment

• Search in space across a program state to find
  the infected variables (often among thousands).
• Search in time over millions of such program
  states to find the moment in time when the
  infection began ( the moment the defect was
  executed).

5
Search in Space

• Focus on the difference between the program
  states of two runs of the program, one that fails
  and one that does not.
• Automatic Strategy Delta Debugging.
• Narrow down the initial differences to a small
  set of variables.

6
Search in Time

• Focus on cause transitions.
• Cause Transition Moments in time when some
  variable ceases to be a failure cause and another
  variable begins.
• Good location for fixes.
• Locate the defects that cause the failure.

7
A Sample Failure

• sample 9 8 7
• 7 8 9
• -
• Sample 11 14
• 0 11
• -

8
(No Transcript)
9
Sample Failure (Continue)

• Delta Debugging in Line 35 gt a20 is the
  failure cause.
• How do we reach Line 35?
• - There is a cause transition from argc to a2
  on this Line!

10
Search in Space- Line 9
11
Search in Space

• By Delta Debugging we determine the smallest
  relevant subset of variables in the set of
  differences.

12
Search in Space

• We use the GNU debugger (GDB) to extract the
  program state as a memory graph.
• Memory Graph contains al values and variables
  of a program, but represents operations (ex.
  Variable access) by edges.
• 1) Compute the common subgraph of G1 and G2, to
  extract the differences.
• 2) Translate the differences to atomic deltas
  that create or delete new variables.
• 3) Apply the deltas to find the relevant
  variables.

13
(No Transcript)
14
Common Subgraph

• Small graphs compute the largest common
  subgraph .
• Larger graphs compute a large common subgraph
  using simple parallel traversal.

15
Search in Time
16
Search in Time- Steps

• Find the interval of matches to start with first
  matching point and last point before the failure
  Step 1 , Step 44.
• Use Delta Debugger to find the relevant variables
  in these two states argc , a0.
• CTS searches a match point between steps 1 and 44
  ( Prefers function calls) Step 11 (a2).
• CTS Step 26 (a2).
• CTS Step 35 (v).

17
(No Transcript)
18
Case Study The GCC Failure
19
Space

• After the program start(main).
• In the middle of program run(combine
  instructions).
• Shortly before the failure(if-then-else).

20
The GCC Memory Graph!
21
GCC Memory Graph

• 27139 vertices, 27159 edges!
• Took 15 minutes of the GDB.
• In 12 seconds, argv3 is determined as the
  failure cause!!

22
Time
23
(No Transcript)
24
A Question

• Why not point out to apply_distributive_law() as
  a cause?
• Not a matching point!

25
Complexity

• Searching in space
• -Best Case Delta Debugging needs 2s log k
  test runs to isolate s failure-inducing variables
  from k state differences.
• -Worst Case k2 3K .
• Searching in Time Binary search over n program
  steps, repeated for each cause transition. For m
  cause transitions we need m log n runs of Delta
  Debugging.

26
Future Works

• Accessing State directly accessing states
  rather than using GDB.
• Use heuristics .

27
Summary

• Cause transitions locate the software defect that
  causes a given failure, performing twice as well
  as any other technique previously known.
• The technique requires an automated test, a means
  to observe and manipulate the program state, as
  well as at least one alternate passing test run.
• the tool reports the cause-effect chain from
  input to failure, listing the isolated cause
  transitions as likely locations to fix.