Using Checkers for End-User Shape Analysis National Taiwan University – August 11, 2009 Bor-Yuh...

Using Checkers for End-User Shape Analysis

National Taiwan University – August 11, 2009

Bor-Yuh Evan Chang 張博聿

University of Colorado, Boulder

If some of the symbols are garbled, try either installing TexPoint (http://texpoint.necula.org) or the TeX fonts (http://www.cs.colorado.edu/~bec/texpoint-fonts.zip).

Collaborators: Xavier Rival (INRIA and ENS Paris), George C. Necula (UC Berkeley)

http://texpoint.necula.org/

http://www.cs.colorado.edu/~bec/texpoint-fonts.zip

2

Why think about the analyzer’s end-user?

Bor-Yuh Evan Chang 張博聿 , University of Colorado - Using Checkers in End-User Shape Analysis

User Tool

Accessibility• end-users are not experts in verification and logic• want adoption of our tools and techniques

Expressivity, Efficiency, and Feasibility• end-users are not completely incompetent either• can provide guidance to tools, understand the code best

3

Splitting of summaries (materialization)

To reflect updates precisely

And summarizing for termination (summarization)

Shape analysis is an abstract interpretation on abstract memory descriptions with …

cur

l

cur

“sorted dl list”l

cur

l

cur

l

cur

l

cur

l


Main Design Decision:Summaries and their operations

4

Our Approach: Executable Specifications

Utilize “run-time validation code” as specification for static analysis.

assert(l.purple_dll(null));

for each node cur in list l {make cur red;

}

assert(l.red_dll(null));

l

l

cur

l


h.dll(p) :=if (h = null) then

trueelse

h!prev = p and h!next.dll(h)

checker

Automatically generalize checkers for intermediate states (generalized segment)

• p specifies where prev should point

h.dll(p) :=h = null Æ emp

Ç 9n.h@prev p ¤h@next n ¤n.dll(h)

Build the abstraction for analysis directly out of the developer-supplied validation code

5

Problem: Checkers are incomplete specs

Xisa shape analyzer

abstract interpretation

splitting andinterpreting update

summarizing


h.dll(p) =if (h = null) then

trueelse

h!prev = prev and h!next.dll(h)

checkers

program analysischecker analysis(“pre-program

analysis”)Derives information about checkers to use them effectively

How do we decide where to unfold?

1

How do we decide where to fold?

2What about different checkers for the same structure?

3

Defining a program analysis:1. The abstraction (e.g., separation logic

formulas with inductive definitions) and operations on the abstraction (e.g., unfolding, update)

2. How to effectively apply the operations (harder!)

6

Outline

• Memory abstraction• Guide unfolding (materialization) with

level-type analysis on checker definitions

• Guide folding (summarization) with iteration history – a binary, non-symmetric widening

operator• Prove lemmas amongst checkers with

our parametric shape domain– for a reduction operatorBor-Yuh Evan Chang 張博聿 , University of Colorado - Using Checkers in End-User Shape

Analysis

7

memory cell (points-to: °!next = ±)

Abstract memory as graphs


trueelse



l

®dll(null) dll(¯)

cur

°dll(°)

¯prev

next±

Make endpoints and segments explicit

l dll(±, °)±

“dll segment”

cur

°

®

segment summary

checker summary (inductive pred)

memory address (value)

Some number of memory cells (thin edges)

¯

°@prev ¯¤ °@next ±¤ ±.dll(°)

(®.dll(null) ¤= °.dll(¯)) ¤

Segment generalization of a checker(Intuitively, ®.dll(null) up to °.dll(¯).)

8

Segments asPartial Checker “Runs” (conceptually)

®.dll(null)

¯.dll(®)

°.dll(¯)

±.dll(°)

null.dll(±)

Complete Checker “Run”

Instance

Summary

®dll(¯)

°

c0(¯,°0)

c(®,°)

… …

… ……

® ¯c(°) c0(°0)

ii

i = 0

i = 0

ii 00

c = c0

® = ¯° = °0

® = °¯ = null

nullnext

°next

±prevprev

null® ¯


[POPL’08]

9

Outline






Analysis

10

0

1

-1

-2

Types for deciding where to unfold

®dll(null) dll(¯) dll(¯)

°

dll(®,null)

dll(¯,®)

dll(°,¯)

dll(±,°)

dll(null,±)

Checker “Run” (call tree/derivation)

Instance

Summary

° ±® ¯ nullnull


trueelse


h:{nexth0i,prevh0i }p:{nexth-1i,prevh-1i }

If it exists, where is:

°!next ?

¯!next ?

Checker Definition

0-1

Says:

For h!next/h!prev, unfold from h

For p!next/p!prev, unfold before h


11

Types make the analysis robust with respect to how checkers are written

¯dll(®) dll(¯) dll(¯)

°

Instance

Summaryh.dll(p) =

if (h = null) thentrue

elseh!prev = p and h!next.dll(h)

h:{nexth0i,prevh0i }p:{nexth-1i,prevh-1i }


°¯ null®

¯ ° null

Instance

¯dll0 dll0 dll0

°

Summaryh.dll0() =if (h!next = null)

thentrue

elseh!next!prev = h

and h!next.dll0()

Alternative doubly-linked list checker h:{nexth0i,prevh-1i }

°!prev ? -1

Doubly-linked list checker (as before)

Different types for different unfolding

12

Summary of checker parameter types

Tell where to unfold for which fields

Make analysis robust with respect to how checkers are written

Learn where in summaries unfolding won’t help


Can be inferred automatically with a fixed-point computation on the checker definitions

13

Outline






Analysis

14

Summarizeby folding into inductive predicates

last = l;cur = l!next;while (cur != null) {

// … cur, last …if (…) last =

cur;cur = cur! next;

}

listl, last

nextcur

listl

next nextcurlast

listl

next next nextcurlast

summarize

listlast

listnextcur

listl

Challenge: Precision (e.g., last, cur separated by at least one step)


15

Use iteration history to guide folding


listl

next next nextcurlast

summarize

listlast

listnextcur

listl

Previous approaches guess where to fold for each graph• i.e., which nodes to

drop• e.g., not pointed by

variables

listl, last

nextcur

listl

next nextcurlast

Contribution: Determine where by comparing graphs across history• discover which

nodes to drop and edges to fold simultaneously

16

Outline






Analysis

17

Problem: Non-Unique RepresentationsWith user-guided abstraction, different summaries may have the same (or related) concretizations.


l.dll(p) :=if (l = null) then

trueelse

l!prev = p and l!next.dll(l)

l.dll_back(n) :=if (l = null) then

trueelse

l!next = n and l!prev.dll_back(l)

dll(null)h

h t

dll(null)h dll_back(null) t

checker

summary

concreteinstance

18

Need: Convert between related summaries

1. Prove lemmas about related checkers– e.g., “dll , dll_back”


Observation: Our widening operator can derive these facts on an appropriate programBasic Idea:

l.dll(p) := …

semantics of dll_backparametricabstract domain

summarization(widening)

S

19

Need: Convert between related summaries

2. Find out which lemmas are needed and when to apply them during program analysis– work-in-progress– not in this talk


20

New “Pre-Program Analysis Analysis”

Xisa shape analyzer



summarizing

level-typeinferencefor unfolding



trueelse

h!prev = prev and h!next.dll(h)

checkers


analysis”)

