View
219
Download
0
Category
Tags:
Preview:
Citation preview
Adapting Side-Effects Analysis for Modular
Program Model CheckingM.S. Defense
Oksana Tkachuk
Major Professor: Matthew Dwyer
SupportUS National Science Foundation (NSF CISE/SEL)US Department of Defense Advanced Research Projects Agency (DARPA/IXO PCES) US Army Research Office (ARO CIP/SW)
Software Model Checking
Problems State space explosion due to large data
domains
Solutions Reduction Abstraction Modular Verification
Modular Verification
Unit
Code Base
Unit
Break the entire system into modules and verify one at a time. Module under analysis is called unit
Unit is not self-executable system, need to model environment
Environment Generation Problem
Unit
Code Base
In OO (Java) systems, boundaries and interactions between unit and environment are complex Control effects:
invoking of methods
Data effects: passing data and modifying data
Hard to identify interaction points
Locking, exceptions, global references
Unit
Code Base
Finds points of interaction (unit interface)
Identifies environment classes that directly interact with the unit
Cuts away classes that don’t directly interact with the unit
Generates models for the remaining classes
Solutions in Bandera Environment Generator (BEG)
Environment Models Universal environments
Safe but impractical
Environment assumptions may be used to generate more precise environments User supplied Automatically extracted from
environment implementation using static analysis techniques
Modular Verification
Unit
Code Base
Drivers
Environment classes are broken into
Active classes hold a thread of control (drivers)
Passive classes (stubs)
Stubs
Closed Unit
Java + modeling primitives
+ Unit Properties Java Model Checker
Generation of universal stubs and drivers
Generation of drivers from assumptions (LTL,Regular Expressions) future work: customized control flow
analysis Generation of stubs from
assumptions (Java-like exprs/assignments) static analysis results
side-effects analysis to calculate data effects future work: control effects, safe locks
Current State of Tool Support
In This Talk…
Identifying environment data effects using a customized side-effects analysis Identifying the unit Identifying environment Analyzing environment Modeling environment from analysis
results
Identifying the unit/environment
The unit is user defined based on properties to be checked
BEG scans the unit for external references that drive generation of environment classes
Unit
Stubs
Analyzing Environment
Staged Analysis Scope-based analysis to eliminate
methods that can’t side-effects the unit data
Points-to analysis to approximate objects pointed to by a reference variable in store statements (l.f = r, l[i]=r)
Side-Effects analysis to detect side-effects on the unit data through store statements
Detecting Independent Methods
BEG builds a call graph for environment methods immediately called from unit
Unit
Stubs
Excluding the methods that can’t effect unit data based on scope analysis
Call Graph
Side Effects Analysis
Traditional side-effects analyses are designed to calculate the set of memory locations that may be modified by method execution Do not approximate the values that are
assigned in a store statement (l.f = r, l[i]=r)
Do not distinguish between unit and environment locations
Are usually designed to be fast rather than precise
Tracks side-effects to unit locations, ignores side-effects to environment locations
Tracks the value on the right hand side of side effecting statements (l.f = r, l[i] = r)
Increases precision Flow and context-sensitivity (parameterized) Access-path based with user controlled k-limiting Tracking type and reachabilty of unit locations Calculating must side-effects Incorporating return sensitivity
BEG Side-Effects
Example
class Node { Node next; Data data; …}class … { … void m(Node n, Data d) { n.next.next.data = d; }}
t = n.next;
t = t.next;
t.data = d;
Assignments through References
t = n.next;
t = t.next;
t.data = d;
n
//
d
n.next.next.data = d;
t
next
data//
Assignments through References
//
//
n d
n.next.next.data = d;
next
data
t = n.next;
t = t.next;
t.data = d;
t
Assignments through References
//next
data//
n.next.next.data = d;
n d
t
t = n.next;
t = t.next;
t.data = d;
Assignments through References
//next
data//
nextnextn ..
n.next.next.data = d;
t = n.next;
t = t.next;
t.data = d;
n d
t
1-limited Analysis
//next
data//
n.next.next.data = d;
t = n.next;
t = t.next;
t.data = d;
n d
t
1-limited Analysis
//
t
next
data//
Nodechoose
n.next.next.data = d;
t = n.next;
t = t.next;
t.data = d;
dn
1-limited Analysis with Reachability
n
//
d
t
next
data//
n.next.next.data = d;
t = n.next;
t = t.next;
t.data = d;
1-limited Analysis with Reachability
//
t
next
data//
NodeachUnitnextn Re.
n.next.next.data = d;
t = n.next;
t = t.next;
t.data = d;
n d
Abstract Access Paths Roots: static fields, formal parameters,
new instances
We restrict the tracking of access paths through unit fields
The language of abstract access paths
CCK
U choosereachUnitfroot
AbsPath
|?))()(( 0
)||.( ,SCi newpfCroot
Extension Operatorroot r
l
)
l
rroot
f
r ! r ! l ! .f)
)(. ftypechoosefUf
l=r.f
f
?
Extension Operatorroot r
l
)
l
rroot
f
l=r.f
)(
)(
)(
.
)'(.)'(
)(.)(
)(.)(
ftypeC
ftypeC
ftypek
U
iU
iU
choosefchoose
reachUnitfreachUnit
reachUnitffroot
ffrootfkifroot
Uf
f
Prefixing Operator
root
arg
arg
l = C.m’(arg)
arg p’
return ret’
p’
’(p’)
ret’
root
p’arg
l
’(p’)
ret’
Prefixing Operator
)'/(')'(' ppl
root
p’arg
l
’(p’)
ret’
'
'
0
0
0
))'((
)'(
'))((
)(
C
kUC
kU
C
kUC
kU
choose
fpreachUnit
fp
choose
frootreachUnit
froot
Prefixing Operator
)'/(')'(' ppl
''........'' 11 mn ffffroot
root
p’arg
l
’(p’)
ret’
]))[''((
)(,'')'/('
''...'.'
....
'1
1
kreachUnit
kmnifp
ffp
ffroot
Cm
n
denote
Data Flow Frameworks
Join semi-lattice L Partial ordering v Merge operator t Least element ? Flow, initial point and value Function Space F of monotone
functions over lattice Mapping from labels to transfer
functions f in F
Our Analyses Using DFFMay Pt Must Pt May Se Must Se
L P(Var->P(AbsPath)) P(AbsPath->P(AbsValue))
v µ ¶ µ ¶
t
? ; Var->P(AbsPath)
; AbsPath->P(AbsValue)
F Forward Flow, initial statement s0, initial value ;
Ff
F={f:L! L j 9 lk, lg:f(l)=(l - lk) lg}
fs(l)=(l-Kill(s)) Gen(s)
Pt Analysis Correctnessp ` 1 Bsemantics 2
Rsc ) Rsc
p ` Pt1c Bconcerete paths Pt2
c
Rca ) Rca
p ` Pt1a Babstract paths Pt2
a
Modeling Environment
Example code
Analysis summary
Generated model
void m(Node n, Data d) { n.next.next.data = d;}
}{Re. 21 paramachUnitnextparam Data
void m(Node param1, Data param2) { if(Bandera.choose())
Bandera.chooseReachable(param1.next,”Data”) = param2;}
Examples and Experience
Container Examples Identified container properties and how
to guide the analysis to preserve such properties in the environment
Replicated Workers Found a deadlock
Autopilot Identified mode confusion scenario
Related Work
Side-effects analysis [Landi & Ryder] Parameterized points-to analysis
[Liang & Harrold] Closing open systems [Godefroid] Generation of environment data
[Stoller] Environment assumption generation
[Giannakopoulou et al.]
Limitations and Future Work
Assumptions Atomicity of environment methods Lack of divergence, indefinite blocking, and
lock acquisition in the environment Designing/reusing analyses to
discharge the above assumptions Designing/reusing analyses for drivers Integration with Bandera and Bogor Exploiting richer specifications (e.g.,
JML)
Summary
Overview of BEG capabilities Presentation of
Side-effects analysis Environment modeling strategies
BEG work is ongoing Will be included in the upcoming
Bandera release http://beg.projects.cis.ksu.edu
Recommended