2006-11-30Newton: A tool for generating abstract explanations of infeasibility1 The Problem P (C Program) BP (Boolean Program of P) CFG(P) CFG(BP)

Slides:



Advertisements
Similar presentations
A SAT characterization of boolean-program correctness K. Rustan M. Leino Microsoft Research, Redmond, WA 14 Nov 2002 IFIP WG 2.4 meeting, Schloβ Dagstuhl,
Advertisements

Advanced programming tools at Microsoft
The Static Driver Verifier Research Platform
The SLAM Project: Debugging System Software via Static Analysis
Abstraction in Model Checking Nishant Sinha. Model Checking Given a: –Finite transition system M –A temporal property p The model checking problem: –Does.
Verification of Evolving Software Natasha Sharygina Joint work with Sagar Chaki and Nishant Sinha Carnegie Mellon University.
Bebop: A Symbolic Model Checker for Boolean Programs Thomas Ball Sriram K. Rajamani
1 Lecture 08(c) – Predicate Abstraction and SLAM Eran Yahav.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
1 Thorough Static Analysis of Device Drivers Byron Cook – Microsoft Research Joint work with: Tom Ball, Vladimir Levin, Jakob Lichtenberg,
A survey of techniques for precise program slicing Komondoor V. Raghavan Indian Institute of Science, Bangalore.
Chair of Software Engineering Software Verification Stephan van Staden Lecture 10: Model Checking.
Thomas Ball, Rupak Majumdar, Todd Millstein, Sriram K. Rajamani Presented by Yifan Li November 22nd In PLDI 01: Programming Language.
BLAST-A Model Checker for C Developed by Thomas A. Henzinger (EPFL) Rupak Majumdar (UC Los Angeles) Ranjit Jhala (UC San Diego) Dirk Beyer (Simon Fraser.
The Software Model Checker BLAST by Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala and Rupak Majumdar Presented by Yunho Kim Provable Software Lab, KAIST.
Software Verification via Refinement Checking Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar Shaz Qadeer.
Using Statically Computed Invariants Inside the Predicate Abstraction and Refinement Loop Himanshu Jain Franjo Ivančić Aarti Gupta Ilya Shlyakhter Chao.
Software Verification with Blast Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar, George Necula, Grégoire Sutre, Wes Weimer UC Berkeley.
State-Event Software Verification for Branching-Time Specifications Sagar Chaki, Ed Clarke, Joel Ouaknine, Orna Grumberg Natasha Sharygina, Tayssir Touili,
Lazy Abstraction Thomas A. Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre UC Berkeley.
Levels of Reasoning propositional p 1 = q 1  p 2 = q 2 ...  p n = q n  p = q schematic (1 st order uninterpreted) x := s ; x := t = x := t[x/s] 1 st.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar [UC Berkeley] Shaz Qadeer [Microsoft Research]
Synergy: A New Algorithm for Property Checking
Secrets of Software Model Checking Thomas Ball Sriram K. Rajamani Software Productivity Tools Microsoft Research
SLAM Over the Summer Wes Weimer (Tom Ball, Sriram Rajamani, Manuvir Das)
Counter Example Guided Refinement CEGAR Mooly Sagiv.
CS 267: Automated Verification Lectures 14: Predicate Abstraction, Counter- Example Guided Abstraction Refinement, Abstract Interpretation Instructor:
Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball and Sriram K. Rajamani Software Productivity Tools, Microsoft Research Presented.
Predicate Abstraction for Software and Hardware Verification Himanshu Jain Model checking seminar April 22, 2005.
Lazy Abstraction Tom Henzinger Ranjit Jhala Rupak Majumdar Grégoire Sutre.
Automatic Predicate Abstraction of C Programs Thomas BallMicrosoft Rupak MajumdarUC Berkeley Todd MillsteinU Washington Sriram K. RajamaniMicrosoft
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
Symbolic Path Simulation in Path-Sensitive Dataflow Analysis Hari Hampapuram Jason Yue Yang Manuvir Das Center for Software Excellence (CSE) Microsoft.
Automated Tools for Software Reliability Suhabe Bugrara Stanford University.
Software Model Checking with SLAM Thomas Ball Testing, Verification and Measurement Sriram K. Rajamani Software Productivity Tools Microsoft Research
Verifying Concurrent Message- Passing C Programs with Recursive Calls Sagar Chaki, Edmund Clarke, Nicholas Kidd, Thomas Reps, and Tayssir Touili.
By: Pashootan Vaezipoor Path Invariant Simon Fraser University – Spring 09.
Lecture #11 Software Model Checking: automating the search for abstractions Thomas Ball Testing, Verification and Measurement Microsoft Research.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 3: Modular Verification with Magic, Predicate Abstraction.
Rule Checking SLAM Checking Temporal Properties of Software with Boolean Programs Thomas Ball, Sriram K. Rajamani Microsoft Research Presented by Okan.
Aditya V. Nori, Sriram K. Rajamani Microsoft Research India.
SLAM :Software Model Checking From Theory To Practice Sriram K. Rajamani Software Productivity Tools Microsoft Research.
Parameterized Verification of Thread-safe Libraries Thomas Ball Sagar Chaki Sriram K. Rajamani.
SAT & SMT. Software Verification & Testing SAT & SMT Test case generation Predicate Abstraction Verifying Compilers.
Thomas Ball Sriram K. Rajamani
Use of Models in Analysis and Design Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India.
Predicate Abstraction of ANSI-C Programs Using SAT By Edmund Clarke, Daniel Kroening, Natalia Sharygina, Karen Yorav Presented by Yunho Kim Provable Software.
Automatically Validating Temporal Safety Properties of Interfaces Thomas Ball, Sriram K. MSR Presented by Xin Li.
Localization and Register Sharing for Predicate Abstraction Himanshu Jain Franjo Ivančić Aarti Gupta Malay Ganai.
Model Checking C Programs Zijiang (James) Yang Department of Computer Science Western Michigan University In collaboration with NEC Laboratories America.
SLAM internals Sriram K. Rajamani Rigorous Software Engineering Microsoft Research, India.
The Yogi Project Software property checking via static analysis and testing Aditya V. Nori, Sriram K. Rajamani, Sai Deep Tetali, Aditya V. Thakur Microsoft.
Synergy: A New Algorithm for Property Checking Bhargav S. Gulavani (IIT Bombay)‏ Yamini Kannan (Microsoft Research India)‏ Thomas A. Henzinger (EPFL)‏
1 Automatically Validating Temporal Safety Properties of Interfaces - Overview of SLAM Parts of the slides are from
Counter Example Guided Refinement CEGAR Mooly Sagiv.
Boolean Programs: A Model and Process For Software Analysis By Thomas Ball and Sriram K. Rajamani Microsoft technical paper MSR-TR Presented by.
Finding bugs with a constraint solver daniel jackson. mandana vaziri mit laboratory for computer science issta 2000.
#1 Having a BLAST with SLAM. #2 Software Model Checking via Counter-Example Guided Abstraction Refinement Topic: Software Model Checking via Counter-Example.
Verifying Regular Behavior of C modules Sagar Chaki, Edmund Clarke, Alex Groce, CMU Somesh Jha, Wisconsin.
The software model checker BLAST Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar Presented by Yunho Kim TexPoint fonts used in EMF. Read.
Presentation Title 2/4/2018 Software Verification using Predicate Abstraction and Iterative Refinement: Part Bug Catching: Automated Program Verification.
Having a BLAST with SLAM
Software Model Checking with SLAM
Over-Approximating Boolean Programs with Unbounded Thread Creation
Abstractions from Proofs
Abstraction, Verification & Refinement
Synchronization Verification in System-Level Design with ILP Solvers
Predicate Abstraction
Course: CS60030 Formal Systems
Presentation transcript:

Newton: A tool for generating abstract explanations of infeasibility1 The Problem P (C Program) BP (Boolean Program of P) CFG(P) CFG(BP)

Newton: A tool for generating abstract explanations of infeasibility2 The Problem P (C Program) BP (Boolean Program of P) CFG(P) CFG(BP) need refinement Where do predicates come from?

Newton: A tool for generating abstract explanations of infeasibility3 Generating Abstract Explanation of Spurious Counterexamples in C Programs Thomas Ball, Sriram K. Rajamani Technical Report Yunkyung Ahn some figures and slides are from

Newton: A tool for generating abstract explanations of infeasibility4 Goal P (path program) Found Bug good explanation (infeasible) Newton

Newton: A tool for generating abstract explanations of infeasibility5 The SLAM Process boolean pgm path predicates pgm P SLIC rule slic pgm P’ c2bp bebop newton

Newton: A tool for generating abstract explanations of infeasibility6 Path Program (Example) do { KeAcquireSpinLock(); A: KeAcquireSpinLock_return(); nPacketsOld = nPackets; request = devExt->WLHV; if(request){ request = request->Next; KeReleaseSpinLock(); B: KeReleaseSpinLock_return(); nPackets++; } C: } while (nPackets != nPacketsOld); KeReleaseSpinLock(); D: KeReleaseSpinLock_return(); enum { Unlocked=0, Locked=1 } state = Unlocked; void slic_abort() { SLIC_ERROR: ; } void KeAcquireSpinLock_return() { if (state == Locked) slic_abort(); else E: E: state = Locked; } void KeReleaseSpinLock_return { if (state == Unlocked) slic_abort(); else F: F: state = Unlocked; }

Newton: A tool for generating abstract explanations of infeasibility7 Path Program (Example) do { skip; A: KeAcquireSpinLock_return(); skip; if(*){ skip; B: KeReleaseSpinLock_return(); skip; } C: } while (*); skip; D: KeReleaseSpinLock_return(); decl {state==Locked}, {state==Unlocked}; void slic_abort() { SLIC_ERROR: skip; } void KeAcquireSpinLock_return() { if ({state==Locked}) slic_abort(); else E: E: {state==Locked},{state==Unlocked} := T,F; } void KeReleaseSpinLock_return() { if ({state == Unlocked}) slic_abort(); else F: F: {state==Locked},{state==Unlocked} := F,T; }

Newton: A tool for generating abstract explanations of infeasibility8 Path Program (Example) do { KeAcquireSpinLock(); A: KeAcquireSpinLock_return(); nPacketsOld = nPackets; request = devExt->WLHV; if(request){ request = request->Next; KeReleaseSpinLock(); B: KeReleaseSpinLock_return(); nPackets++; } C: } while (nPackets != nPacketsOld); KeReleaseSpinLock(); D: KeReleaseSpinLock_return(); enum { Unlocked=0, Locked=1 } state = Unlocked; void slic_abort() { SLIC_ERROR: ; } void KeAcquireSpinLock_return() { if (state == Locked) slic_abort(); else E: E: state = Locked; } void KeReleaseSpinLock_return { if (state == Unlocked) slic_abort(); else F: F: state = Unlocked; } nPackets = nPacketsOld; request = devExt->WLHeadVa; nPackets = nPacketsOld; request = devExt->WLHeadVa; assume(!request); assume(nPackets != nPacketsOld);

Newton: A tool for generating abstract explanations of infeasibility9 Example p1 is infeasible condition: e1 = (b > 0)  (c = 2b)  (a = b - 1) e1 implies (a  c) E1 = {(b > 0), (c = 2b), (a = b), (a = b-1)} an explanation of p1’ infeasibility 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c); p1 (path program ) (b > 0)(b > 0), (c=2b)(b > 0), (c=2b), (a=b)(b > 0), (c=2b), (a=b-1)

