Rigorous Software Development CSCI-GA 3033-011 Instructor: Thomas Wies Spring 2012 Lecture 13.

Slides:



Advertisements
Similar presentations
A practical and complete approach to predicate abstraction Ranjit Jhala UCSD Ken McMillan Cadence Berkeley Labs.
Advertisements

Exploiting SAT solvers in unbounded model checking K. L. McMillan Cadence Berkeley Labs.
Automated Theorem Proving Lecture 1. Program verification is undecidable! Given program P and specification S, does P satisfy S?
Modeling issues Book: chapters 4.12, 5.4, 8.4, 10.1.
Abstraction of Source Code (from Bandera lectures and talks)
Semantics Static semantics Dynamic semantics attribute grammars
Data-Flow Analysis II CS 671 March 13, CS 671 – Spring Data-Flow Analysis Gather conservative, approximate information about what a program.
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Partial Order Reduction: Main Idea
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
50.530: Software Engineering Sun Jun SUTD. Week 10: Invariant Generation.
Hoare’s Correctness Triplets Dijkstra’s Predicate Transformers
Model-based reasoning meets code verification Michael Butler 21 May 2014 WG 2.3 Meeting 55, Orlando.
Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 11.
Introducing BLAST Software Verification John Gallagher CS4117.
Partial correctness © Marcelo d’Amorim 2010.
Copyright © 2006 Addison-Wesley. All rights reserved.1-1 ICS 410: Programming Languages Chapter 3 : Describing Syntax and Semantics Axiomatic Semantics.
ISBN Chapter 3 Describing Syntax and Semantics.
Program Proving Notes Ellen L. Walker.
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.
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.
Abstractions. Outline Informal intuition Why do we need abstraction? What is an abstraction and what is not an abstraction A framework for abstractions.
Thread-modular Abstraction Refinement Tom Henzinger Ranjit Jhala Rupak Majumdar [UC Berkeley] Shaz Qadeer [Microsoft Research]
CS 267: Automated Verification Lectures 14: Predicate Abstraction, Counter- Example Guided Abstraction Refinement, Abstract Interpretation Instructor:
Temporal Logic and Model Checking. Reactive Systems We often classify systems into two types: Transformational: functions from inputs available at the.
Overview of program analysis Mooly Sagiv html://
ESE601: Hybrid Systems Introduction to verification Spring 2006.
Describing Syntax and Semantics
Data Flow Analysis Compiler Design Nov. 8, 2005.
1 Formal Engineering of Reliable Software LASER 2004 school Tutorial, Lecture1 Natasha Sharygina Carnegie Mellon University.
CS 267: Automated Verification Lecture 13: Bounded Model Checking Instructor: Tevfik Bultan.
Lazy Abstraction Lecture 3 : Partial Analysis Ranjit Jhala UC San Diego With: Tom Henzinger, Rupak Majumdar, Ken McMillan, Gregoire Sutre.
272: Software Engineering Fall 2012 Instructor: Tevfik Bultan Lecture 4: SMT-based Bounded Model Checking of Concurrent Software.
Thread-modular Abstraction Refinement Thomas A. Henzinger, et al. CAV 2003 Seonggun Kim KAIST CS750b.
By: Pashootan Vaezipoor Path Invariant Simon Fraser University – Spring 09.
Program Analysis with Dynamic Change of Precision Dirk Beyer Tom Henzinger Grégory Théoduloz Presented by: Pashootan Vaezipoor Directed Reading ASE 2008.
1 Automatic Refinement and Vacuity Detection for Symbolic Trajectory Evaluation Orna Grumberg Technion Haifa, Israel Joint work with Rachel Tzoref.
Defining Programs, Specifications, fault-tolerance, etc.
CS 363 Comparative Programming Languages Semantics.
Program Correctness. 2 Program Verification An object is a finite state machine: –Its attribute values are its state. –Its methods optionally: Transition.
1 Bisimulations as a Technique for State Space Reductions.
Lazy Abstraction Jinseong Jeon ARCS, KAIST CS750b, KAIST2/26 References Lazy Abstraction –Thomas A. Henzinger et al., POPL ’02 Software verification.
Lazy Annotation for Program Testing and Verification Speaker: Chen-Hsuan Adonis Lin Advisor: Jie-Hong Roland Jiang November 26,
Formal verification of skiplist algorithms Student: Trinh Cong Quy Supervisor: Bengt Jonsson Reviewer: Parosh Abdulla.
Symbolic Execution with Abstract Subsumption Checking Saswat Anand College of Computing, Georgia Institute of Technology Corina Păsăreanu QSS, NASA Ames.
Program Analysis and Verification Spring 2015 Program Analysis and Verification Lecture 12: Abstract Interpretation IV Roman Manevich Ben-Gurion University.
COP4020 Programming Languages Introduction to Axiomatic Semantics Prof. Robert van Engelen.
Learning Symbolic Interfaces of Software Components Zvonimir Rakamarić.
Predicate Abstraction. Abstract state space exploration Method: (1) start in the abstract initial state (2) use to compute reachable states (invariants)
SAT-Based Model Checking Without Unrolling Aaron R. Bradley.
Automated Debugging with Error Invariants TexPoint fonts used in EMF. Read the TexPoint manual before you delete this box.: AAA A A A AA A A Chanseok Oh.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
CS357 Lecture 13: Symbolic model checking without BDDs Alex Aiken David Dill 1.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
CSC3315 (Spring 2009)1 CSC 3315 Languages & Compilers Hamid Harroud School of Science and Engineering, Akhawayn University
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Chair of Software Engineering Software Verification Lecture 12: Software Model Checking Carlo A. Furia.
Abstraction and Abstract Interpretation. Abstraction (a simplified view) Abstraction is an effective tool in verification Given a transition system, we.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Counterexample-Guided Abstraction Refinement By Edmund Clarke, Orna Grumberg, Somesh Jha, Yuan Lu, and Helmut Veith Presented by Yunho Kim Provable Software.
The software model checker BLAST Dirk Beyer, Thomas A. Henzinger, Ranjit Jhala, Rupak Majumdar Presented by Yunho Kim TexPoint fonts used in EMF. Read.
Automatic Verification
Over-Approximating Boolean Programs with Unbounded Thread Creation
Axiomatic Verification II
Axiomatic Verification II
Predicate Abstraction
COP4020 Programming Languages
Presentation transcript:

