Zing: A Systematic State Explorer for Concurrent Software

1 / 29
About This Presentation
Title:

Zing: A Systematic State Explorer for Concurrent Software

Description:

Process stacks and heap can grow without limit at runtime ... states on the checkers stack are stored. For states not on the stack only a fingerprint is stored ... –

Number of Views:91
Avg rating:3.0/5.0
Slides: 30
Provided by: Moni73
Category:

less

Transcript and Presenter's Notes

Title: 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
  • Presentation modified by Andres Lips

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
How 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

6
What 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

7
Zing features
  • Concyrrency models with support for shared memory
    and message passing
  • Control constructs
  • Sequential flow
  • Branching
  • Iteration
  • Function calls (including asynchronous)
  • Exception handling

8
Zing features (2)
  • Data
  • Primitive types
  • Reference types
  • Object model similar to C and Java
  • Inheritance not supported

9
Zing 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

10
Zing 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

11
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) ?

12
Zings architecture
Domain- specific tools
Visual Studio.NET
13
Zing Object Model
Zing Application
StateImpl
Checkers, Simulators, etc.
State
State contains state of the entire model
14
Zing Object Model Internal State View
State
Globals simple types refs
15
Zing 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

16
Zing 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

17
Simple 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()

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
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!

24
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

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

26
Summary
  • 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

27
Future 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

28
Place 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)
Write a Comment
User Comments (0)
About PowerShow.com