Newton: A tool for generating abstract explanations of infeasibility10 Example Is there a better explanation than E1? p2 is infeasible condition: e2 = (b > 0)  (c = 2b)  (a < b) e2 implies (a  c) e2 is more abstract (weaker) than e1 e1 = (b > 0)  (c = 2b)  (a = b - 1) e2 = (b > 0)  (c = 2b)  (a < b) e1  e2 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c); p1 (path program ) 1 assume(b>0); 2 c := 2  b; 5 assume(a<b); 6 assume(a=c); p2 (path program )

Newton: A tool for generating abstract explanations of infeasibility11 Example E1 = {(b > 0), (c = 2b), (a = b), (a = b-1)} E2 = {(b > 0), (c = 2b), (a < b)} E1, E2: explanations of p1’s infeasibility E2 is a better explanation than E1 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c); p1 (path program ) 1 assume(b>0); 2 c := 2  b; 5 assume(a<b); 6 assume(a=c); p2 (path program )

Newton: A tool for generating abstract explanations of infeasibility12 Example - Annotation introduce a fresh symbolic constant in p1, there is no variable is used without first being defined 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c); p1 1 b :=  b 2 assume(b>0); 3 c := 2  b; 4 a := b; 5 a := a – 1; 6 assume(a<b); 7 assume(a=c); p1’

