1 / 49

Context-bounded model checking of concurrent software

Context-bounded model checking of concurrent software. Shaz Qadeer Microsoft Research. Joint work with: Jakob Rehof, Microsoft Research Dinghao Wu, Princeton University. . . . . . . . . . . . . . . . . . . . . . . . .

inga
Télécharger la présentation

Context-bounded model checking of 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. Context-bounded model checking of concurrent software Shaz Qadeer Microsoft Research • Joint work with: • Jakob Rehof, Microsoft Research • Dinghao Wu, Princeton University

  2.                        Concurrent software • Operating systems, device drivers • Databases, web servers, browsers, GUIs, ... • Modern languages: C#, Java Thread 1 Processor 1 Thread 2 Thread 3 Processor 2 Thread 4

  3. Concurrency is increasingly important • New classes of concurrent software • Web services • Workflows • Single-chip multiprocessors are an architectural inflexion point • Software running on these chips will be even more concurrent

  4. Reliable concurrent software? • Correctness Problem • does program behaves correctly for allinputs and allinterleavings? • Bugs due to concurrency are insidious • non-deterministic, timing dependent • difficult to detect, reproduce, eliminate • coverage from testing very poor

  5. Analysis of concurrent programs is difficult (1) • Finite-data single-procedure program • n lines • m states for global data variables • 1 thread • n * m states • K threads • (n)K * m states

  6. Analysis of concurrent programs is difficult (2) • Finite-data program with procedures • n lines • m states for global data variables • 1 thread • Infinite number of states • Can still decide assertions in O(n * m3) • SLAM, ESP, BLAST implement this algorithm • K  2 threads • Undecidable! (Ramalingam 00)

  7. Context-bounded verification of concurrent software Context switch Context switch           Context Context Context Analyze all executions with small number of context switches !

  8. Why context-bounded analysis? • Many subtle concurrency errors are manifested in executions with a small number of contexts • Context-bounded analysis can be performed efficiently

  9. KISS: A static checker for concurrent software • An implementation of context-bounded analysis • Technique to use any sequential checker to perform context-bounded concurrency analysis • Has found a number of concurrency errors in NT device drivers

  10. KISS: A static checker for concurrent software No error found  Sequential Checker KISS Concurrent program P Sequential program Q  Error in Q indicates error in P

  11. KISS: A static checker for concurrent software No error found  KISS SDV Concurrent program P Sequential program Q  Error in Q indicates error in P

  12. KISS: A static checker for concurrent software No error found  KISS PREfix Concurrent program P Sequential program Q  Error in Q indicates error in P

  13. KISS: A static checker for concurrent software No error found  KISS ESP Concurrent program P Sequential program Q  Error in Q indicates error in P

  14. Inside a static checker for sequential programs int x, y, z; void foo ( ) { if (x > y) { y = x; } if (y > z) { z = y; } assert (x ≤ z); } • Symbolically analyze all paths • Check the assertion for each path • Interprocedural analysis • e.g., PREfix, ESP, SLAM, BLAST

  15. KISS SDV Concurrent program P Sequential program Q  KISS strategy • Q encodes executions of P with small number of context switches • instrumentation introduces lots of extra paths to mimic context switches • Leverage all-path analysis of sequential checkers

  16. DispatchRoutine( ) { int t; if (! de->stopping) { AtomicIncr(& de->count); // do useful work // … t = AtomicDecr(& de->count); if (t == 0) SetEvent(& de->stopEvent); } } PnpStop( ) { int t; de->stopping = T; t = AtomicDecr(& de->count); if (t == 0) SetEvent(& de->stopEvent); WaitEvent(& de->stopEvent); }

  17. DispatchRoutine( ) { int t; if (! de->stopping) { AtomicIncr(& de->count); // do useful work // … t = AtomicDecr(& de->count); if (t == 0) SetEvent(& de->stopEvent); } } PnpStop( ) { int t; if ($) return; de->stopping = T; if ($) return; t = AtomicDecr(& de->count); if ($) return; if (t == 0) SetEvent(& de->stopEvent); if ($) return; WaitEvent(& de->stopEvent); }

  18. if ( !done ) { if ($) { done = T; PnpStop( ); } } bool done = F;  CODE DispatchRoutine( ) { int t; CODE; if (! de->stopping) { CODE; AtomicIncr(& de->count); // do useful work // … CODE; t = AtomicDecr(& de->count); CODE; if (t == 0) SetEvent(& de->stopEvent); } } PnpStop( ) { int t; if ($) return; de->stopping = T; if ($) return; t = AtomicDecr(& de->count); if ($) return; if (t == 0) SetEvent(& de->stopEvent); if ($) return; WaitEvent(& de->stopEvent); }

  19. if ( !done ) { if ($) { done = T; PnpStop( ); } } bool done = F;  CODE DispatchRoutine( ) { int t; CODE; if (! de->stopping) { CODE; AtomicIncr(& de->count); // do useful work // … CODE; t = AtomicDecr(& de->count); CODE; if (t == 0) SetEvent(& de->stopEvent); } } PnpStop( ) { int t; if ($) return; de->stopping = T; if ($) return; t = AtomicDecr(& de->count); if ($) return; if (t == 0) SetEvent(& de->stopEvent); if ($) return; WaitEvent(& de->stopEvent); } main( ) { DispatchRoutine( ); }

  20. if ( !done ) { if ($) { done = T; PnpStop( ); } } bool done = F;  CODE DispatchRoutine( ) { int t; if ($) return; if (! de->stopping) { if ($) return; AtomicIncr(& de->count); // do useful work // … if ($) return; t = AtomicDecr(& de->count); if ($) return; if (t == 0) SetEvent(& de->stopEvent); } } PnpStop( ) { int t; CODE; de->stopping = T; CODE; t = AtomicDecr(& de->count); CODE; if (t == 0) SetEvent(& de->stopEvent); CODE; WaitEvent(& de->stopEvent); } main( ) { PnpStop( ); }

  21. KISS features • KISS trades off soundness for scalability • Cost of analyzing a concurrent program P = cost of analyzing a sequential program Q • Size of Q asymptotically same as size of P • Unsoundness is precisely quantifiable • for 2-thread program, explores all executions with up to two context switches • for n-thread program, explores up to 2n-2 context switches • Allows any sequential checker to analyze concurrency

  22. Experimental Evaluation of KISS

  23. Driver Stopping Error in Bluetooth Driver (1 KLOC) DispatchRoutine() { int t; if (! de->stopping) { AtomicIncr(& de->count); assert ! driverStopped; // do useful work // … t = AtomicDecr(& de->count); if (t == 0) SetEvent(& de->stopEvent); } } PnpStop() { int t; de->stopping = T; t = AtomicDecr(& de->count); if (t == 0) SetEvent(& de->stopEvent); WaitEvent(& de->stopEvent); driverStopped = T; }

  24. int t; de->stopping = T; t = AtomicDecr(& de->count); if (t == 0) SetEvent(& de->stopEvent); WaitEvent(& de->stopEvent); driverStopped = T; AtomicIncr(& de->count); assert ! driverStopped; // do useful work // … t = AtomicDecr(& de->count); if (t == 0) SetEvent(& de->stopEvent); } int t; if (! de->stopping) { Assertion fails!

  25. IRP Cancellation Error in Packet Driver (2.5 KLOC) DispatchRoutine(IRP *irp) { … irp->CancelRoutine = PacketCancelRoutine; Enqueue(irp); IoMarkIrpPending(irp); … } IoCancelIrp(IRP *irp) { IoAcquireCancelSpinLock(); if (irp->CancelRoutine) { (irp->CancelRoutine)(irp); } … } PacketCancelRoutine(IRP *irp) { … Dequeue(irp); IoCompleteRequest(irp); IoReleaseCancelSpinLock(); … }

  26. IoAcquireCancelSpinLock(); if (irp->CancelRoutine) { // inline PacketCancelRoutine(irp) … Dequeue(irp); IoCompleteRequest(irp); IoReleaseCancelSpinLock(); IoMarkIrpPending(irp); … irp->CancelRoutine = PacketCancelRoutine; Enqueue(irp); Error: An irp should not be marked pending after it has been completed !

  27. Data-race Conditions in DDK Sample Drivers • Device extension shared among threads • Data-races on device extension fields • 18 sample DDK drivers • Range 0.5-9.2 KLOC • Total 70 KLOC • Each field checked separately with resource limit of 20 minutes and 800MB • Two threads: each calls nondeterministically chosen dispatch routine

  28. Total: 30 races

  29. DevicePnpState Field in Toaster/toastmon ToastMon_DispatchPnp( DEVICE_OBJECT *obj, IRP *irp) { … IoAcquireRemoveLock(); … case IRP_MN_QUERY_STOP_DEVICE: // Race: write access deviceExt->DevicePnPState = StopPending; … break; … IoReleaseRemoveLock(); … } ToastMon_DispatchPower( DEVICE_OBJECT *obj, IRP *irp) { … // Race: read access if (deviceExt->DevicePnpState == Deleted) { … } … }

  30. Acknowledgments • Tom Ball • Byron Cook • John Henry • Doron Holan • Vladimir Levin • Jakob Lichtenberg • Adrian Oney • Sriram Rajamani • Peter Wieland • …

  31. Keep It Simple and Sequential • Context-bounded analysis by leveraging existing sequential checkers • Validates the hypothesis that many concurrency errors require few context switches to show up

  32. However… • Hard limit on number of explored contexts • e.g., two context switches for concurrent program with two threads • Case study: Concurrent transaction management code written in C# (Naik-Rehof 04) • Analyzed by the Zing model checker after automatically translating to the Zing input language • Found three bugs each requiring between three and four context switches

  33. Given a concurrent boolean program P, does P go wrong by failing an assertion? Undecidable Is a tuning knob possible? Given a concurrent boolean program P and a positive integer c, does P go wrong by failing an assertion via an execution with at most c contexts? Decidable Given a concurrent boolean program P with unbounded fork-join parallelism and a positive integer c, does P go wrong by failing an assertion via an execution with at most c contexts? Decidable

  34. Context switch Context switch           Context Context Context • Problem: • Unbounded computation possible within each context! • Unbounded execution depth and reachable state space • Different from bounded-depth model checking

  35. Transition relation: (g, s)  (g’, s’) Sequential pushdown system Global store g, valuation to global variables Local store l, valuation to local variables Stack s, sequence of local stores State (g, s)

  36. Reachability problem for sequential pushdown system Given (g, s), is there s’ such that (g, s) * (error,s’)?

  37. Aggregate state Set of stacks ss Aggregate state (g, ss) = { (g,s) | s  ss } Reach(g, ss) = { (g’, s’) | exists s  ss such that (g, s) * (g’, s’) } Reach(g, ss, g’) = {s’ | (g’, s’)  Reach(g, ss)}

  38. Theorem (Buchi, Schwoon00) • If ss is regular, then Reach(g, ss, g’) is regular. • If ss is given as a finite automaton A, then a finite automaton A’ for Reach(g, ss, g’) can be constructed from A in polynomial time.

  39. Algorithm Problem: Given (g, s), is there s’ such that (g, s) * (error,s’)? Solution: Compute automaton for Reach(g, {s}, error) and report error if it is nonempty.

  40. Transition relation: (g, s2)  (g’, s’2) in thread 2 (g, s1)  (g’, s’1) in thread 1 (g, s1, s2) 2 (g, s1, s’2) (g, s1, s2) 1 (g, s’1, s2) Concurrent pushdown system Global store g, valuation to global variables Local store l, valuation to local variables Stack s, sequence of local stores State (g, s1, s2)

  41. Reachability problem for concurrent pushdown system Given (g, s1, s2), are there s’1 and s’2 such that (g, s1, s2) reaches (error, s’1, s’2) via an execution with at most c contexts?

  42. ss’1 = Reach1(g, ss1, g’) (g, ss1, ss2) 1 (g’, ss’1, ss2) ss’2 = Reach2(g, ss2, g’) (g, ss1, ss2) 2 (g’, ss1, ss’2) Aggregate transition relation

  43. (g, {s1}, {s2})  1 2    1 2 1 2  Depth c  Algorithm: 2 threads, c contexts Compute the set of reachable aggregate states. Report an error if (g, ss1, ss2) is reachable and g = error, ss1 is nonempty, and ss2 is nonempty.

  44. Depth c Complexity: 2 threads, c contexts (g, {s1}, {s2})  1 2    1 2 1 2   Depth of tree = context bound c Branching factor bounded by G  2 (G = # of global stores) Number of edges bounded by (G  2) (c+1) Each edge computable in polynomial time

  45. Unbounded fork-join parallelism • Fork operation: x = fork • Join operation: join(x) • Copy thread identifier from one variable to another

  46. Algorithm: unbounded fork-join parallelism, c contexts • At most c threads may perform a transition • Reduce to previously solved problem with c threads and c contexts • Nondeterministically pick c forked threads for execution

  47. x = fork translates to join(x) translates to if ($) { assume(count < c); count = count + 1; x = count; start[count] = true; } else { x = c + 1; } assume(x  c); assume(end[x]); start : {1, …, c}  boolean, initialized to  i. (i == 1) end : {1, …, c}  boolean, initialized to  i. false • c statically created threads • thread i starts execution when start[i] is true • thread i sets end[i] to true on termination count : {1, …, c}, initialized to 1

  48. Context-bounded analysis of concurrent software • Many subtle concurrency errors are manifested in executions with few context switches • Experience with KISS on Windows drivers • Experience with Zing on transaction manager • Algorithms for context-bounded analysis are more efficient than those for unbounded analysis • Reducibility to sequential checking with KISS • Decidability of assertion checking for concurrent boolean programs

More Related