Title: Zing: A Systematic State Explorer for Concurrent Software
1Zing A Systematic State Explorer for Concurrent
Software
- Tony Andrews
- Shaz Qadeer
- Sriram K. Rajamani
- Jakob Rehof
- Microsoft Research
- Presentation modified by Andres Lips
2Model 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
3Model Checking at MSR
- Check source code in common programming languages
- Model can be extracted automatically from the
code - Good models are not necessarily FSMs
4Characteristics 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
5How expressive should a model be?
- Very restrictive (such as FSM)?
- Directly on programming language?
- Balanced
- Procedure calls with call-stack
- Objects with dynamic allocation
- Processes with dynamic creation
6What is Zing?
- Zing is a framework for software model-checking
- Zing components
- Modelling language and compiler
- A systematic state axploration infrastructure
- Support infrastructure for automatic generation
of models from source code - Not a programming language
- Code structure is preserved in model
7Zing features
- Concyrrency models with support for shared memory
and message passing - Control constructs
- Sequential flow
- Branching
- Iteration
- Function calls (including asynchronous)
- Exception handling
8Zing features (2)
- Data
- Primitive types
- Reference types
- Object model similar to C and Java
- Inheritance not supported
9Zing features (3)
- Support for abstraction and efficient state
exploration - Atomicity brackets
- Sets
- Non-deterministic choice
- To abstract irrelevant data from code
- To support region-based alias analysis
10Zing features (4)
- 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
11What 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) ?
12Zings architecture
Domain- specific tools
Visual Studio.NET
13Zing Object Model
Zing Application
StateImpl
Checkers, Simulators, etc.
State
State contains state of the entire model
14Zing Object Model Internal State View
State
Globals simple types refs
15Zing Object Model Internal State View (2)
- Process stacks and heap can grow without limit at
runtime - Price of that Zing is not guaranteed to
terminate on every model
16Zing Object Model External State View
- Simplified view to query and update state
- How many processes?
- Is process(i) runnable?
- Are two states equal?
- Execute process(i) for one atomic step
- Can write simple DFS search in 10 lines
17Simple DFS model checker
- Stack dfsStack
- Hashtable stateHash
- void addState(State I)
- if (!stateHash.Contains(I))
- stateHash.Add(I)
- dfsStack.Push(I)
-
-
- Void doDfs(State initialState)
- addState(initialImplState)
- while (dfsStack.Countgt1)
- State I (State)dfsStack.Peek()
- State newI I.GetNextSuccessor()
- if (newI ! null)
- addState(newI)
- else
- dfsStack.Pop()
18Saving 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
19State 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
20Interleaving reduction
- Do not explore all interleavings between threads
- Interleave only at transaction boundaries
- Combine atomicity with summarization
- Two level model checking algorithm
21Transactions
- 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
23Transactions 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!
24Abstraction
- 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
25Composition
- Divide and conquer
- Check one component of the model at a time
- Requires behavioral contracts
26Summary
- Possibility to extract sound models from
concurrent programs - To enable it ZML has procedure calls, objects and
processes - Intermediate model ZOM
- Various model checker van be written on top of it
- ZML preserves abstraction boundaries in the
source program - Using it helps to alleviate the state explosion
problem
27Future plans
- Improving algorithm usage
- Handling non-determinism in data
- SLAM-like iterative refinement loop
- Goal is to keep the architecture flexible and
open - Offering possibility to write third party
translators from code to model
28Place of Zing in landscape
- Zing can be compared to SPIN, JPF, BOGOR and
SLAM. - Compared to SPIN, Zing supports several features
like objects and function calls - Compared to JPF and Bogor, newer algorithms are
used for reduction and summarization - Unlike SLAM, Zing handles concurrent programs
29(No Transcript)