daniel jacksonstatic analysis symposium ·santa barbara ·

june 2k

logic,models&

analysis

2

my green eggs and ham

·two languages in any analysis·first order relational logic·models in their own right

3

plan of talk

·Alloy, a RISC notation·models of software·analysis reduced to SAT·finding bugs with constraints

4

an example

model CeilingsAndFloors {domain { Man, Platform }state { ceiling, floor : Man -> Platform! }

// one man’s ceiling is another man’s floorinv { all m: Man | some n: Man - m | m.ceiling = n.floor }

// one man’s floor is another man’s ceilingassert { all m: Man | some n: Man - m | m.floor = n.ceiling }}

5

kernel: type decls

d decls, x typexps, t types

d ::= v : xx ::= t | t -> t | t => x

sample declsFile, Dir, Root : Objectdir : Object => Name -> Object

entries : Object -> DirEntryname : DirEntry -> Namecontents : DirEntry -> Object

parent : Object -> Object

scalars are singleton sets

funcs are first-order(t1 => t2 -> t3)

equiv to (t1 x t2 -> t3)

missing:(t1 -> t2) -> t3

6

kernel: expressions

f formulas, e exps, v vars

e ::= e + e | e & e | e - e set ops| ~ e | + e relational ops

| e . eimage| e [v] application| {v : t | f}

comprehension| v

sample exprsRoot.~parent & Filed.entries.contentsn.dir [d]

navigation

7

kernel: formulas

f ::=e in e subset| f && f | !f logic ops| all v : t | f quantification

sample formulasFile+Dir-Root in Root.+~parentall d: DirEntry | ! d in d.contents.entries

in used forsubset and

membership

8

shorthands

declarations·domain {d} declares d : _d·use sets on RHS·multiplicities: + 1, ? 1, ! 1

domain {Object, DirEntry, Name}state { partition File, Dir : Object

Root: Dir !entries: Dir ! -> DirEntryname: DirEntry -> Name !contents: DirEntry -> Object !parent (~children) : Object -> Dir ? }

9

more shorthands

quantifierssole v: t | f some w: t | { v: t | f } in wall x | f all x : d | f where d is inferred domain

Q e Q v | v in e

sample invariants// object has at most one parentall o | sole o.parent // root has no parentsno Root.parent// all other directories have one parentall d: Dir - Root | one d.parent

10

sample model: intentional naming

INS·Balakrishnan et al, SOSP 1999·naming scheme based on specs

why we picked INS·naming vital to infrastructure·INS more flexible than Jini, COM, etc

what we did·analyzed lookup operation·based model on SOSP paper & Java code

11

intentional naming

attribute/value pairscity: cambridge

hierarchical specscity: cambridge, building: ne43, room: 524service: camera, resolution: hiservice: printer, postscript: level2

lookup·database maps spec to set of records·query is set of specs·lookup returns records meeting all specs

12

building

camera

service

ne43

query

n1n0

building

camera

service

ne43 printer

database

tree representation

n0

n1

n0

n0

13

strategy

model database & queries·characterize by constraints·generate samples

check properties·obvious

no record returned when no attributes match·claims

“wildcards are equivalent to omissions”·essential

additions to DB don’t reduce query results

discuss and refine …

14

alloy model: state

model INS {domain {Attribute, Value, Record}state {

Root : fixed Value!

valQ : Attribute? -> Value?attQ : Value? -> Attribute

valDB : Attribute? -> Value attDB : Value? -> Attribute rec : Value + -> Record

lookup : Value -> Record}

15

alloy model: constraints

// Root is not the value of an attributeinv Q1 {no Root.~valQ}

// if query and DB share a leaf value, lookup returns its recordsinv Lookup1 {all v | no v.attQ || no v.attDB -> v.lookup = v.rec}

// adding a record doesn’t reduce resultsassert LookupOK7 {AddRecord -> Root.lookup in Root.lookup'}

16

checking assertions

selectscope

runcheck

counter?

fixmodel

slow?real?

incrscope

propfails

propholds

YY

N

N

YN

3 attrs,vals, recs

17

results

12 assertions checked·when query is subtree, ok·found known bugs in paper·found bugs in fixes too·monotonicity violated

18

counterexample

type

mono

n1

service

printer

database query

service

printer

type

mono

size

A4

n1

n0

size

A4

19

time & effort

costs

2 weeks modelling, ~70 + 50 lines Alloycf. 1400 + 900 lines code

all bugs found in < 10 secs with scope of 42 records, 2 attrs, 3 values usually enoughcf. a year of use

exhausts scope of 5 in 30 secs maxspace of approx 10^20 cases

20

other modelling experiences

microsoft COM (Sullivan)·automated & simplified: 99 lines·no encapsulation

air traffic control (Zhang)·collaborative arrival planner·ghost planes at US/Canada border

PANS phone (Zave)·multiplexing + conferencing·light gets stuck

21

why modelling improves designs

rapid experimentationarticulating essencesimplifying designcatching showstopper bugs

22

how analyzer works

what you learned in CS 101·3-SAT: first NP-c problem·to show a problem is hard

reduce SAT to it

what we know now·SAT is usually easy·to show a problem is easy

reduce it to SAT

key to reduction·consider finite scope: type

small scope hypothesis

most interesting cases

have illustrationsin small scopes

23

architecture

translateproblem

translatesolution

mapping

booleanformula

booleansolution

SATsolver

alloyproblem

alloyresult

scope

24

example

problema, b : Sp : S -> T! (a – b).p in (a.p – b.p)

a model in a scope of 2S = {S0, S1}T = {T0, T1}p = {(S0, T0), (S1, T0)}a = {S0}b = {S1}

S0

S1

T0

T1

a

b

p

25

translation scheme

represent·set as vector of bool var

a [a0 a1]b [b0 b1]

·relation as matrixp [p00 p01 , p10 p11]

translate·set expr to vector of bool formula

XT [a - b]i = XT [a]i XT [b]iXT [a . b]i = j. XT [a]j XT [b]ji

·relational expr to matrix of bool formula·formula to bool formulas

a0 , b1 , p00 , p10

S0

S1

T0

T1

a

b

p

26

translation

a [a0 a1]b [b0 b1]p [p00 p01 , p10 p11]a – b [a0 b0 a1 b1](a – b).p [(a0 b0 p00) (a1 b1 p10) …]a.p [(a0 p00) (a1 p10) (a0 p01) (a1 p11)]b.p [(b0 p00) (b1 p10) (b0 p01) (b1 p11)]a.p – b.p [((a0 p00) (a1 p10)) ((b0 p00) (b1 p10)) …]

! (a – b).p in (a.p – b.p) (((a0b0 p00) (a1b1 p10)

((a0 p00) (a1 p10)) ((b0 p00) (b1 p10))))

…

27

tricks

quantifiers·could expand into conjunctions·but how to make modular?·translate formula into tree indexed on var

avoiding blowup·solvers expect CNF·standard var intro tricks

symmetry·all our domains are uninterpreted·many equivalent assignments·add symmetry-breaking predicates

28

how (not) to delete

class List {List next; Val val;}

void static delete (List p, Val v) { List prev = null; while (p != NULL) if (p.val == v) { prev.next = p.next ; return; } else { prev = p ; p = p.next ; }

29

specifying delete

basic specp.*next’ = p.*next – {c | c.val = v}

as Alloy modeldomain {List, Val}state {

next : List -> List?val : List -> Val?p : List? , v : Val?}

op MergeCode { … }op MergeSpec {p.*next’ = p.*next – {c | c.val = v}}assert {MergeCode -> MergeSpec}

30

hacking delete (1)

counter #1: first cell has value vcond Mask {p.val != v}assert {MergeCode && Mask -> MergeSpec}

p

vval

31

hacking delete (2)

counter #2: two cells with value vcond RI {all x | sole c: p.*next | c.val = x}assert {MergeCode && Mask && RI -> MergeSpec}

assert {MergeCode && RI -> RI’}next

vval val

p

val

next

32

step 1: unroll control flow graph

void static delete (List p, Val v) { List prev = null; while (p != NULL) if (p.val == v) { prev.next = p.next ; return; } else { prev = p ; p = p.next ; }

0

1

2

3

4 6

5 7

8

prev = NULL

p != NULLp == NULL

p.val == v p.val != v

prev = p

p = p.next

prev.next = p.next

return

p == NULL

33

step 2: encode control flow

E01 -> E12 || E13E13 -> E34 || E36E34 -> E45E45 -> E52E36 -> E67E67 -> E78E78 -> E82

0

1

2

3

4 6

5 7

8

prev = NULL

p != NULLp == NULL

p.val == v p.val != v

prev = p

p = p.next

prev.next = p.next

return

p == NULL

34

step 3: encode dataflow

E36 -> p3.val3 != v3

E45 ->prev4.next5 = p4.next4

E78 -> p8 = p7.next7

0

1

2

3

4 6

5 7

8

prev = NULL

p != NULLp == NULL

p.val == v p.val != v

prev = p

p = p.next

prev.next = p.next

return

p == NULL

35

frame conditions

must say what doesn’t change·so add p6 = p7

but·don’t need a different p at each node·share vars across paths·eliminates most frame conditions

36

sample results

on Sagiv & Dor’s suite of small list procedures·reverse, rotate, delete, insert, merge·wrote partial specs (eg, set containment on cells)·predefined specs for null deref, cyclic list creation

anomalies found·1 unrolling·scope of 1·< 1 second

specs checked·3 unrollings·scope of 3·< 12 seconds

37

promising?

nice features·expressive specs·counterexample traces·easily instrumented

compositionality·specs for missing code·summarize code with formula

analysis properties·code formula same for all specs·exploit advances in SAT

38

summary

·Alloy, a tiny logic of sets & relations·declarative models, not abstract programs·analysis based on SAT·translating code to Alloy

challenge·checking key design properties·global object model invariants·looking at CTAS air-traffic control·abstraction, shape analysis …?

39

related work

checking against logic·Sagiv, Reps & Wilhelm’s PSA·Extended Static Checker

using constraints·Ernst, Kautz, Selman & co: planning·Biere et al: linear temporal logic·Podelski’s array bounds

extracting models from code·SLAM’s boolean programs·Bandera’s automata

40

You do not like them.So you say.Try them! Try them!And you may.Try them and you may, I say.

sdg.lcs.mit.edu/alloy