adapting side-effects analysis for modular program model checking m.s. defense oksana tkachuk major...

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