Rigorous Software Development CSCI-GA Instructor: Thomas Wies Spring 2012 Lecture 13

Invariant Generation Tools such as ESC/Java enable automated program verification by – automatically generating verification conditions and – automatically checking validity of the generated VCs. The user still needs to provide the invariants. – This is often the hardest part. Can we generate invariants automatically?

Programs as Systems of Constraints 1: assume y ¸ z; 2: while x < y do x := x + 1; 3: assert x ¸ z `1`1 `1`1 `2`2 `2`2 `3`3 `3`3 ` err ` exit y ¸ z x ¸ z x ¸ y x < y Æ x’ = x + 1 x < z ½ 1 = move( ` 1, ` 2 ) Æ y ¸ z Æ skip(x,y,z) ½ 2 = move( ` 2, ` 2 ) Æ x < y Æ x’ = x + 1 Æ skip(y,z) ½ 3 = move( ` 2, ` 3 ) Æ x ¸ y Æ skip(x,y,z) ½ 4 = move( ` 3, ` err ) Æ x < z Æ skip(x,y,z) ½ 5 = move( ` 3, ` exit ) Æ x ¸ z Æ skip(x,y,z) move( ` 1, ` 2 ) = pc = ` 1 Æ pc’ = ` 2 skip(x 1,..., x n ) = x 1 ’ = x 1 Æ... Æ x n ’ = x n

Program P = (V, init, R, error) V : finite set of program variables init : initiation condition given by a formula over V R : a finite set of transition constraints – transition constraint ½ 2 R given by a formula over V and their primed versions V’ – we often think of R as disjunction of its elements R = ½ 1 Ç... Ç ½ n error : error condition given by a formula over V

