1 / 29

Zing: A Systematic State Explorer for Concurrent Software

Zing: A Systematic State Explorer for Concurrent Software. Tony Andrews Shaz Qadeer Sriram K. Rajamani Jakob Rehof Microsoft Research Presentation modified by Andres Lips. Model Checking. Finding bugs by systematically exploring all possible states of a model

earl
Download Presentation

Zing: A Systematic State Explorer for Concurrent Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. Legend User user “source” Zing Source Code Product Groups model extraction Zing Compiler MSR Model-checker visualization (UML activity) Conformance Checker Zing object code (MSIL) event trace State browser visualization (call graph) Debugger Zing runtime library … Zing’s 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. Processes Process Process Process Stack … IP Locals Params Heap: complex types IP Locals Params … … 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.Count>=1) { 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 thread’s 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? Lipton’s theory of reduction

  23. Transactions and summaries Corollary of Lipton’s 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

More Related