lemma proving for reduction

S S

21

Example: User-Defined List Segments

Want a decision procedure for these inclusions:


l.ls(e) :=if (l = e) then

trueelse

l!next.ls(l)

l.list() :=if (l = null) then

trueelse

l!next.list()

checker

summary

“a list segment” “a segment of a list”

®list() list()

¯

l e

Can reuse our parametric abstract domain!

ls(¯)®

l

¯

e

v ?ls(¯)®

l

¯

e

®list() list()

¯

l e

22

An Alternative Semantics for Checkers


°

set of concrete stores

summary

ls(¯)®

l

¯

e

…l e

addrof(®) addrof(¯)

generator of “concrete” graphs

®

l

¯

e

® = ¯

®

lnext

®0 ¯

e

®0 = ¯

¯

e

®00 = ¯®

lnext

®0next

®00

…

23

Show


®

l

¯

e

® = ¯

®

lnext

®0 ¯

e

®0 = ¯

¯

e

®00 = ¯®

lnext

®0next

®00

…

Apply abstract interpretation using only list as a checker parameter to the domain

vls(¯)®

l

¯

e

®list() list()

¯

l e

®

l

¯

elist() list()

X

®

l

¯

elist() list()

Our widening• is a non-symmetric

binary operator• interleaves region

matching and summarizing

Widening

Properties• Soundness: computes an over-approximation• Termination: ensures chain stabilizes

Algorithm1. Iteratively split regions by matching nodes (ok

by ¤)2. Find common abstraction for matched regions

(calling on v to check inclusion)

[SAS’07]

24

Inclusion Check


®

lnext

®0 ¯

e

®0 = ¯

®

l

¯

elist() list()

v

¯

elist() list()®

lnext

®0

®0 = ¯ ¯

e

®

lnext

®0

®

lnext

®0

®

lnext

®0

Inclusion Check

Algorithm1. Iteratively split

regions by matching nodes

2. Check inclusion by unfolding and matching edges until obvious(emp v emp)

25

Summary: Reuse domain to decide relations amongst checker definitions

Xisa shape analyzer



summarizing

level-typeinferencefor unfolding


dll(h, p) =if (h = null) then

trueelse

h!prev = prev and dll(h!next, h)

checkers


analysis”)

lemma proving for reduction

S S

26

Reduction: Next steps

• Non-unique representation problem magnified with user-supplied checkers– Need reduction to convert between

representations– Ordering on checkers needed to apply reduction

• Ordering shown by applying Xisa to a checker def

• To put into practice– Needed lemmas: pre-compute ordering or on-

demand?– When to apply: level types for unfolding may

help– Derive new checkers (e.g., dll_back from dll)?


27

Summary: Using checkers as specs

Constructing the end-user program analysisIntermediate states: Generalized segment predicates

Splitting: Checker parameter types with levels

Summarizing: History-guided approach

Reduction: Prove lemmas by reusing our domain on checkers

next listlist list listlist

® ¯c(°) c0(°0)

h : {nexth0i, prevh0i}p : {nexth-1i, prevh-1i}


l.dll(p) := …

semantics of dll_backS

28

Conclusion

• Checkers are useful specificationsDeveloper View: Global, Expressed in a familiar

styleAnalysis View: Capture developer intent,

Not arbitrary inductive definitions

• Yet they are incomplete for program analysis– With an executable interpretation, can apply

program analysis to checker definitions– Such “pre-analysis analysis” guides the code

analysis


http://www.cs.colorado.edu/~bec/xisa

Using Checkers for End-User Shape Analysis National Taiwan University – August 11, 2009 Bor-Yuh...

Documents

Transcript of Using Checkers for End-User Shape Analysis National Taiwan University – August 11, 2009 Bor-Yuh...