P = (V, init, R, error) V = {pc, x, y, z} init = pc = ` 1 R = { ½ 1, ½ 2, ½ 3, ½ 4, ½ 5 } where ½ 1 = move( ` 1, ` 2 ) Æ y ¸ z Æ skip(x,y,z) ½ 2 = move( ` 2, ` 2 ) Æ x < y Æ x’ = x + 1 Æ skip(y,z) ½ 3 = move( ` 2, ` 3 ) Æ x ¸ y Æ skip(x,y,z) ½ 4 = move( ` 3, ` err ) Æ x < z Æ skip(x,y,z) ½ 5 = move( ` 3, ` exit ) Æ x ¸ z Æ skip(x,y,z) error = pc = ` err Programs as Systems of Constraints `1`1 `1`1 `2`2 `2`2 `3`3 `3`3 ` err ` exit y ¸ z x ¸ z x ¸ y x < y Æ x’ = x + 1 x < z

Programs as Transition Systems states Q are valuations of program variables V initial states Q init are the states satisfying the initiation condition init Q init = {q 2 Q | q ² init } transition relation ! is the relation defined by the transition constraints in R q 1 ! q 2 iff q 1, q 2 ’ ² R error states Q err are the states satisfying the error condition error Q err = {q 2 Q | q ² error }

Partial Correctness of Programs a state q is reachable in P if it occurs in some computation of P q 0 ! q 1 ! q 2 !... ! qwhere q 0 2 Q init denote by Q reach the set of all reachable states of P a program P is safe if no error state is reachable in P Q reach Å Q err = ; or, if Q reach is expressed as a formula reach over V ² reach Æ error ) false

state space Q error states Q err Partial Correctness of Programs reachable states Q reach initial states Q init

Example: Reachable States of a Program 1: assume y ¸ z; 2: while x < y do x := x + 1; 3: assert x ¸ z Reachable states reach = pc = ` 1 Ç pc = ` 2 Æ y ¸ z Ç pc = ` 3 Æ y ¸ z Æ x ¸ y Ç pc = ` exit Æ y ¸ z Æ x ¸ y `1`1 `1`1 `2`2 `2`2 `3`3 `3`3 ` err ` exit y ¸ z x ¸ z x ¸ y x < y Æ x’ = x + 1 x < z What is the connection with invariants? Can we compute reach?

Invariants of Programs an invariant Q I of a program P is a superset of its reachable states: Q reach µ Q I an invariant Q I is safe if it does not contain any error states: Q I Æ Q err = ; or if Q I is expressed as a formula I over V ² I Æ error ) false reach is the “smallest” invariant of P. In particular, if P is safe then so is reach.

state space Q error states Q err Partial Correctness of Programs reachable states Q reach initial states Q init safe invariant Q I

Strongest Postconditions The strongest postcondition post( ½,A) holds for any state q that is a ½ -successor state of some state satisfying A: q’ ² post( ½,A) iff 9 q 2 Q. q ² A Æ q,q’ ² ½ or equivalently post( ½, A) = ( 9 V. A Æ ½ ) [V/V’] Compute reach by applying post iteratively to init

