Variance Analyses from Invariance Analyses Josh Berdine Microsoft Research, Cambridge Joint work with Aziem Chawdhary, Byron Cook, Dino.

Slides:



Advertisements
Similar presentations
1 Verification by Model Checking. 2 Part 1 : Motivation.
Advertisements

Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Auto-Generation of Test Cases for Infinite States Reactive Systems Based on Symbolic Execution and Formula Rewriting Donghuo Chen School of Computer Science.
Type-based termination analysis with disjunctive invariants Dimitrios Vytiniotis, MSR Cambridge with Byron Cook (MSR Cambridge) and Ranjit Jhala (UCSD)
An Abstract Interpretation Framework for Refactoring P. Cousot, NYU, ENS, CNRS, INRIA R. Cousot, ENS, CNRS, INRIA F. Logozzo, M. Barnett, Microsoft Research.
Functional Verification III Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture Notes 23.
Shape Analysis by Graph Decomposition R. Manevich M. Sagiv Tel Aviv University G. Ramalingam MSR India J. Berdine B. Cook MSR Cambridge.
Budapest University of Technology and EconomicsDagstuhl 2004 Department of Measurement and Information Systems 1 Towards Automated Formal Verification.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13.
1 Mechanical Verification of Timed Automata Myla Archer and Constance Heitmeyer Presented by Rasa Bonyadlou 24 October 2002.
A survey of techniques for precise program slicing Komondoor V. Raghavan Indian Institute of Science, Bangalore.
Automatic Predicate Abstraction of C-Programs T. Ball, R. Majumdar T. Millstein, S. Rajamani.
August Moscow meeting1August Moscow meeting1August Moscow meeting11 Deductive tools in insertion modeling verification A.Letichevsky.
Rahul Sharma Işil Dillig, Thomas Dillig, and Alex Aiken Stanford University Simplifying Loop Invariant Generation Using Splitter Predicates.
Liveness Counter Abstraction Liveness with Counter Abstraction A mir P nueli, J essie X u and L enore Z uck.
Termination Proofs for Systems Code Andrey Rybalchenko, EPFL/MPI joint work with Byron Cook, MSR and Andreas Podelski, MPI PLDI’2006, Ottawa.
What is an Algorithm? (And how do we analyze one?)
Using Statically Computed Invariants Inside the Predicate Abstraction and Refinement Loop Himanshu Jain Franjo Ivančić Aarti Gupta Ilya Shlyakhter Chao.
Software Engineering: Where are we? And where do we go from here? V Software Engineering Lecture 23 Clark Barrett New York University 4/17/2006.
1 Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications.
Abstractions. Outline Informal intuition Why do we need abstraction? What is an abstraction and what is not an abstraction A framework for abstractions.
Synergy: A New Algorithm for Property Checking
1 Predicate Abstraction of ANSI-C Programs using SAT Edmund Clarke Daniel Kroening Natalia Sharygina Karen Yorav (modified by Zaher Andraus for presentation.
1 Program Analysis Mooly Sagiv Tel Aviv University Textbook: Principles of Program Analysis.
Program Verification using Templates over Predicate Abstraction Saurabh Srivastava University of Maryland, College Park Sumit Gulwani Microsoft Research,
Operational Semantics Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Describing Syntax and Semantics
Invisible Invariants: Underapproximating to Overapproximate Ken McMillan Cadence Research Labs TexPoint fonts used in EMF: A A A A A.
Program Analysis Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Formal Verification of SpecC Programs using Predicate Abstraction Himanshu Jain Daniel Kroening Edmund Clarke Carnegie Mellon University.
Propositional Calculus Math Foundations of Computer Science.
Proving termination conditions Name Country, City, University Omer Subasi Turkey, Istanbul, Koc University Anton Dergunov
Verification and Validation Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Systems Architecture I1 Propositional Calculus Objective: To provide students with the concepts and techniques from propositional calculus so that they.
Software Engineering Prof. Dr. Bertrand Meyer March 2007 – June 2007 Chair of Software Engineering Static program checking and verification Slides: Based.
Program Analysis with Dynamic Change of Precision Dirk Beyer Tom Henzinger Grégory Théoduloz Presented by: Pashootan Vaezipoor Directed Reading ASE 2008.
Type Systems CS Definitions Program analysis Discovering facts about programs. Dynamic analysis Program analysis by using program executions.
ISBN Chapter 3 Describing Semantics -Attribute Grammars -Dynamic Semantics.
Introduction to Problem Solving. Steps in Programming A Very Simplified Picture –Problem Definition & Analysis – High Level Strategy for a solution –Arriving.
Program analysis with dynamic change of precision. Philippe Giabbanelli CMPT 894 – Spring 2008.
Propositional Calculus CS 270: Mathematical Foundations of Computer Science Jeremy Johnson.
Reasoning about programs March CSE 403, Winter 2011, Brun.
Convergence of Model Checking & Program Analysis Philippe Giabbanelli CMPT 894 – Spring 2008.
1 Predicate Abstraction and Refinement for Verifying Hardware Designs Himanshu Jain Joint work with Daniel Kroening, Natasha Sharygina, Edmund M. Clarke.
Proving Non-Termination Gupta, Henzinger, Majumdar, Rybalchenko, Ru-Gang Xu presentation by erkan.
More on Correctness. Prime Factorization Problem: Write a program that computes all the prime factors of a given number Solution (Idea): Factors are less.
13 Aug 2013 Program Verification. Proofs about Programs Why make you study logic? Why make you do proofs? Because we want to prove properties of programs.
1 Reasoning with Infinite stable models Piero A. Bonatti presented by Axel Polleres (IJCAI 2001,
1 MSR/Cambridge Formal Verification Overview Byron Cook Microsoft Research, Cambridge.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
Introduction to Software Analysis CS Why Take This Course? Learn methods to improve software quality – reliability, security, performance, etc.
Operational Semantics Mooly Sagiv Tel Aviv University Textbook: Semantics with Applications Chapter.
1 Proving program termination Lecture 5 · February 4 th, 2008 TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: A.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Adaptive Shape Analysis Thomas Wies joint work with Josh Berdine Cristiano Calcagno TexPoint fonts used in EMF. Read the TexPoint manual before you delete.
Quantified Data Automata on Skinny Trees: an Abstract Domain for Lists Pranav Garg 1, P. Madhusudan 1 and Gennaro Parlato 2 1 University of Illinois at.
/ PSWLAB Thread Modular Model Checking by Cormac Flanagan and Shaz Qadeer (published in Spin’03) Hong,Shin Thread Modular Model.
1 Numeric Abstract Domains Mooly Sagiv Tel Aviv University Adapted from Antoine Mine.
Operational Semantics Mooly Sagiv Tel Aviv University Sunday Scrieber 8 Monday Schrieber.
Operational Semantics Mooly Sagiv Reference: Semantics with Applications Chapter 2 H. Nielson and F. Nielson
Spring 2017 Program Analysis and Verification
Presentation Title 2/4/2018 Software Verification using Predicate Abstraction and Iterative Refinement: Part Bug Catching: Automated Program Verification.
Tutorial: Proving termination and liveness
runtime verification Brief Overview Grigore Rosu
Lecture 5 Floyd-Hoare Style Verification
Over-Approximating Boolean Programs with Unbounded Thread Creation
Abstraction, Verification & Refinement
Predicate Abstraction
Presentation transcript:

Variance Analyses from Invariance Analyses Josh Berdine Microsoft Research, Cambridge Joint work with Aziem Chawdhary, Byron Cook, Dino Distefano & Peter O’Hearn SAVCBS’06: 10 Nov 2006

State of the verification toolbox Safety properties & reachability:  For proving that software doesn’t “crash”  Many verification tools & techniques at hand  Software model checkers, e.g. SLAM, Blast, SATAbs,…  Abstract domains: e.g. Interval, Octagon, Polyhedra,…  Other static analyzers: e.g. various control-flow, shape,… analyses  Not insignificant degree of coverage and maturity Liveness & termination:  For proving that software does “react”  Fewer verification tools  Often not as general, each strongly tailored to a form of programs  Sometimes “inconvenient” restrictions: e.g. no nested loops, purely functional Here: constructing termination provers from safety analyzers

Termination provers for free! Take an invariance analysis as a parameter  Computes an invariance assertion for each program location  An invariance assertion for l holds of all reachable states at l Construct its induced variance analysis  Computes a variance assertion for each program location  A variance assertion for l holds between any reachable state at l and any previous state at l Yields a termination prover  We give a local termination predicate LT such that  Program terminates if LT holds of each program location’s variance assertion Need two additional operations on abstract representation  Seed & WellFounded  Not difficult to define in practice

The plan Introduction Overview induced variance analysis algorithm Local termination predicates Play-by-play for an example Requirements on instantiations Instantiation for numerical abstract domains Instantiation for shape analysis Conclusion

Parameterized variance analysis algorithm

Underlying invariance analysis Single-step version of invariance analysis Additional operation to plant initial representation of progress Additional operation to check progress is being made

Parameterized variance analysis algorithm Input program Set of cutpoints Initial abstract state Output array indicating which local termination predicates were proved

Local termination predicates Line 83 is not visited infinitely often  Line 85 is not visited infinitely often  Program terminates 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (x>10); 87 } else { 88 y = y - 1; 89 } 90 }