Newton: A tool for generating abstract explanations of infeasibility13 Semantics of Path SP (strongest post condition) in terms of p SP maps a context to a new context : a context ,store represents the current valuation ,condition represents the constraints ,history represents the past valuations

Newton: A tool for generating abstract explanations of infeasibility14 Strongest Postcondition Example (Path simulation of p1) p1’  : store  : conditions  : history b :=  b ; assume(b>0); c := 2  b; a := b; a := a – 1; assume(a<b); assume(a=c); p1’  : store  : conditions  : history b :=  b ;(b,  b ) assume(b>0); c := 2  b; a := b; a := a – 1; assume(a<b); assume(a=c); p1’  : store  : conditions  : history b :=  b ;(b,  b ) assume(b>0);(b,  b )  b > 0 c := 2  b; a := b; a := a – 1; assume(a<b); assume(a=c); p1’  : store  : conditions  : history b :=  b ;(b,  b ) assume(b>0);(b,  b )  b > 0 c := 2  b;(b,  b ), (c, 2  b )  b > 0 a := b;(a,  b ), (b,  b ), (c, 2  b )  b > 0 a := a – 1;(a,  b -1), (b,  b ), (c, 2  b )  b > 0(a,  b ) assume(a<b);(a,  b -1), (b,  b ), (c, 2  b )  b > 0,  b -1 <  b (a,  b ) assume(a=c);(a,  b -1), (b,  b ), (c, 2  b )  b > 0,  b -1 <  b, 2  b =  b - 1 (a,  b ) p1’  : store  : conditions  : history b :=  b ;(b,  b ) assume(b>0);(b,  b )  b > 0 c := 2  b;(b,  b ), (c, 2  b )  b > 0 a := b;(a,  b ), (b,  b ), (c, 2  b )  b > 0 a := a – 1;(a,  b -1), (b,  b ), (c, 2  b )  b > 0(a,  b ) assume(a<b);(a,  b -1), (b,  b ), (c, 2  b )  b > 0,  b -1 <  b (a,  b ) assume(a=c);(a,  b -1), (b,  b ), (c, 2  b )  b > 0,  b -1 <  b, 2  b =  b - 1 (a,  b )

