Zing: A Systematic State Explorer for Concurrent Software

1
Zing A Systematic State Explorer for Concurrent
Software

• Tony Andrews
• Shaz Qadeer
• Sriram K. Rajamani
• Jakob Rehof
• Microsoft Research

2
Model Checking

• Finding bugs by systematically exploring all
  possible states of a model
• Works for control-dominated hardware and
  protocols
• Model is written manually by someone who
  understands the system
• Typical models are FSMs

3
Model Checking at MSR

• Check source code in common programming languages
• Model can be extracted automatically from the
  code
• Good models are not necessarily FSMs

4
Characteristics of Software

• Primitive values are more complicated
• Pointers
• Objects
• Control flow (transition relation) is more
  complicated
• Functions
• Function pointers
• Exceptions
• States are more complicated
• Unbounded graphs over values
• Variables are scoped
• Locals
• Shared scopes
• Much richer modularity constructs
• Functions
• Classes

5
What is Zing?

• Zing is a framework for software model-checking
• Language, compiler, runtime, tools
• Supports key programming language constructs
• Objects, functions, threads, channels, dynamic
  allocation
• Enables easier extraction of models from code
• Supports research in exploring large state spaces
• New techniques implemented
• compositional model checking
• summarizing procedures with concurrency
• Supports conformance checking

6
Applications of Zing

• Check for errors in sets of web services whose
  behavior is described by BPEL4WS
• Check web services for conformance with
  behavioral contracts
• Check behavior of Windows device drivers under
  concurrent execution
• Find errors in complex application protocols

7
What can we check for?

• Assertion violations
• Zing has assert() statement
• Assertion violations are flagged as errors
• Stuck states
• Deadlock a process is waiting for message that
  is never sent or condition that is never
  satisfied
• Conformance
• Does a communicating process conform to a
  specification (contract) ?

8
Outline

• Overview
• Zing show and tell
• Architecture
• State-space reduction algorithms
• Conformance Checker

9

• Bluetooth driver

10
BPEL4WS checking
BPEL Processes
Buyer
Seller
Zing Model
Auction House
Reg Service
11
Zing features

• objects
• functions (methods)
• dynamic memory allocation
• exceptions
• range type
• sets
• variable-size arrays

• processes
• simple data types
• structures
• arrays
• enums
• communication
• message queues
• shared memory
• blocking
• non-determinism
• atomic blocks

12
Outline

• Overview
• Zing show and tell
• Architecture
• State-space reduction algorithms
• Conformance Checker

13
Zings eco-system
Domain- specific tools
Visual Studio.NET
14
Zing Object Model
Zing Application
StateImpl
Checkers, Simulators, etc.
State
State contains state of the entire model Can
query how many processes are in the state Can
execute a particular process in the state for
one atomic step and return the resulting
state Can compare if two states are equal
15
Zing State Internals
State
Globals simple types refs
16
State explosion

• 5 components, 100 states/component
• Worst case 10 billion states

17
Outline

• Overview
• Zing show and tell
• Architecture
• State-space reduction algorithms
• Conformance Checker

18
Saving storage

• Only states on the checkers stack are stored
• For states not on the stack only a fingerprint is
  stored
• In progress
• Store only deltas from previous states

19
State reduction

• Abstract notion of equality between states
• Avoid exploring similar states several times
• Exploit structure and do this fully automatically
  while computing the fingerprint
• s1 ? s2 ? f(s1) f(s2)

Heap1
100
200
a
b
0
ptr
Heap2
ptr
150
300
b
0
a
20
Interleaving reduction

• Do not explore all interleavings between threads
• Interleave only at transaction boundaries
• Combine atomicity with summarization
• Two level model checking algorithm

21
Transactions

• In a well synchronized concurrent program
• A threads computation can be viewed as a
  sequence of transactions
• While analyzing a transaction, interleavings with
  other threads need not be considered
• Furthermore summarize transactions, leading to
  reuse and efficiency

22

• How do you identify transactions?

Liptons theory of reduction
23
Four atomicities

• R right movers
• lock acquire

• L left movers
• lock release

• B both right left movers
• variable access holding lock

• N non-movers
• access unprotected variable

24
Transaction

• Any sequence of actions whose atomicities are in
  R(N?)L is a transaction

R
R
R
N
R
L
L
S0
S1
S2
S5
S6
S3
S7
S4
Transaction
Precommit
Postcommit
25
Transactions and summaries