Local termination predicates Line 83 is visited infinitely often Program diverges but… LT (83): Line 83 is visited infinitely often only when the program’s execution exits the loop contained in lines 82 to 90 infinitely often 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (x>10); 87 } else { 88 y = y - 1; 89 } 90 } 91 }

Local termination predicates Line 85 is visited infinitely often Program diverges but still… LT (83): Line 83 is visited infinitely often only when the program’s execution exits the loop contained in lines 82 to 90 infinitely often 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 } 91 }

Local termination predicates LT (82): Line 82 is visited infinitely often only when the program’s execution exits the loop contained in lines 81 to 91 infinitely often  LT (83): Line 83 is visited infinitely often only when the program’s execution exits the loop contained in lines 82 to 90 infinitely often  LT (85): Line 85 is visited infinitely often only when the program’s execution exits the loop contained in lines 84 to 86 infinitely often  81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 } 91 }

Illustrative example Consider an invariance analysis based on the Octagon domain Can express conjunctions of inequalities of the form:  x   y  c Represent the program counter with equalities: pc  c 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 } 91 }

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 } 91 }

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 } 91 } pc  81  x  a  1  y  b  1

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 } 91 } pc  81  x  a  1  y  b  1 pc  83  x  a  1  y  b  1 {s | s(pc)  83  s(x)  s(a)  1  s(y)  s(b)  1} 8383

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } pc  83  x  a  1  y  b  1

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } pc  83  x  a  1  y  b  1

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } pc  83  x  a  1  y  b  1  pc s  pc  x s  x  y s  y  a s  a  b s  b

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } pc  83  x  a  1  y  b  1  pc s  pc  x s  x  y s  y  a s  a  b s  b {(s,t) | s(pc)  t(pc)  83  s(x)  t(x)  s(y)  t(y)  s(a)  t(a)  s(b)  t(b)  t(x)  t(a)  1  t(y)  t(b)  1 }

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } pc  83  x  a  1  y  b  1  pc s  pc  x s  x  y s  y  a s  a  b s  b pc s  83  pc  84  x  a  1  y  b  1  x s  x  y s  y  a s  a  b s  b

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } pc s  83  pc  84  x  a  1  y  b  1  x s  x  y s  y  a s  a  b s  b

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } pc s  83  pc  84  x  a  1  y  b  1  x s  x  y s  y  a s  a  b s  b  { pc s  83  pc  83  x  a  1  y  b  1  x s  x  1  y s  y  a s  a  b s  b, pc s  83  pc  83  x  a  1  y  b  1  x s  x  y s  y  1  a s  a  b s  b, pc s  83  pc  83  x  a  1  y  b  1  x s  x  1  y s  y  1  a s  a  b s  b }

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } “A superset of the possible transitions from states at 83 to states also at line 83 reachable in 1 or more steps of the program’s execution”  { pc s  83  pc  83  x  a  1  y  b  1  x s  x  1  y s  y  a s  a  b s  b, pc s  83  pc  83  x  a  1  y  b  1  x s  x  y s  y  1  a s  a  b s  b, pc s  83  pc  83  x  a  1  y  b  1  x s  x  1  y s  y  1  a s  a  b s  b }