Newton: A tool for generating abstract explanations of infeasibility15 Example How to generate a good explanation p1,p2: infeasible paths p2 is a ICPP (Infeasible Consistent Path Projection) of p1 we can use the ICPP to generate an abstract explanation 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c); 1 assume(b>0); 2 c := 2  b; 5 assume(a<b); 6 assume(a=c); p1p2

Newton: A tool for generating abstract explanations of infeasibility16 Example p2 is a ICPP of p1 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b);, b :=  b ; 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; a :=  a ; 5 assume(a<b); 6 assume(a=b); p2 p1 1 assume(b>0); 2 c := 2  b; a :=  a ; 5 assume(a<b); 6 assume(a=b); b :=  b ; 1 assume(b>0); 2 c := 2  b; a :=  a ; 5 assume(a<b); 6 assume(a=b);

Newton: A tool for generating abstract explanations of infeasibility17 Newton implements SP to check if a path p is infeasible find an abstract explanation for the infeasibility of p based on constructing ICPPs, if p is infeasible Internal state of Newton has 3 components store (  ): map from variables to values condition(  ): predicates over symbols history(  ) : past valuations of the store Newton function in 3 phases: Phase1: check feasibility Phase2: minimize conditions Phase3: find a explanation

Newton: A tool for generating abstract explanations of infeasibility18 Example Store ConditionsHistory 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c);

