Modular Shape Analysisfor Dynamically Encapsulated Programs
Noam Rinetzky Tel Aviv University
Arnd Poetzsch-Heffter Universität Kaiserlauten Ganesan Ramalingam Microsoft Research IndiaMooly Sagiv Tel Aviv University Eran Yahav IBM Watson
modular shape analysis
shape analysis?
...
modular analysis?
modular shape analysis
sound static analysis programs
imperative heap-manipulating
properties no memory errors
no memory leaks no null dereferences
shape invariants lists are acyclic
shape analysis
...
modular shape analysis
analyze a program by analyzing its parts scalability reusability
modular analysis
modular shape analysis
sound static analysis programs
imperative heap-manipulating
properties no memory errors
no memory leaks no null dereferences
shape invariants lists are acyclic
analyze a program by analyzing its parts scalability reusability
shape analysis
...
modular analysis
p
analyze programs by analyzing their parts imperative heap-manipulating
modular shape analysis
qPolygon List
Point Integer
memoryprogram
p
analyze programs by analyzing their partsprogram modular analysisheap modular analysis
modular shape analysis
qPolygon List
Point Integer
program parts memoryprogram memory parts
imperative heap-manipulating
p
q
analyze programs by analyzing their partsprogram modular analysisheap modular analysis
modular shape analysis
Polygon List
Point Integer
program part relevant heap parts
p
q
analyze programs by analyzing their partsprogram modular analysisheap modular analysis
modular shape analysis
Polygon List
Point Integer
program part relevant heap parts
analyze programs by analyzing their partsprogram modular analysisheap modular analysis
modular shape analysis
Polygon List
Point Integer
p
q
program part relevant heap parts
analyze programs by analyzing their partsprogram modular analysisheap modular analysis
modular shape analysis
Polygon List
Point Integer
p
q
program part relevant heap parts
analyze programs by analyzing their partsprogram modular analysisheap modular analysis
modular shape analysis
Polygon List
Point Integer
program
approach
restrict class of programs to “well behaved” programs dynamically encapsulated programs
compute conditional module invariant approximate “well behaved” clients
use dynamic encapsulation to enable modular shape analysis, use shape analysis to verify dynamic encapsulation
agenda
setting shape abstraction modular shape analysis
modules simple program model
program = collection of modules module = types + procedures
module level access control
......
Listtype List { Node
hd }type Node { Node n, Point
d}int foo(List s) { Point p = p.d; int x = getX(p);}
p.x;
...
...
int getX(Point p) { Integer I = p.x; return value(I);}
Pointtype Point {Integer
x,y }Point point(int x, int y)
{}
types
procedures
p
q
Polygon List
Point Integer
Polygon
Point Integer
module-local state
module can only access parts of the heap comprised of its objects
module-local state
p
q
Polygon List
Point Integer
module can only access parts of the heap comprised of its objects
components
Polygon List
Point Integer
p
q
sub-heaps objects of one module
maximal connected subheap outgoing references incoming references
p
q
components
Polygon List
Point Integer
sub-heaps objects of one module
maximal connected subheap outgoing references incoming references
List
Point
p
q
component graphs nodes: components edges: inter-component references
p
q
Polygon List
Point Integer
Polygon
Point Integer
(un)sealed components unsealed component mutable sealed component immutable
p
q
Polygon List
Point Integer
Polygon
Point Integer
trimming abstraction
represents only components of a single module forget other components forget component graph
trimming: abstractiont
z
trimming: concretization
t
z
t
z
t
z
t
z
t
z
trimming: concretization
t
z
t
z
trimming: concretization
t
z
t
z
trimming: impossible concretization
bounding abstraction (standard)
q ztrimming
bounding
q
z ...
parametric shape abstraction
concrete states
trimmed states
bounded trimmed states
trimMtrim
M
boundMbound
M
modular shape analysis
main challenges inferring precondition for inter-module
procedure calls to the moduledetermining effect of inter-module procedure
calls by the module
inter-module procedure calls sealed component immutable unsealed component mutable
Polygon List
Point Integer
Polygon
Point Integer
list_proc(p.list, q)
q
p
sealed components
Polygon
Point Integer
Polygon
s
list_proc(p.list, q)
e
sealed component immutable inputs to inter-module procedure calls
q
ListList
module invariant set of sealed (stable) components
in all programs in all executions
all possible inputs to inter-module procedure calls
modular shape analysis infer module invariant analysis
compute input states to inter-module procedure calls
from discovered sealed components
shape analysis within module
discover new sealed components in output states
shapeanalysis
abstraction + fixpoint are we done?
sanity check
Listtype List { Node hd }type Node { Node n, Point d}void push(List s, Node e) { e.n = s.hd; s.hd = e;}
...
sanity check
hd n n
d d d
s
de
n
Listtype List { Node hd }type Node { Node n, Point d}void push(List s, Node e) { e.n = s.hd; s.hd = e;}
...
sanity check
hd n n
d d d
s
de
ne
Listtype List { Node hd }type Node { Node n, Point d}void push(List s, Node e) { e.n = s.hd; s.hd = e;}
...
main difficulty: unknown usage
unknown heap context returned references incoming references
worst case assumption
complicated analysis expensive analysis non-useful analysis
hd n n
d d d
d
n
our approach
limit inter-component aliasingevery sealed component has a single entry point
q p
limit inter-component aliasingevery sealed component has a single entry point tree of inter-component references
p q
our approach
enque(p,q)challenge: reference parameterssolution: ignore unused references
p q
challenge
verify q is never used!
specify deadnessenque(List s, Node e) // {e}
p q
lightweight annotations
limit inter-component aliasingevery component has a single entry point tree of inter-component references ignoring not to be used references
p q
dynamic encapsulation
dynamic encapsulation p
dynamic encapsulation p p
dynamic encapsulation p p
p q
dynamic encapsulation p p
p p q q
sanity check revisited
Listtype List { Node hd }type Node { Node n, Point d}void push(List s, Node e) //
{e} { e.n = s.hd; s.hd = e;}
...
hd n n
d d d
s
de
sanity check revisited
hd n n
d d d
s
de
n
...
Listtype List { Node hd }type Node { Node n, Point d}void push(List s, Node e) //
{e} { e.n = s.hd; s.hd = e;}
sanity check revisited
hd n n
d d d
s
de
n
...
Listtype List { Node hd }type Node { Node n, Point d}void push(List s, Node e) //
{e} { e.n = s.hd; s.hd = e;}
our approach
concentrate on well-behaved programs“well behaved” = dynamic encapsulation
modularly checkableprogram P is well behave if all its modules
respect the specification
for every module assume all other modules are well behavedguarantee module is well behaved
verify dynamic encapsulation discover (conditional) module invariants
may not be hold for arbitrary programs
modular analysis
summary
parametric shape abstraction dynamic encapsulation
restriction on programs modular shape analysis
shape analysis dynamic
encapsulation
enable
verify modular
related work
modular analysis modular heap analysis shape analysis interprocedural shape analysis encapsulation local reasoning
closely related work
modular heap analysisLogozzo, SAS’03, VMCAI’04Wies et al., VMCAI’06
encapsulationZaho et al., RTSS’04Clarke et al., ECOOP’03
modular verificationLeino et al., ESOP’06
future work
relax restrictions richer component-graph structures
implementation
END
use dynamic encapsulation to enable modular shape analysis, use shape analysis to verify dynamic encapsulation
fixpoint
dry run
analysis
Listtype List { Node hd }type Node { Node n, Point d}List crtList() { ... }Node crtNode(Point p) // {p }{ ... }void push(List s, Node e) //
{ e }{ ... }Node pop(List s) { ... }
dry run
analysis
Listtype List { Node hd }type Node { Node n, Point d}List crtList() { ... }Node crtNode(Point p) // {p }{ ... }void push(List s, Node e) //
{ e }{ ... }Node pop(List s) { ... }
p
p
dry run
analysis
Listtype List { Node hd }type Node { Node n, Point d}List crtList() { ... }Node crtNode(Point p) // {p }{ ... }void push(List s, Node e) //
{ e }{ ... }Node pop(List s) { ... }
s e
s e
dry run
analysis
Listtype List { Node hd }type Node { Node n, Point d}List crtList() { ... }Node crtNode(Point p) // {p }{ ... }void push(List s, Node e) //
{ e }{ ... }Node pop(List s) { ... }
s e
s e...
conditional module invariant program dynamically-encapsulated module invariant holds
partitioned module invariant
partitioned module invariant
partitioned module invariant
related work
Manevich et al., TACAS’07
x x
zy
y z x
y
z
ownership types
p
trace
inter-module procedure calls input: sealed component observation: unmodified since last call
inter-module procedure calls input: sealed component observation: unmodified since last call