Illustrative example 81 while (nondet()) { 82 while (x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (nondet()); 87 } else { 88 y = y - 1; 89 } 90 }; assume(false); 91 } “A superset of the possible transitions from states at 83 to states also at line 83 reachable in 1 or more steps of the program’s execution”  { pc s  83  pc  83  x  a  1  y  b  1  x s  x  1  y s  y  a s  a  b s  b, pc s  83  pc  83  x  a  1  y  b  1  x s  x  y s  y  1  a s  a  b s  b, pc s  83  pc  83  x  a  1  y  b  1  x s  x  1  y s  y  1  a s  a  b s  b } If LTPreds[ l ]=true, then VAs is a finite disjunction of well-founded relations that over-approximates R . Then isolated program terminates by Podelski & Rybalchenko [LICS04]

Remarks Speed: the induced termination provers are fast:  0.07s for Octagon-based prover on this example, vs 8.3s for Terminator Automatic:  Termination arguments are automatically found and checked Disjunctive termination arguments:  Disjunctive decomposition under the control of the invariance analysis  Allows using invariance analyzers based on simpler domains  Traditional ranking function for blue loop is: f(s)=s(x)+s(y) and the program’s transition relation (whose coverage must be proven) is: {(s,t) | s(x)+s(y)  t(x)+t(y)-1  t(x)+t(y)  0} Note the 4-variable inequality. 81 while (nondet()) { 82 while ( x>a && y>b) { 83 if (nondet()) { 84 do { 85 x = x - 1; 86 } while (x>10); 87 } else { 88 y = y - 1; 89 } 90 } 91 }

