Download
1 / 15
150 likes | 236 Views
Differential S tatic A nalysis: Opportunities and Challenges. Shuvendu Lahiri RiSE , MSR Redmond UC Berkeley OSQ Retreat (5/12/11). Challenges of static assertion checking. void F(A *z, int *a){ int n = ComplexFunc (z); int j = 0; List* x = z->list;
E N D
Differential Static Analysis: Opportunities and Challenges Shuvendu Lahiri RiSE, MSR Redmond UC Berkeley OSQ Retreat (5/12/11)
Challenges of static assertion checking void F(A *z, int *a){ int n = ComplexFunc(z); int j = 0; List* x = z->list; while(x != null) { j++; if (x->d == n) { a[j] = x->g; break; } x = x->next; } } Precondition Postcondition Loop invariant assert (0 <= j && j <= ?);
State of static assertion checking • Not cost-effective for an average developer (yet) • Need for specs • Need for intermediate inductiveassertions • Precise analysis non-scalable • Most functional specs are tested by regression testing (expensive/low-coverage)
App-Compat problem • Every developer has to worry about introducing incompatibility rather than fixing ALL existing bugs • Library writers (releases) Did the “refactoring” change any observable behavior? How does the change propagate to the public APIs Do my changes introduce a regression? Microsoft Confidential
Current practice • Run regression tests and hope breaking changes show up • Problems • Coverage: only a small fraction of paths covered • Especially with few inputs, loops, recursive • Controllability: hard to exercise the paths under change • Oracles: mostly program crashes, or a few built-in assertions
Differential static analysis • Provide relative guaranteeinstead of absolute guarantee • May be easier to obtain, and possibly desirable
Precedence (equivalence checking) • Hardware • Equivalence checking was a big success • ISA vs. RTL, timing optimizations, …. • Software • Translation validation (intraprocedural compiler transformations) • However, most code changes in software change behaviors (bug fixes, features, …) • Fairly limited applicability
Potential applications: Fast feedback about changes • Equivalence checking • Manual refactorings, translation validation, app-compat for different versions of compilers • Conditional equivalence checking • Allow the user to express (or infer) conditions under which two versions are compatible • Differential contract checking • Show that contracts are not violated for more inputs after a change
Differential contract checking void F(A *z, int *a){ int n = ComplexFunc(z); int j = 0; List* x = z->list; while(x != null) { j++; if (x->d == n) { a[j] = x->g; break; } x = x->next; } } void F(A *z, int *a){ int n = ComplexFunc(z); int j = 0; List* x = z->list; while(x != null) { j++; if (x->d == n) { a[j] = x->h + x->g; break; } x = x->next; } } May be able to check that the change does not introduce new buffer overruns, with cheap abstractions
SymDiff (Symbolic Diff) • Project underway in MSR Redmond • With Chris Hawblitzel, .. • In a nutshell • Windiff for a program’s input/output behaviors • Source language independent (uses Boogie/Z3) • Static tool for identifying semantic differences between two closely related program versions
Current directions (in progress) • Mutual summaries • With Chris Hawblitzel • A general mechanism for comparing programs • E.g. Can prove most compiler optimizations (translation validation) • Application of differential contract checking • Finding precise concurrent bugs in the presence of underspecified environment • With Akash Lal (POIROT) • Inference of conditional equivalence • Using abstract interpretation, interpolation, …
Summary • Problem: Static App-compat • Relative vs. absolute guarantee • Opportunities • Impact developers, quick feedback, more coverage than tests, fewer false alarms, cheaper abstractions • Challenges • Understanding developer intent, communicating differences, root cause, …
Other projects • Linear maps • Local reasoning in classical logic [Qadeer, Walker] • POIROT • Assertion directed symbolic search for concurrent programs [Lal, Qadeer]