• Corollary of Liptons theorem
• No need to schedule other threads in the middle
  of a transaction
• If a procedure body occurs in a transaction, we
  can summarize it!

26
Resource allocator (1)

• bool availableN
• mutex m
• int getResource()
• int i 0
• L0 acquire(m)
• L1 while (i lt N)
• L2 if (availablei)
• L3 availablei false
• L4 release(m)
• L5 return i
• L6 i
• L7 release(m)
• L8 return i

Choose N 2 Summaries ltpc, i, m,
(a0,a1)gt ? ltpc, i, m, (a0,a1)gt
ltL0, 0, 0, (0, 0)gt ? ltL8, 2, 0,
(0,0)gt ltL0, 0, 0, (0, 1)gt ? ltL5, 1,
0, (0,0)gt ltL0, 0, 0, (1, 0)gt ? ltL5,
0, 0, (0,0)gt ltL0, 0, 0, (1, 1)gt ?
ltL5, 0, 0, (0,1)gt
27
Resource allocator (2)

• bool availableN
• mutex mN
• int getResource()
• int i 0
• L0 while (i lt N)
• L1 acquire(mi)
• L2 if (availablei)
• L3 availablei false
• L4 release(mi)
• L5 return i
• else
• L6 release(mi)
• L7 i
• L8 return i

Choose N 2 Summaries ltpc,i,(m0,m1),(a0,
a1gt ? ltpc,i,(m0,m1),(a0,a1)gt
ltL0, 0, (0,0), (0,0)gt ? ltL1, 1, (0,0), (0,0)gt
ltL0, 0, (0,0), (0,1)gt ? ltL1, 1, (0,0), (0,1)gt
ltL0, 0, (0,0), (1,0)gt ? ltL5, 0, (0,0), (0,0)gt
ltL0, 0, (0,0), (1,1)gt ? ltL5, 0, (0,0), (0,1)gt
ltL1, 1, (0,0), (0,0)gt ? ltL8, 2, (0,0), (0,0)gt
ltL1, 1, (0,0), (0,1)gt ? ltL5, 1, (0,0), (0,0)gt
ltL1, 1, (0,0), (1,0)gt ? ltL8, 2, (0,0), (1,0)gt
ltL1, 1, (0,0), (1,1)gt ? ltL5, 1, (0,0), (1,0)gt
28
Abstraction

• Represent only aspects of the program relevant to
  property being checked
• Automatic iterative refinement of abstractions
• Use regions to construct conservative
  abstractions of the heap

29
Composition

• Divide and conquer
• Check one component of the model at a time
• Requires behavioral contracts

30
Outline

• Overview
• Zing show and tell
• Architecture
• State-space reduction algorithms
• Conformance Checker

31
Contract checking

• Does each implementation conform to its contract?
• Example
• Does A conform to CA?
• Use only CB and CC (and not B and C during this
  check)

CA
?
CB
CC
A
32
Contract checking
33
Conformance and Zing

• Conformance was originally defined syntactically
  for CCS
• Tony Hoare helped us generalize definition to
  make it purely semantic
• makes no assumptions about the syntactic
  structure of the processes
• can work for any system where we can observe
  externally visible behavior for processes
• we have implemented exactly this on top of Zing!

34
Conformance Checker

• void doDfs(State initImpl, State initSpec)
• addState(initImpl, initSpec)
• while(dfsStack.Count gt 0)
• StatePair pair
  dfsStack.Peek()
• State I pair.first()
• State S pair.second()
  
• State newI I.GetNextSuccessor()
  
• // lookup the events on the
  transition from I to newI
• if (newI null)
• if (isStable(I))
• // first get all the
  events we executed from I
• Event IEvents
  I.AccumulateEvents
• if (!checkRefusals(S,
  IEvents))
• Console.WriteLine(Contract over-promises)
• 
  generateError(I, S)
• return

Stack dfsStack Hashtable stateHash void
addState(State i, State s) StatePair
combinedState new StatePair(i,s)
if(!stateHash.contains(combinedState))
stateHash.add(combinedState)
dfsStack.push(combinedState)
State executeWithTrace(State s, Event l )
S S ? l ? S, if such S exists null
otherwise Bool checkRefusals(State s,
Event L) true exists stable S such
that S ? ? ? S, and for all l, if
S ? l ? then l ? L false otherwise
35
(No Transcript)