Remarks Dynamic seeding: improved precision  Seeding may be done after some disjunctive decomposition  Auxiliary information kept by the invariance analysis can be seeded No rank function synthesis:  Well-foundedness checks only need boolean result, a full rank-function synthesizer is unnecessary Some usable information is computed whether or not overall termination is established  The well-founded disjuncts that are found provide refinement-based tools like Terminator with a much better starting point Robust wrt nested loops, etc. by use of standard analysis methods  Fits in comfortably with cutpoint decomposition techniques Over-approximation of program’s transition relation holds by construction, in Terminator checking this is the performance bottleneck

Instantiating the algorithm: Seed & WellFounded Seed encodes a binary relation on states into a predicate on states Ghost state is the additional information in a state used to represent a relation (the seed variables) Seeding must introduce ghost state, approximating copying the state, in a fashion such that:  The concrete semantics is independent of any ghost state  The abstract semantics (InvarianceAnalysis) must ignore the ghost state and not introduce spurious facts about it WellFounded must soundly check well-foundedness of the relations seeded states represent and of course: Step and InvarianceAnalysis must be sound over-approximations of the program’s concrete semantics

Induced termination provers for numerical domains Take a conventional invariance analysis based on the Ocatgon or Polyhedra abstract domains Fit a post-analysis phase that recovers some disjunctive information Define:   is a bijection between program and seed variables  WfCheck can be e.g. RankFinder or PolyRank That’s it!

Induced termination provers for numerical domains

Induced termination prover for shape analysis Take Sonar, the separation-logic based shape analysis that tracks sizes of abstracted portions of the heap No post-analysis, the Sonar analysis is already fully disjunctive Define:   is a bijection between list length and seeded length variables  WfCheck can be e.g. RankFinder or PolyRank Surprisingly similar to instantiation for numerical domains, despite the underlying analyses being radically different

Induced termination prover for shape analysis Results on examples Terminator flags as buggy 1 false bug reported: loop 8, essentially reversing a pan-handle list

Conclusions Variance analyses can be constructed from invariance analyses Resulting termination provers are fast: at least competitive with the state- of-the art Even (quickly) failed proofs can help other provers Usual analysis techniques for varying the precision versus performance balance can now be done for termination Questions? details in a paper to appear in POPL