V yrdMC : Driving Runtime Refinement Checking Using Model Checkers

19.Nisan.2023 PLDI 2005, June 12-15, Chicago, U.S. 1

Tayfun Elmas, Serdar TasiranTayfun Elmas, Serdar Tasiran

Koç University, Istanbul, TurkeyKoç University, Istanbul, Turkey

VVyrdMCyrdMC:: Driving Runtime Driving Runtime Refinement Checking Using Refinement Checking Using

Model CheckersModel Checkers


MotivationMotivation• Verification/testing of concurrent programs difficult• Exhaustive methods: State space too big,

compounded by thread interleavings• Testing: Scalable but not exhaustive• Our work: Hybrid methods

– Testing + model checking

• Coverage metrics: Link between testing and model checking– Quantify adequacy of testing/verification– Communicate partial results, testing goals between tools– Direct tools toward unexplored, distinct new executions

Coverage metric for Coverage metric for concurrent programsconcurrent programs


IdeaIdea• This paper: Metric directed at concurrency errors ONLY• Focus: “High-level” data races

– Atomicity violations– Refinement violations– All variables may be lock-protected,

but operations not implemented atomically


IdeaIdea• Observation: Bug occurs whenever

– Method1 executes up to line X, context switch occurs– Method2 starts execution from line Y– Provided there is a data dependency between

• Method1’s code “right before” line X: BlockX• Method2’s code “right after” line Y: BlockY

• Bug description follows pattern above• No other requirements on program state, other

threads, method arguments, etc.• A “one-bit” data abstraction captures error scenario

– Depdt: Is there a data dependency between BlockX and BlockY


IdeaIdea• A “one-bit” data abstraction captures error scenario

– Depdt: Is there a data dependency between BlockX and BlockY

– Many other conditions may need to be set up: • Many other threads• Particular, complicated program state

• But testing target easy to describe• Programmer thinks BlockY cannot follow BlockX

because of assumptions about– the environment accessing the component– synchronization mechanism used


OutlineOutline

• Motivating examples– The java.lang.StringBuffer bug– The bug in Boxwood.Cache

• The Location Pairs (LP) Metric• Reducing the Coverage Goal• Approximating reachable LP’s

int len = sb.length();

ensureCapacity(newCount);

int newCount = count + len;

if (newCount > value.length)

count = newCount;

return this;

sb.getChars(0, len, value, count);

public synchronized StringBuffer append(StringBuffer sb) {

}

...

} else {

if (count < newLength)

...

}

return this;

count = newLength;

public synchronized void setLength(int newLength) {

}


handle

handle

T Z

Chunk Manager

X Y

Cache

handle

handle

X Z

Chunk Manager

A Y

Cache

handle

handle

A Y

Chunk Manager

A B

Cache

handle

handle

A Y

Chunk Manager

A B

Cache

Write(handle,AB) starts

Flush()starts

Flush() ends

Write(handle, AB)

ends

ExperienceExperience Concurrency Bug in Concurrency Bug in CacheCache

handle

handle

A Y

Chunk Manager

A Y

Cache

Different byte-arrays for the same handle

Corrupted data in persistent storage

}

te.data[i] = buf[i];

for (int i=0; i<buf.length; i++) {

te.lsn = lsn

private static void CpToCache( byte[] buf, CacheEntry te, int lsn, Handle h sb) {

}

...

lock (clean) {

BoxMain.alloc.Write(h, te.data, te.data.length, 0, 0, WRITE_TYPE_RAW);

}

...

public static void Flush(int lsn) {

}

-----------------------------------acquire(this)-----------------------------------invoke sb.length()

--------------------------– L1 ----int len = sb.length()

--------------------------- L2 ----int newCount = count + len

-----------------------------------invoke sb.getChar()-----------------------------------sb.getChars(0, len, value, count)--------------------------–--------count = newCount-----------------------------------return this

-----------------------------------if (newCount > value.length)

-----------------------------------expandCapacity(newCount);

public synchronized StringBuffer append(StringBufer sb) {

1 int len = sb.length();2 int newCount = count + len;3 if (newCount > value.length) {4 ensureCapacity(newCount);5 sb.getChars(0, len, value, count);6 count = newCount;7 return this;8 }


Coverage FSM StateCoverage FSM State

Method 1

Method 2

(LX, pend1, LY, pend2, depdt)

Location inthe CFG ofMethod 1

Is an “interesting” action in Method 1 is expected next?

Location inthe CFG ofMethod 2Is an

“interesting” action in Method 2 expected next?

Do actions following LX and LY have a data dependency?


Coverage FSMCoverage FSM

(L1, !pend1, L3, !pend2, depdt)

(L2, !pend1, L3, pend2, !depdt)

(L1, pend1, L3, !pend2, !depdt)

(L1, !pend1, L3, !pend2, !depdt)

t1: L1

L2

t1: L1

L2

t2: L3 L4

t2: L3 L4


Coverage GoalCoverage Goal• The “pend1” bit gets set when

– The depdt bit is TRUE– Method2 takes an action– Intition: Method1’s dependent action must follow

• Must cover all (reachable) transitions of the form– p = (LXp, TRUE, LYp, pend2p, depdtp)

q = (LXq, pend1q, LYq, pend2q, depdtq)

– p = (LXp, pend1p, LYp, TRUE, depdtp)

q = (LXq, pend1q, LYq, pend2q, depdtq)

• Separate coverage FSM for each method pair– Cover transitions in each FSM


Important DetailsImportant Details• Action: Atomically executed code

fragment– Defined by the language

• Method calls:– Call action: Method call, all lock acquisitions– Return action: Total net effect of method,

atomically executed + lock releases

• But what if there is interesting concurrency inside called method?– Considered separately when that method is

considered as one in the method pair


Reducing the Coverage FSMReducing the Coverage FSM• Method-local actions:

– Basic block consisting of method-local actions considered a single atomic action

• Atomic blocks:– User can annotate code blocks “atomic”– Block considered as single action

• Pure blocks:– A “pure” execution of pure block does not affect global state

• Example: Acquire lock, read global variable, decide resource not free, release lock

– Considered a “no-op”– Modeled by “bypass transition” in coverage FSM. Does not

need to be covered


Evidence, estimate on # of Evidence, estimate on # of locationslocations• Errors captured by metric

– 100% metric Bug guaranteed to be triggered• Preliminary study

– Bugs in Java class libraries– Bug found in Boxwood– Bug found in Scan file system– Bugs in

E. Farchi, Y. Nir, S. Ur Concurrent Bug Patterns and How to Test Them 17th Intl. Parallel and Distributed Processing Symposium (IDPDS ’03)

• # of location pairs after factoring out atomic and pure blocks– 100s

• How many are covered by random testing? How does coverage scale over time?– Don’t know yet. Students implementing coverage measurement tool.


Future Work: Approximating Reachable Future Work: Approximating Reachable LP SetLP Set

• Caveat: LP reachability undecidable– Metric only intended as aid to programmer

•What have I tested?•What should I try to test?•Make sure LP does not lead to error if it

looks like it can be exercised.• Future work: Better approximate reachable LP

set– Do conservative reachability analysis of

coverage FSM for one method pair using predicate abstraction.

V yrdMC : Driving Runtime Refinement Checking Using Model Checkers

Documents

Transcript of V yrdMC : Driving Runtime Refinement Checking Using Model Checkers