The$credit$for$crea-ng$these$slides$belongs$to$Fall$2014$CS$521/621$students.$$Student$names$have$been$removed$per$FERPA$regula-ons.$

Using Likely Invariants for Automated Software

Fault Localization

Do you see the needle?

Would it not be nice to have help finding things?

Motivation

Motivation

●  Software bugs are everywhere!

Motivation

●  Software bugs are everywhere! ●  Bug Detection is the problem of determining whether

the program has bugs.

Motivation

●  Software bugs are everywhere! ●  Bug Detection is the problem of determining whether

the program has bugs. ●  Involves Fault Localization: the problem of identifying

one or more possible locations in the program where code needs to be changed to prevent the failure.

Motivation

●  Software bugs are everywhere! ●  Bug Detection is the problem of determining whether

the program has bugs. ●  Involves Fault Localization: the problem of identifying

one or more possible locations in the program where code needs to be changed to prevent the failure.

●  Debugging is an important but time consuming step, and mostly a manual process.

Research Questions

Research Questions

●  Can we compare program invariants between failing and succeeding input to help narrow down potential bug locations?

Research Questions

●  Can we compare program invariants between failing and succeeding input to help narrow down potential bug locations?

●  Can we further filter the results to give better bug locations without removing the true cause?

Key Idea ●  Train the invariants with a small set of automatically constructed

“good inputs” that are close to a given failing input ●  Compare invariants to find different areas which can be root

causes for bug ●  Use filtering techniques to narrow down candidate root causes to a

small set of final locations o  Use dynamic backward slicing to filter out invariants that do not influence the observed

failure symptom o  Remove dependant instructions to a potentially failing instruction

●  Repeat this for similar failing inputs to compare common failing instructions (not always helpful: removes true root cause)

Code Example: MySQL long calc_daynr( uint year, uint month, uint day) { …. if (month <= 2)

year --; …… return ( delsum +( int ) year/4-temp ) ; } ……. weekday= calc_weekday (calc_daynr(t->year, t->month->day), 0); str->append(loc->d_names->type_names[weekday], …...

Year becomes negative for January 0000 and February 0000

Will return negative

weekday will get a negative value

Buffer overflow and program CRASH

Code Example Cont. ●  Generate successful Year, Month, Day inputs ●  Compare likely invariants to generate candidate root

causes o  ex. str->append(‘-’), weekday, calc_weekday,

calc_daynr ●  Filter root causes

o  output: calc_daynr ●  Compare with other failing inputs

o  if root cause eliminated, examine previous step’s root causes

Summary of Evaluation

Summary of Evaluation The root cause for bug-2 was found in the step after the Dependence filter

Comparing against 2 previously statistical approaches for how many lines of code (LOC) needs to be invested.

Contribution

●  New invariant based approach for fault localization that uses automatically created similar inputs to the failing input

●  Uses effective filtering to narrow down potential bug locations

●  Evaluated work on large input libraries ●  Results show the approach is very effective

Discussion Questions

1.  How do failing invariants help find the root error?

Discussion Questions

1.  How do failing invariants help find the root error? 2.  What problems would arise by using a large general test

suite, compared to a smaller and more precise?

Discussion Questions

1.  How do failing invariants help find the root error? 2.  What problems would arise by using a large general test

suite, compared to a smaller and more precise? 3.  How is Delta debugging incorporated in the technique?

Discussion Questions

1.  How do failing invariants help find the root error? 2.  What problems would arise by using a large general test

suite, compared to a smaller and more precise? 3.  How is Delta debugging incorporated in the technique? 4.  How is Daikon or similar tools be incorporated in the

technique?

Discussion Questions

1.  How do failing invariants help find the root error? 2.  What problems would arise by using a large general test

suite, compared to a smaller and more precise? 3.  How is Delta debugging incorporated in the technique? 4.  How is Daikon or similar tools be incorporated in the

technique? 5.  What are the limitations of the technique?

Discussion Questions

1.  How do failing invariants help find the root error? 2.  What problems would arise by using a large general test

suite, compared to a smaller and more precise? 3.  How is Delta debugging incorporated in the technique? 4.  How is Daikon or similar tools be incorporated in the

technique? 5.  What are the limitations of the technique? 6.  How can we handle the limitations?

Bibliography

Sahoo, Swarup K., John Criswell, Chase Geigle, and Vikram Adve. "Using

Likely Invariants for Automated Software Fault Localization."ACM

SIGARCH Computer Architecture News 41.1 (2013): 139-52. ACM Digital

Library. Web. 30 Oct. 2014. <http://dl.acm.org/citation.cfm?id=2451131>.