Example: Application of post A = pc = ` 2 Æ y ¸ z ½ = move( ` 2, ` 2 ) Æ x < y Æ x’ = x + 1 Æ skip(y,z) post( ½, A) = ( 9 V. A Æ ½ ) [V/V’] = ( 9 pc x y z. pc = ` 2 Æ y ¸ z Æ pc = ` 2 Æ pc’ = ` 2 Æ x<y Æ x’ = x+1 Æ y’ = y Æ z’ = z) [pc/pc’, x/x’, y/y’, z/z’] = (y’ ¸ z’ Æ pc’ = ` 2 Æ x’ - 1 < y’) [pc/pc’, x/x’, y/y’, z/z’] = y ¸ z Æ pc = ` 2 Æ x · y

Iterating post A, if i = 0 post(post i -1 ( ½, A) if i > 0

Finite Iteration of post May Suffice

Example Iteration ½ 1 = move( ` 1, ` 2 ) Æ y ¸ z Æ skip(x,y,z) ½ 2 = move( ` 2, ` 2 ) Æ x < y Æ x’ = x + 1 Æ skip(y,z) ½ 3 = move( ` 2, ` 3 ) Æ x ¸ y Æ skip(x,y,z) ½ 4 = move( ` 3, ` err ) Æ x < z Æ skip(x,y,z) ½ 5 = move( ` 3, ` exit ) Æ x ¸ z Æ skip(x,y,z) post 0 (R, init) = init = pc = ` 1 post 1 (R, init) = post( ½ 1, init) = pc = ` 2 Æ y ¸ z post 2 (R, init) = post( ½ 2, post(R, init)) Ç post( ½ 3, post(R, init)) = pc = ` 2 Æ y ¸ z Æ x · y Ç pc = ` 3 Æ y ¸ z Æ x ¸ y post 3 (R, init) = post( ½ 2, post 2 (R, init)) Ç post( ½ 3, post 2 (R, init)) Ç post( ½ 4, post 2 (R, init)) Ç post( ½ 5, post 2 (R, init))

Example Iteration ½ 1 = move( ` 1, ` 2 ) Æ y ¸ z Æ skip(x,y,z) ½ 2 = move( ` 2, ` 2 ) Æ x < y Æ x’ = x + 1 Æ skip(y,z) ½ 3 = move( ` 2, ` 3 ) Æ x ¸ y Æ skip(x,y,z) ½ 4 = move( ` 3, ` err ) Æ x < z Æ skip(x,y,z) ½ 5 = move( ` 3, ` exit ) Æ x ¸ z Æ skip(x,y,z) post 2 (R, init) = post( ½ 2, post(R, init)) Ç post( ½ 3, post(R, init)) = pc = ` 2 Æ y ¸ z Æ x · y Ç pc = ` 3 Æ y ¸ z Æ x ¸ y post 3 (R, init) = post( ½ 2, post 2 (R, init)) Ç post( ½ 3, post 2 (R, init)) Ç post( ½ 4, post 2 (R, init)) Ç post( ½ 5, post 2 (R, init)) = pc = ` 2 Æ y ¸ z Æ x · y Ç pc = ` 3 Æ y ¸ z Æ x = y Ç pc = ` exit Æ y ¸ z Æ x · y Ç false

Example Iteration post 3 (R, init) = = pc = ` 2 Æ y ¸ z Æ x · y Ç pc = ` 3 Æ y ¸ z Æ x ¸ y Ç pc = ` exit Æ y ¸ z Æ x · y post 4 (R, init) = post 3 (R, init) Fixed point: reach = post 0 (R, init) Ç post 1 (R, init) Ç post 2 (R, init) Ç post 3 (R, init) = pc = ` 1 Ç pc = ` 2 Æ y ¸ z Ç pc = ` 3 Æ y ¸ z Æ x ¸ y Ç pc = ` exit Æ y ¸ z Æ x · y

Checking Safety An inductive invariant I contains the initial states and is closed under successors: ² init ) I and ² post(R, I ) ) I A program is safe if there exists a safe inductive invariant. reach is the strongest inductive invariant.

Inductive Invariants for Example Program weakest inductive invariant: true – set of all states – contains error states strongest inductive invariant: reach pc = ` 1 Ç pc = ` 2 Æ y ¸ z Ç pc = ` 3 Æ y ¸ z Æ x ¸ y Ç pc = ` exit Æ y ¸ z Æ x ¸ y slightly weaker inductive invariant: pc = ` 1 Ç pc = ` 2 Æ y ¸ z Ç pc = ` 3 Æ y ¸ z Æ x ¸ y Ç pc = ` exit Can we drop another conjunct in one of the disjuncts?

1: assume y ¸ z; 2: while x < y do x := x + 1; 3: assert x ¸ z Safe inductive invariant: pc = ` 1 Ç pc = ` 2 Æ y ¸ z Ç pc = ` 3 Æ y ¸ z Æ x ¸ y Ç pc = ` exit `1`1 `1`1 `2`2 `2`2 `3`3 `3`3 ` err ` exit y ¸ z x ¸ z x ¸ y x < y Æ x’ = x + 1 x < z Inductive Invariants for Example Program

Computing Inductive Invariants We can compute the strongest inductive invariants by iterating post on init. Can we ensure that this process terminates? In general no: checking safety of programs is undecidable. But we can compute weaker inductive invariants – conservatively abstract the behavior of the program – iterate an abstraction of post that is guaranteed to terminate.

Abstracting post instead of iteratively applying post, use over- approximation post # such that always post( ½, F) ² post # ( ½, F) decompose computation of post # into two steps: – first, apply post and – then, over-approximate the result define abstraction function ® such that F ² ® (F) for a given abstraction function ® define post # ( ½, F) = ® (post( ½, F))

Abstracting reach by reach #

Predicate Abstraction