Newton: A tool for generating abstract explanations of infeasibility19 Example Store ConditionsHistoryStore 1b bb () Conditions (  b > 0)(1) 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c);

Newton: A tool for generating abstract explanations of infeasibility20 Example Store ConditionsHistoryStore 1b bb () Conditions (  b > 0)(1) Store 1b bb () 2c2  b (1) 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c);

Newton: A tool for generating abstract explanations of infeasibility21 Example Store ConditionsHistoryStore 1b bb () Conditions (  b > 0)(1) Store 1b bb () 2c2  b (1) Store 1b bb () 2c2  b (1) 3a bb 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c);

Newton: A tool for generating abstract explanations of infeasibility22 Example Store ConditionsHistoryStore 1b bb () Conditions (  b > 0)(1) Store 1b bb () 2c2  b (1) Store 1b bb () 2c2  b (1) 3a bb Store 1b bb () 2c2  b (1) 4a  b -1(3) History 3a bb (1) 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c);

Newton: A tool for generating abstract explanations of infeasibility23 Example Store ConditionsHistoryStore 1b bb () Conditions (  b > 0)(1) Store 1b bb () 2c2  b (1) Store 1b bb () 2c2  b (1) 3a bb Store 1b bb () 2c2  b (1) 4a  b -1(3) History 3a bb (1) Store 1b bb () 2c2  b (1) 5a aa () Conditions (  b > 0)(1) (  a <  b )(1,5) 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c);

Newton: A tool for generating abstract explanations of infeasibility24 Example Store ConditionsHistoryStore 1b bb () Conditions (  b > 0)(1) Store 1b bb () 2c2  b (1) Store 1b bb () 2c2  b (1) 3a bb Store 1b bb () 2c2  b (1) 4a  b -1(3) History 3a bb (1) Store 1b bb () 2c2  b (1) 5a aa () Conditions (  b > 0)(1) (  a <  b )(1,5) Conditions (  b > 0)(1) (  a <  b )(1,5) (  a = 2  b )(2,5) a explanation of infeasibility {(  b > 0),(  a <  b ), (  a = 2  b )} {, } 1 assume(b>0); 2 c := 2  b; 3 a := b; 4 a := a – 1; 5 assume(a<b); 6 assume(a=c);

Newton: A tool for generating abstract explanations of infeasibility25 Experimental Results Newton generates a very small explanation. Every iteration of Newton took under a minute consumed less than 10MB of memory in a 996Mhz Pentium PC with 256MB RAM

Newton: A tool for generating abstract explanations of infeasibility26 Summary Symbolic path simulator Check conditions for inconsistency using theorem prover (Simplify) After detecting inconsistency: minimize inconsistent conditions traverse dependencies obtain predicates SLAM = The first CEGAR project CEGAR = Counter-Example Guided Abstraction Iterative Abstraction Refinement