state space Q error states error reachable states reach invariant reach # x:0,y:5 x:1,y:5 p1Æp2Æ…p1Æp2Æ… :p1Æp2Æ…:p1Æp2Æ… p 1 ´ x · 0 p 2 ´ y>0 … x:-1,y:3 x:0,y:3

Example: compute ® (pc = ` 2 Æ y ¸ z Æ x + 1 · y) Preds = {pc = ` 1,..., pc = ` err, y ¸ z, x · y} result of abstraction = conjunction of implied predicates ® (pc = ` 2 Æ y ¸ z Æ x + 1 · y) = pc = ` 2 Æ y ¸ z pc = ` 1 pc = ` 2 pc = ` 3 pc = ` exit pc = ` err y ¸ zx · y pc = ` 2 Æ y ¸ z Æ x + 1 · y ² ²² ² ² ² ² / / / / /

Trivial Abstraction Result of applying predicate abstraction is true if none of the predicates is implied by F ® (F) = true “predicates are too specific” This is always the case if Preds = ;

Algorithm AbstReach /

Abstract Reachability Graph Preds = {false, pc = ` 1,..., pc = ` err, y ¸ z, x · y} nodes F 1,..., F 4 2 Q # reach labeled edges 2 Tree dotted edge: entailment relation (here: post # ( ½ 2, F 2 ) ² F 2 F 1 : pc = ` 1 F 2 : pc = ` 2 Æ y ¸ z F 3 : pc = ` 3 Æ y ¸ z Æ x ¸ y F 4 : pc = ` exit Æ y ¸ z Æ x ¸ y ½2½2 ½1½1 ½3½3 ½5½5 F 1 = ® (init) F 2 = post # ( ½ 1, F 1 ) post # ( ½ 2, F 2 ) ² F 2 F 3 = post # ( ½ 3, F 2 ) F 4 = post # ( ½ 5, F 3 )

Abstract Reachability Graph state space Q error states error reachable states reach x:0,y:5 x:1,y:5 p1Æp2Æ…p1Æp2Æ… :p1Æp2Æ…:p1Æp2Æ… p 1 ´ x · 0 p 2 ´ y>0 … x:=x+1 invariant reach #

Example: Computing reach # post( ½ 1, F 1 )

application of ½ 1, ½ 4, and ½ 5 on F 2 results in false (since ½ 1, ½ 4, ½ 5 are applicable only if pc = ` 1 or pc = ` 3 holds) for ½ 2 we obtain post # ( ½ 2, F 2 ) = ® (pc = ` 2 Æ y ¸ z Æ x · y) = pc = ` 2 Æ y ¸ z result is F 2, which is already subsumed by reach # for ½ 3 we obtain post # ( ½ 3, F 2 ) = ® (pc = ` 3 Æ y ¸ z Æ x ¸ y) = pc = ` 3 Æ y ¸ z Æ x ¸ y = F 3 add new node F 3 to reach #, new edge to Tree Example: Computing reach #

application of ½ 1, ½ 2, and ½ 3 on F 3 results in false for ½ 5 we obtain post # ( ½ 5, F 3 ) = ® (pc = ` exit Æ y ¸ z Æ x ¸ y) = pc = ` exit Æ y ¸ z Æ x ¸ y = F 4 new node F 4 in reach #, new edge in Tree for ½ 4 (assertion violation) we obtain post # ( ½ 4, F 3 ) = ® (pc = ` err Æ y ¸ z Æ x ¸ y Æ x < z) = false any further application of program transitions does not compute any additional reachable states thus, reach # = F 1 Ç F 2 Ç F 3 Ç F 4 since reach # Æ pc = ` err ² false the program is proven safe. Example: Computing reach #

Abstract Reachability Graph with Preds = {false, pc = ` 1,..., pc = ` err, y ¸ z} F 1 : pc = ` 1 F 2 : pc = ` 2 Æ y ¸ z F 3 : pc = ` 3 Æ y ¸ z F 4 : pc = ` err Æ y ¸ z ½2½2 ½1½1 ½3½3 ½4½4 F 1 = ® (init) F 2 = post # ( ½ 1, F 1 ) post # ( ½ 2, F 2 ) ² F 2 F 3 = post # ( ½ 3, F 2 ) F 4 = post # ( ½ 4, F 3 ) F 5 = post # ( ½ 5, F 3 ) F 5 : pc = ` exit Æ y ¸ z ½5½5

Too Coarse Abstraction state space Q error states error reachable states reach invariant reach #

Finding the Right Predicates omitting just one predicate (in the example: x ¸ y) may lead to an over-approximation reach # such that reach # Æ error ² false that is, AbstReach without the predicate x ¸ y fails to prove safety How can we find the right predicates? /

Counterexample Path Tree relation records sequence of transitions leading to F 4 – apply ½ 1 to F 1 and obtain F 2 – apply ½ 3 to F 2 and obtain F 3 – apply ½ 4 to F 3 and obtain F 4 counterexample path: sequence of transitions ½ 1, ½ 3, ½ 4 Using this path and the functions ® and post # for the current set of predicates we obtain F 4 = post # ( ½ 4, post # ( ½ 3, post # ( ½ 1, ® (init)))) that is, F 4 is the over-approximation of the post-condition computed along the counterexample path.

Analysis of Counterexample Path check if the counterexample path also leads to the error states when no over-approximation is applied compute post( ½ 4, post( ½ 3, post( ½ 1, init))) = post( ½ 4, post( ½ 3, pc = ` 2 Æ y ¸ z)) = post( ½ 4, pc = ` 2 Æ y ¸ z Æ x ¸ y) = false by executing the program transitions ½ 1, ½ 3, and ½ 4 it is not possible to reach any error state. conclude that the over-approximation is too coarse when dealing with the above path.

Refinement of Abstraction need a more precise over-approximation that will prevent reach # from including error states. need a more precise over-approximation that will prevent ® from including states that lead to error states along the path ½ 1, ½ 3, ½ 4. need a refined abstraction function and a corresponding post # such that the execution of AbstReach along the counterexample path does not compute a set of states that contains some error states post # ( ½ 4, post # ( ½ 3, post # ( ½ 1, ® (init)))) Æ error ² false

Over-Approximation along Counterexample Path goal: post # ( ½ 4, post # ( ½ 3, post # ( ½ 1, ® (init)))) Æ error ² false find formulas F 1, F 2, F 3, F 4 such that init ² F 1 post( ½ 1, F 1 ) ² F 2 post( ½ 3, F 2 ) ² F 3 post( ½ 4, F 3 ) ² F 4 F 4 Æ error ² false thus, F 1,..., F 4 guarantee that no error state can be reached but may still approximate, i.e., allow additional states example choice for F 1,..., F 4 F 1 = pc = ` 1 F 2 = pc = ` 2 Æ y ¸ z, F 3 = pc = ` 3 Æ x ¸ z F 4 = false

Refinement of Predicate Abstraction given formulas F 1, F 2, F 3, F 4 such that init ² F 1 post( ½ 1, F 1 ) ² F 2 post( ½ 3, F 2 ) ² F 3 post( ½ 4, F 3 ) ² F 4 F 4 Æ error ² false add atoms of F 1,..., F 4 to Preds. refinement guarantees that counterexample path ½ 1, ½ 3, ½ 4 is eliminated.

CEGAR: Counter-Example Guided Abstraction Refinement Loop function AbstRefineLoop begin Preds := ; ; repeat (reach #, Tree) := AbstReach (Preds) if exists F 2 reach # such that F Æ error ² false then path := MakePath (F, Tree) if FeasiblePath (path) then return “counterexample path: path" else Preds := Preds [ RefinePath (path) else return “program is safe" end /

Path Computation function MakePath input F err - reachable abstract error state formula Tree – abstract reachability tree begin path := empty sequence F’ := F err while exist F and ½ such that (F, ½, F’) 2 Tree do path := ½. path F’ := F return path end

Feasibility of a Path function FeasiblePath input ½ 1... ½ n - path begin F := post( ½ 1, ±... ± ½ n, init) if F Æ error ² false then return true else return false end

Counterexample-Guided Predicate Discovery function RefinePath input ½ 1... ½ n – infeasible path begin F 1,..., F n+1 := compute such that init ² F 1 and post( ½ 1, F 1 ) ² F 2 and... post( ½ n, F n ² F n+1 and F n+1 Æ error ² false return {F 1,..., F n+1 } end omitted: particular algorithm for finding the F 1,..., F n+1