Review for Final Exam

Transcription

1 Review for Final Exam Some selected slides from the second half of the semester Move from Dynamic Analysis to Sta?c Analysis Dynamic analysis approaches are based on sampling the input space Infer behavior or proper?es of a system from execu?ng a sample of test cases Func?onal (Black Box) and Structural (White Box) approaches 1

2 Sta?c Analysis Approaches Dependence Analysis (We have already seen this) Symbolic Evalua?on Formal Verifica?on Data Flow Analysis Concurrency Analysis Reachability analysis Finite- state Verifica?on Sta?c Analysis Approaches Dependence Analysis Symbolic Evalua?on Formal Verifica?on Data Flow Analysis Concurrency Analysis Reachability analysis Finite- state Verifica?on 2

3 Represen?ng Computa?on Symbolic names represent the input values the path value PV of a variable for a path describes the value of that variable in terms of those symbolic names the computa?on of the path C[P] is described by the path values of the outputs for the path Represen?ng Condi?onals an interpreted branch condi?on or interpreted predicate is represented as an inequality or equality condi?on the path condi?on PC describes the domain of the path and is the conjunc?on of the interpreted branch condi?ons the domain of the path D[P] is the set of input values that sa?sfy the PC for the path 3

4 procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 write Y; endif; end Contrived; Example program Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 + In 2 true In 1 3 = In 1 3 5,6 Y In 2 +5 In 1 3 In 2 >0 7,9 (In 1 3 In 2 >0 In 1 - ( In ) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Note: In i means the ith value taken as input to the program procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 write Y; endif end Contrived Presen?ng the results Statements PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,6 Y In 2 +5 In 1 3 In 2 >0 7,9 In 1 3 In 2 >0 In 1 - (In 2 +5) 0 = In 1 3 In 2 >0 (In 1 - y) 5 P = 1, 2, 3, 5, 6, 7, 9 D[P] = { (In 1, In 2 ) In 1 3 In 2 >0 In 1 - In 2 5} C[P] = PV.Y =, In 2 +5 ( PV.Z = In 1 +, In 2 ) 4

5 Results (feasible path) In 2 In 1 3 (In 1 - In 2) 5 In 2 >0 In 1 P = 1, 2, 3, 5, 6, 7, 9 D[P] = { (In 1, In 2 ) In 1 3 In 2 >0 (In 1 - In 2) 5} C[P] = PV.Y = In 2 +5 Evalua?ng another path procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 write Y; endif; end Contrived; Stmts PV PC 1 X In 1 true Y In 2 2,3 Z In 1 + In 2 true In 1 3 = In 1 3 5,7 In 1 3 In 2 0 7,8 In 1 3 In 2 0 In 1 - In 2 < 0 P = 1, 2, 3, 5, 7, 8 D[P] = { (In 1, In 2 ) In 1 3 In 2 0 In 1 - In 2 <0} infeasible path! 5

6 Results (infeasible path) In 2 (In 1 -In 2 ) <0 In 1 3 In 2 0 x Represen?ng Condi?onals an interpreted branch condi?on or interpreted predicate is represented as an inequality or equality condi?on the path condi?on PC describes the domain of the path and is the conjunc?on of the interpreted branch condi?ons the domain of the path D[P] is the set of input values that sa?sfy the PC for the path 6

7 What This Capability Is Good For: Simplifica?on Path Condi?on Consistency Fault Detec?on Path Selec?on Test Data Genera?on Simplifica?on Reduces path condi?on to a canonical form Simplifier ooen determines consistency PC = ( In 1 >= 5 ) (In 1 < 0 ) May want to display path computa?on in simplified and unsimplified form PV.X = In 1 + (In 1 +1) + (In 1 + 2) + (In 1 + 3) = 4 *In

8 Path Condi?on Consistency strategy = solve a system of constraints theorem prover consistency algebraic, e.g., linear programming consistency and find solu4ons solu?on is an example of automa?cally generated test data In general it is not possible to solve an arbitrary system of constraints Some complica?ons: Non- linear constraints X*Y = 10 X 3 - X 2 +3X+Y 3 =0 Integer constraints Things like the above where the solu?ons must be integers Constraints involving non- numbers Character strings Etc. Can be dealt with separately (to some extent), but not all together. 8

9 Fault Detec?on Implicit fault condi?ons E.g. Subscript value out of bounds E.g. Division by zero e.g., Q:=N/D Create asser?on to represent the fault and conjoin with the pc Division by zero assert(divisor 0) Determine consistency PC P and (PV.divisor = 0) if consistent then error possible Must check the asser?on at the point in the path where the construct occurs Add in Diagnos?c Constraint procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 Z:= X / (Y- 2) 10 write Z; endif; end Contrived; Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,6 Y In 2 +5 In 1 3 In 2 >0 7,9,10 Z In 1 / (In ) = In 1 /(In 2 +3) PC: (In 1 3 In 2 >0 In 1 - (In 2 +5) 0) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Diagnos?c constraint: (In )=0 or In 2 =- 3 9

10 Is Division by Zero possible? Path Constraint = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Diagnos?c Constraint In 2 =- 3 Total Constraint: In 1 3 In 2 >0 (In 1 - In 2 ) 5 In 2 =- 3 In 2 Results In 1 3 (In 1 - In 2) 5 In 2 >0 In 2 = -3 In 1 Division by zero is impossible 10

11 Add in Different Constraint procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 Z:= X / (Y- 8) 10 write Z; endif; end Contrived; Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,6 Y In 2 +5 In 1 3 In 2 >0 7,9,10 Z In 1 / (In ) = In 1 /(In 2-3) PC: (In 1 3 In 2 >0 In 1 - (In 2 +5) 0) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Diagnos?c constraint: (In )=0 or In 2 =3 In 2 Results In 1 3 (In 1 - In 2) 5 In 2 = 3 In 2 >0 In 1 Division by zero is now possible if the second input value is 3 and the first input value is appropriate 11

12 Change the Example program Path procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 write Y; endif; end Contrived; Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,7 Y In 2 +5 In 1 3 In 2 0 7,9 (In 1 3 In 2 >0 In 1 - (In 2 +5) 0) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Example program With Asser?on procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; ASSERT X<Y 7 if X - Y < 0 then 8 write Z; else 9 write Y; endif; end Contrived; Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,7 In 1 3 In 2 0 ASSERT In 1 < In 2 7,9 (In 1 3 In 2 >0 In 1 - (In 2 +5) 0) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) 12

13 Combine Path Condi?on with Asser?on Path Condi?on In 1 3 In 2 0 Asser?on In 1 < In 2 Yields an inconsistency Asser?on will always fail on this path A different asser?on may fail some?mes or never The same asser?on may behave differently on different paths Simplifica?on Reduces path condi?on to a canonical form Simplifier ooen determines consistency PC = ( In 1 >= 5 ) (In 1 < 0 ) May want to display path computa?on in simplified and unsimplified form PV.X = In 1 + (In 1 +1) + (In 1 + 2) + (In 1 + 3) = 4 *In

14 Path Condi?on Consistency strategy = solve a system of constraints theorem prover consistency algebraic, e.g., linear programming consistency and find solu4ons solu?on is an example of automa?cally generated test data In general it is not possible to solve an arbitrary system of constraints Some complica?ons: Non- linear constraints X*Y = 10 X 3 - X 2 +3X+Y 3 =0 Integer constraints Things like the above where the solu?ons must be integers Constraints involving non- numbers Character strings Etc. Can be dealt with separately (to some extent), but not all together. 14

15 Fault Detec?on Implicit fault condi?ons E.g. Subscript value out of bounds E.g. Division by zero e.g., Q:=N/D Create asser?on to represent the fault and conjoin with the pc Division by zero assert(divisor 0) Determine consistency PC P and (PV.divisor = 0) if consistent then error possible Must check the asser?on at the point in the path where the construct occurs Add in Diagnos?c Constraint procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 Z:= X / (Y- 2) 10 write Z; endif; end Contrived; Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,6 Y In 2 +5 In 1 3 In 2 >0 7,9,10 Z In 1 / (In ) = In 1 /(In 2 +3) PC: (In 1 3 In 2 >0 In 1 - (In 2 +5) 0) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Diagnos?c constraint: (In )=0 or In 2 =- 3 15

16 Is Division by Zero possible? Path Constraint = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Diagnos?c Constraint In 2 =- 3 Total Constraint: In 1 3 In 2 >0 (In 1 - In 2 ) 5 In 2 =- 3 In 2 Results In 1 3 (In 1 - In 2) 5 In 2 >0 In 2 = -3 In 1 Division by zero is impossible 16

17 Add in Different Constraint procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 Z:= X / (Y- 8) 10 write Z; endif; end Contrived; Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,6 Y In 2 +5 In 1 3 In 2 >0 7,9,10 Z In 1 / (In ) = In 1 /(In 2-3) PC: (In 1 3 In 2 >0 In 1 - (In 2 +5) 0) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Diagnos?c constraint: (In )=0 or In 2 =3 In 2 Results In 1 3 (In 1 - In 2) 5 In 2 = 3 In 2 >0 In 1 Division by zero is now possible if the second input value is 3 and the first input value is appropriate 17

18 Change the Example program Path procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; 7 if X - Y < 0 then 8 write Z; else 9 write Y; endif; end Contrived; Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,7 Y In 2 +5 In 1 3 In 2 0 7,9 (In 1 3 In 2 >0 In 1 - (In 2 +5) 0) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) Example program With Asser?on procedure Contrived is X, Y, Z : integer; 1 read X, Y; 2 if X 3 then 3 Z := X+Y; else 4 Z := 0; endif; 5 if Y > 0 then 6 Y := Y + 5; endif; ASSERT X<Y 7 if X - Y < 0 then 8 write Z; else 9 write Y; endif; end Contrived; Stmt PV PC 1 X In 1 true Y In 2 2,3 Z In 1 +In 2 true In 1 3 = In 1 3 5,7 In 1 3 In 2 0 ASSERT In 1 < In 2 7,9 (In 1 3 In 2 >0 In 1 - (In 2 +5) 0) = (In 1 3 In 2 >0 (In 1 - In 2 ) 5) 18

19 Combine Path Condi?on with Asser?on Path Condi?on In 1 3 In 2 0 Asser?on In 1 < In 2 Yields an inconsistency Asser?on will always fail on this path A different asser?on may fail some?mes or never The same asser?on may behave differently on different paths Informa?on explosion Some Problems Imprac?cality of all paths Path condi?on consistency Aliasing elements of a compound type e.g., arrays and records pointers 19

20 Alias Problems Do for I = 1 to 100; A(I) := I A(2) := 5 read I; A(I) Indeterminate subscript What is X? X := A(2) Y:=A(I) What is Y? I > 2 Z:=A(I) What is Z? constraints on subscript value due to path condition add more uncertainty Par?al Evalua?on Similar to Dynamic Symbolic Evalua?on Provide some of the input values E.g., If input is x and y, provide a value for x Create a representa?on that incorporates those values and that is equivalent to the original representa?on if it were given the same values as the preset values P(x, y) = P x (y) 20

21 Global Symbolic Evalua?on Loop Analysis creates recurrence rela?ons for variables and loop exit condi?on solu?on is a closed form expression represen?ng the loop then, loop expression evaluated as a single node Loop analysis example read A, B Area := 0 X := A write AREA X B f t AREA:= AREA+A X:= X+1 21

22 Loop Analysis Example Nota?on <iden4fier> k denotes the value of <iden4fier> aoer k itera?ons Recurrence Rela?ons AREA k = AREA k- 1 + A 0 X k = X k X B T Loop Exit Condi?on X k > B 0 AREA:= AREA+A X:= X+1 Find path computa?on and path domain for paths that iterate the loop P2 = (1, 2, 3, 4, (5, 6), 7) D[P2] = (b>a) C[P2] = (AREA = (b- a+1) a ) k e = b - a +1 X : = b + 1 X:= A read A, B Area:= 0 X 0 = a B 0 = b A 0 = a K e = b - a +1 X = b+1 AREA = (b-a+1) a f X B t write AREA AREA:= AREA+A X:= X+1 22

23 Formal Verifica?on Computer Science Fall 2011 Prof. L. J. Osterweil Material adapted from slides originally prepared by Prof. L. A. Clarke Floyd Method of Induc?ve Asser?ons 1. Show that given input asser?ons, aoer execu?ng the program, program sa?sfies output asser?ons Break the program into program fragments, and prove each fragment separately Divide and conquer approach Use induc?on to prove that fragments with loops behave as intended By transi?vity, proofs of all the fragments imply that the program is correct 2. Show that the program must terminate 23

24 Pictorially: A single path (no loops) intermediate asser?ons ini?al asser?on A i A i+1 C i STRAIGHT- LINE CODE final asser?on Why does this work? suppose P is an arbitrary path through the program can denote it by P = A 0 C 1 A 1 C 2 A 2...C n A n where A 0 - Ini?al asser?on A n - Final asser?on A i - C i - Intermediate asser?ons Loop free, uninterrupted, straight- line code If it has been shown that i, 1 i < n: A i C i A i+1 Then, by transi?vity A 0... A n 24

25 Asser?ons Specifica?on that is intended to be true at a given site in the program Use three types of asser?ons: ini?al : sited before the ini?al statement e.g., precondi?on final : sited aoer the final statement e.g., postcondi?on intermediate: sited at various internal program loca?ons subject to the rule: a "loop invariant is true on every itera?on thru the loop Floyd s Induc?ve Verifica?on Method (more carefully stated) Specify ini?al and final asser?ons to capture intent Place intermediate asser?ons so as to "cut" every program loop For each pair of asser?ons where there is at least one executable (asser?on- free) path from the first to the second, create and prove the verifica?on condi?on: assume that the first asser?on is true show that for all (asser?on- free, executable) paths from the first asser?on to the second, that the second asser?on is true This above establishes par?al correctness Show that the program terminates This establishes total correctness 25

26 Wensley s Algorithm Input P, Q, E A 0.0 B Q/2 D 1.0 Y 0.0 A0" AI" AF" D E P-A-B 0.0 Y Y+(D/2.0) A A+B B B/2.0 D D/2.0 Asser?ons Ini?al: A 0 : {(0 P<Q) (0< E)} computed quotient" Final:"A F : {((P/Q-E)<Y (P/Q))}" Intermediate: "" "A I : {(A=Q*Y) (B=Q*(D/2)) " " (k 0, k integer D=2 -k ) " " " ((P/Q)-D)<Y (P/Q)}" computed error" Y is within the computed error D of P/Q" 26

27 Summary of Four Lemmas Needed Input P, Q, E I. Ini?al asser?on, A0, to AI II. AI, false branch, to AI III. AI, true branch, to AI IV. AI, to AF, final asser?on A 0.0 B Q/2 D 1.0 Y 0.0 D E P-A-B 0.0 AI" A0" AF" Y Y+(D/2.0) A A+B B B/2.0 D D/2.0 Lemmas called verification conditions Lemma I: A 0 to A I A 0 : Ini?al Asser?on (0 P < Q) Λ (0 < E) code { Input P, Q, E A 0; B Q/2; D 1; Y 0; Proof:" 1) A = 0; Q *Y = Q * 0 = 0 "A = Q *Y" 2) B = Q/2 = Q * 1/2 = Q*D/2" 3) D = 1 = 2-0 " 4) P/Q - 1 < Y = 0 P/Q A 1 : A = Q * Y B = Q * D/2 D = 2 - k,k=0 P/Q - D < Y P/Q because 0 P/Q < 1 given by input assertion" 27

28 Proof of Lemma II A = Q * Y" B = Q * D/2" D = 2 -k for some integer k" P/Q - D < Y P/Q" D E [constraint] " P - A - B < 0 [constraint]" "B B/2" "D D/2" A = Q * Y " } "B = Q * D /2" "D = 2 -(k+1) for some integer k" "P/Q - D < Y P/Q" (Symbolic execution shows A = A, B = B/2; D = D/2; Y = Y)" Proof:" 1) A = A = Q * Y = Q * Y 2) B = B/2= (Q * D/2)/2 =(Q * 2D /2)/2 = Q*D /2 3) D = D/2= 2 -k /2 = 2 -k-1 =2 -(k+1) 4) a)p-a-b < 0 (constraint ) P - Q * Y - Q * D/2 < 0" P/Q - Y - D/2 < 0 (uses Q > 0)" P/Q - D/2 < Y" but D = D/2, so P/Q - D < Y " b)y P/Q => Y P/Q " This is only par?al correctness Must also prove termina?on In general, can not prove termina?on For most programs, can usually do it by showing that each loop must terminate For our example: given that (E>0) observe that D is halved on each itera?on and E does not change Thus, eventually D<E and the loop terminates Input P, Q, E A 0.0 B Q/2 D 1.0 Y 0.0 D E P-A-B 0.0 B B/2.0 D D/2.0 A0" AI" AF" Y Y+(D/2.0) A A+B 28

29 Example: FindValue Int FindValue (int table[ ], int n, int key) { boolean found; found=false; current = 0; while (not found && current < n) { if (table[current] == key) found = true; else current = current + 1; } if (not found) { table[current] = key; } return (current); } // precondi?ons requires n >= 0; requires key!= null; requires table!= null; requires n<=table.size(); // postcondi?ons ensures (table[\result] == key) ensures \forall(int i=0;i < \result; i++;) (table[i]!= key) ensures \result>=0 && \result<=n ensures \result==n => table.size()>=n+1 ensures \result<n => table.size() >=n FindValue found=false; current = 0; not found && current < n F not found T table[current] = key T F table[current]==key T F found = true current = current + 1; return(current) 29

30 loop invariant {code3} loop invariant ensures (found ==false) ensures current >=0 && current < n ensures \forall(int i=0;i < current ; i++;) (table[i]!= key) {not found && current < n If table[current ] == key then found =true else current =current +1 not found && current < n } ensures (found ==false) ensures current>=0 && current< n ensures \forall(int i=0;i < current; i++;) (table[i]!= key) 2 cases to consider: true and false branch For the true case, only found needs to dis?nguish ini?al from changed values a) True case: using symbolic execu?on Given found ==false && current < n By execu?on (found =true) By subs?tu?on (not found = false) => infeasible path Thus, only have to consider the false branch Must Prove Termina?on Int FindValue (int table[ ], int n, int key) { boolean found; found=false; current = 0; while (not found && current < n) { if (table[current] == key) found = true; else current = current + 1; } if (not found) { table[current] = key; } return (current); } // precondi?ons requires n >= 0; requires key!= null; requires table!= null; requires n<=table.size(); // postcondi?ons ensures (table[\result] == key) ensures \forall(int i=0;i < \result; i++;) (table[i]!= key) ensures \result>=0 && \result<=n ensures \result==n => table.size()>=n+1 ensures \result<n => table.size() >=n 30

31 Beware Because Formal verifica?on can be used to prove that: Given the input condi?ons, aoer execu?ng the program, the output condi?on is sa?sfied It does not prove that the program is correct because: The postcondi?on may be incorrect or incomplete The precondi?on might be wrong The invariants might be wrong The proof might be incorrect Observa?ons about Formal Verifica?on Some proofs are simple but many proofs are long, tedious & hard asser?ons are hard to get right invariants are difficult to get right need to support proof strategy proofs themselves some?mes require deep program insight May require axioms about the domain 31

32 Help with long tedious proofs: Floyd- Hoare axioma?c proof method As in Floyd's induc?ve asser?on method, we construct a sequence of asser?ons, But now each can be inferred from previously proved asser?ons and the rules and axioms about the statements and operahons of the program To do this we need some axioms and rules about the programming language Hoare axioms and proof rules Example: a simple programming language that deals only with integers and has the following types of constructs: assignment statement x:= f composi?on of a sequence of statements S1, S2 condi?onal (alterna?ve statements) if B then S1 else S2 itera?on while B do S 32

33 Sooware Tools Can Help Proof Checkers: Scru?nize the steps of a proof and determine if they are sound Iden?fy the rule(s) of inference, axiom(s), etc. needed to jus?fy each step Is the proof checker right (verify it? with what?...) One successful approach: human/computer collabora?on Humans architect the proof by providing precondi?ons, post condi?ons, loop invariants Computer a empts the proof (generally by exhaus?ve search of space of possible axioms and inferences at each step) Gives an indica?on of where it is stuck (e.g., verifica?on condi?ons it has not proved) Human interven?on aoer computer has tried for a while Add addi?onal invariants Add addi?onal axioms Computer rea empts proof 33

34 Another Success: Verify first (then code) Create ini?al and final asser?ons Specify loop invariants And other intermediate asser?ons Specify lemmas Prove lemmas Fill in the code Deeper Issues unsuccessful proof a empt??? incorrect sooware incorrect asser?ons incorrect placement of asser?ons inept prover any combina?on (or all) of the above failed proofs ocen indicate which of the above is likely to be the problem (especially to an astute prover) 34

35 Deeper Issues undecidability of predicate calculus - - no way to be sure when you have a false theorem there is no sure way to know when you should quit trying to prove a theorem (and change something) Set of proofs are generally much longer than the sooware being verified But most proofs are done automa?cally Most proofs are trivial Data- Flow Analysis Computer Science Fall 2011 Prof. L. J. Osterweil Material adapted from slides originally prepared by Prof. L. A. Clarke 35

36 Data Flow Analysis (DFA) Efficient technique for proving proper?es about programs Not as powerful as automated theorem provers, but requires less human exper?se Uses an annotated control flow graph model of the program Compute facts for each node Use the flow in the graph to compute facts about the whole program We ll focus on single units Some examples of DFA techniques DFA used extensively in program op?miza?on e.g., determine if a defini?on is dead (and can be removed) determine if a variable always has a constant value determine if an asser?on is always true and can be removed DFA can also be used to find anomalies in the code Find def/ref anomalies [Osterweil and Fosdick] Cecil/Cesar system demonstrated the ability to prove general user- specified proper?es [Olender and Osterweil] FLAVERS demonstrated applicability to concurrent system [Dwyer and Clarke] Why anomalies and not faults? May not correspond to an actual executable failure 36

37 Compu?ng values for a node Keep track of the defini?ons into a node that have not been redefined Flow out of a node depends on flow in and on what happens in the node Forward flow In(n) def(n)={y} ref(n)={x } y:= x Out(n) Example: Possible Reaching Defini?ons X 1" Y 2" X 4" int x,y;... x := foo(); y := x + 2; if x > 0 then x := x + y; end if;... Forward flow, any path problem, def/ref sets are the ini?al facts associated with each node def={x} ref={ } def={y} ref={x} def={} ref={x} def={x} ref={x,y} def={} ref={ } { } x = foo() {X 1 } {X 1 } y = x + 2 {X 1,Y 2 } {X 1,Y 2 } if(x > 0) {X 1,Y 2 } {X 1,Y 2 } x = x + y {X 4,Y 2 } {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } 37

38 Example: Definite Reaching Defini?ons X 1" Y 2" X 4" int x,y;... x := foo(); y := x + 2; if x > 0 then x := x + y; end if;... Forward flow, all path problem, def/ref sets are the ini?al facts associated with each node { } x = foo() {X 1 } {X 1 } y = x + 2 {X 1,Y 2 } {X 1,Y 2 } if(x > 0) {X 1,Y 2 } x = x + y {Y 2 } {Y 2 } {X 1,Y 2 } {X 4,Y 2 } Keep track of the (forward) references that have not found their (backward) definition site Flow out of a node depends on flow in and on what happens in the node Live Variables: Compu?ng values for a node y:= x Backward flow Out(n) In(n) 38

39 Example: Possible Live Variables foo(); x = foo() y = x + 2 if(x > 0) { } {x} {x} {x,y} {x,y} {x,y} Backward flow, any path problem, def/ref sets are the initial facts associated with each node x = x + y {} {} {x,y} {} Example: Definite Live Variables foo(); x = foo() y = x + 2 if(x > 0) { } {x} {x} {x} {x} {} Backward flow, all path problem, def/ref sets are the initial facts associated with each node x = x + y {} {} {x,y} {} 39

40 Example: Definite Live Variables Backward flow, all path problem def/ref sets are the initial facts associated with each node x = foo() y = x + 2 if(x > 0) { } {x} {x} {x} {x} {} def(n)={v v is defined at n} ref(n)={v v is referenced at n} Then: Out(n) = kєsucc(n) In(k) In(n) = Out(n)-def(n) U ref(n) x = x + y {} {} {x,y} {} Fixed point The data flow analysis algorithm will eventually terminate If there are only a finite number of possible sets that can be associated with a node If the func?on that determines the sets that can be associated with a node is monotonic 40

41 Anomalous pairs of ref/def informa?on d - defined, r - referenced, u - undefined d..r: defined variable reaches a reference u..d: undefined variable reaches a defini?on d..d: defini?on is redefined before being used d..u: defini?on is undefined before being used u..r: undefined variable reaches a reference Unreferenced (dead) definition undefined reference Consider an unreferenced defini?on For a defini?on of a, want to know if that defini?on is not going to be referenced Is there some path where a is redefined or undefined before being used? May be indica?ve of a problem Usually just a programming convenience and not a problem For a defini?on of a, want to know if on all paths is a redefined or undefined before being used May be indica?ve of a problem Or could just be wasteful 41

42 Keep track of the definitions into a node that have not been referenced Flow out of a node depends on flow in and on what happens in the node Unreferenced defini?on: Compu?ng values for a node y:= x Forward flow In(n) Out(n) Keep track of the definitions into a node that have not been referenced Flow out of a node depends on flow in and on what happens in the node Unreferenced defini?on: Compu?ng values for a node y:= x Forward flow In(n) Out(n) Forward flow, all paths problem In(n) = kєpred(n) Out(k) Out(n) = In(n)-ref(n) U def(n) 42

43 int x,y;... x := foo(); y := x + 2; if x > 0 then x := x + 1; end if; y:= Unreferenced defini?ons x = foo() y = x + 2 if(x > 0) x = x + 1 Need to look at each node where there is a def Forward flow, all paths problem y:= z Data Flow Analysis Problem Need to determine the informa?on that should be computed at a node Need to determine how that informa?on should flow from node to node Backward or Forward Union or Intersec?on Ooen there is more than one way to solve a problem Can ooen be solved forward or backward, but usually one way is easier than the other Next: a general framework for defining DFA problems 43

44 Data- flow Frameworks Computer Science Fall 2011 Prof. L. J. Osterweil Material adapted from slides originally prepared by Prof. L. A. Clarke Ini?al Facts about nodes: GEN and KILL sets For each node i associate sets: GEN(i) - what is to be added (generated) KILL(i) - what is to be eliminated (killed) We make choices about how to define the GEN and KILL sets for a node depending on the problem. Ooen the GEN and KILL sets can be derived from an abstract syntax tree E.g., variables defined in a node variables referenced in a node 44

45 General Approach Ini?al node values for each node define GEN and KILL informa?on Equa?ons for each node for each node we have equa?ons of the form: IN(n i ) := Merge ( predecessor n j OUT(n j ) OUT(n j ) := Merge ( successor n j IN(n j ) Merge over {predecessors successors} of n i depends on whether it is a {forward backward}- flow problem Equa?ons for each node also usually depend on GEN and KILL informa?on that is computed for each node Ooen, for example: OUT := (IN \ KILL) U GEN General Approach (con?nued) Propaga?on rule Forward or backward IN value for the ini?al node Since IN depends on OUT, need to ini?alize OUT for each node Ini?al value depends on the problem Merge operator determined by whether it is an all- path or an any- path problem Final result rule Usually based on IN, OUT, GEN, and KILL for each node Some?mes only need to look at the final node 45

46 Choices Depend on what you want to know Constant propaga?on Dead variables Undefined references But also domain- specific things Elevator never moves with doors open Rocket engine never asked to fire unless there is fuel File use is always: (open, write, (read, write)*, close) Blood transfusion only aoer two checks succeed To be cashed a check must be ( (signed, endorsed), balance- checked, approved, logged- in) Note: some of these can be applied to precode ar?facts Each type of ques?on is nuanced. Example: Undefined reference Is it possible for the value of some variable to be undefined when it is referenced? Is it possible for the value of some variable to always be undefined when it is referenced? Are there any variables that are always undefined whenever they are referenced. Is there a specific reference to a specific variable that is Possibly undefined Always undefined 46

47 Consider Def a Def a Def a Ref a Ref a Ref a Ref a What do we want to know? Def a Def a Def a Ref a Ref a Ref a Ref a a is some?mes undefined when referenced here S?ll different flow analysis, but in this case probably just subs?tu?ng for 47

48 Works Equally Well for Close elevator door Close elevator door Close elevator door Move Elevator Move Elevator Move Elevator Move Elevator Note that Dead Definition is not worrisome here As Well As Transfuse Blood Verify right blood type Verify right blood type Transfuse Blood Verify right blood type Transfuse Blood Dead Definition is desirable and reassuring here! Transfuse Blood 48

49 Formalizing Data- flow Analysis Compute facts for each node of a control- flow graph The IN and OUT sets Depends on the direc?on facts are propagated predecessors of n Forward flow predecessors of n Backward flow IN(n) IN(n) y:= y:= OUT(n) OUT(n) successors of n successors of n Typical Merge Func?ons Forward-flow for i initial Backward-flow for i final Any-path IN(i) = OUT(j) j preds(i) All-path IN(i) = OUT(j) j preds(i) OUT(i) = IN(j) j succs(i) OUT(i) = IN(j) j succs(i) 49

50 Fixed point Compute the new In and Out values for each node Loops complicate ma ers Con?nue around loops un?l all the In and Out values stabilize at a Fixed Point Computa?on of In and Out sets reaches a fixed point, if There are only a finite number of possible sets that can be associated with a node, and If the func?on that determines the sets that can be associated with a node is monotonic Can visit each node in any order, but algorithm is more efficient if a worklist is used Worklist holds the nodes that need to have new In values computed Example - Unini?alized Variables Want to determine if it may be possible for a variable to be used without having been defined Use data- flow analysis to determine which variables are undefined at each node in the control- flow graph A variable is unini?alized on a node if it is undefined and referenced on that node Similar to undefined referenced variables shown previously, but will incorporate variables becoming undefined and not be concerned about where (just if) they are defined 50

51 Summary Are there any references that could be to a variable that is unini?alized? Summary Forward- flow problem Any- path problem Initial values: j, OUT(j) = GEN(i) = UNDEF(i) KILL(i) = DEF(i) All vars if i = 1 IN(i) = OUT(j) otherwise { j preds(i) OUT(i) = (IN(i) \ KILL(i)) GEN(i) UNINIT(i) = IN(i) REF(i) Visualizing the itera?ve worklist algorithm INITIALIZE OUT(i) TO { } GEN(i) = UNDEF(i) def(n) def(i) KILL(i) = DEF(i) {i,n,s,x}! {i,s,x}! In! In! OUT(i) = (IN(i) \ KILL(i)) GEN(i) 1! 2! Out! Out! {s,x}! IN(i) = All vars if i = 1 {i,s,x}! {s,x} { OUT(j) otherwise In! 3! ref(i,n) j preds(i) {s,x}! Out! Worklist: In! def(x) {s,x}! 1 4! Out! {s}! 2 undef(i) ref(i) 3 In! {s}! {s,x}! In! 5! 4 9! ref(x) Out! Out! ref(x,s) {i,s,x}! {s}! def(s) 9 def(s) In! {s}! In! 6! 7! {s}! 5 Out! Out! ref(s) {}! {}! 10 {i,s,x}! In! 10! In! {}! 6 Out! 8! ref(i) {i,s,x}! Out! 7 {}! def(i) 8 3 No change. No addi?ons to worklist. So we are done 51

52 Facts in Data- flow Analysis Facts are represented by a meet semi- la ce a set of values a par?al order on the values a meet operator that computes the greatest lower bound of two values with respect to the par?al order Prac?cal la ces have: a finite set of values dis?nguished top (T) and bo om ( ) elements For the unini?alized variables example, the values of the la ce are the power set of the variables in the program Variables are i, n, s, x Example Meet Semila ce values=powerset({i,n,s,x})" T = { }" = {i,n,s,x}" {}" Ordering = " Meet = " {i}" {n}" {s}" {x}" {i,n}" {i,s}" {i,x}" {n,s}" {n,x}" {s,x}" {i,n,s}" {i,s,x}" {i,n,x}" {n,s,x}" {i,n,s,x}" 52

53 Example Meet Semila ce Moves values down the la ce, from top (T) to bo om ( ) {n} U {s,x} = {n,s,x} {}" values=powerset({i,n,s,x})" T = { }" = {i,n,s,x}" Ordering = " Meet = " {i}" {n}" {s}" {x}" {i,n}" {i,s}" {i,x}" {n,s}" {n,x}" {s,x}" {i,n,s}" {i,s,x}" {i,n,x}" {n,s,x}" {i,n,s,x}" Greatest lower bound Well- formed Fixed Point Problem Condi?ons under which the data- flow analysis will always terminate If there are only a finite number of possible sets that can be associated with a node La ce is finite If the func?on that determines the sets that can be associated with a node is monotonic Always move down or stay at the same place on the la ce 53

54 Reaching Defini?ons Which defini?ons can reach a statement x i means that the defini?on of variable x at node i reached the current node X 1" Y 2" X 4" int x,y;... x := foo(); y := x + 2; if x > 0 then x := x + y; end if;... x = foo() y = x + 2 if(x > 0) { } {X 1 } {X 1 } {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } x = x + y {X 1,Y 2 } {X 4,Y 2 } Forward-flow, any-path problem {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } Reaching Defini?ons - Formalized x = foo() { } {X 1 } {X 1 } y = x + 2 {X 1,Y 2 } if(x > 0) {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } x = x + y {X 4,Y 2 } {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } In what direc?on are the facts propagated? Choice of forwards or backwards: Could propagate defini?ons forward to the statements that they reach, or could propagate statements backwards to the defini?ons Reaching defini?ons Here, easier to iden?fy defini?ons and propagate them forward Solved as a forward- flow problem 54

55 Reaching Defini?ons - Formalized x = foo() { } {X 1 } {X 1 } y = x + 2 {X 1,Y 2 } if(x > 0) {X 1,Y 2 } {X 1,Y 2 } What facts are no longer true aoer a node is processed? Called the KILL set of a node For reaching defini?ons If node i defines a variable v, then we know that for any j, v j is no longer a poten?al reaching defini?on aoer the node is processed x = x + y {X 1,Y 2 } {X 4,Y 2 } {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } KILL(i) = { j, v j if node i defines v otherwise Reaching Defini?ons - Formalized x = foo() { } {X 1 } {X 1 } y = x + 2 {X 1,Y 2 } if(x > 0) {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } x = x + y {X 4,Y 2 } How should facts be propagated over a node? Called the transfer func?on of a node For each node i, have an equa?on OUT(i) = f i ( IN(i), GEN(i), Kill(i) ) Usually depends on GEN and KILL for each node Usually: OUT(i) = (IN(i) \ KILL(i)) GEN(i) Reaching defini?ons The usual equa?on works {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } 55

56 Reaching Defini?ons - Formalized x = foo() { } {X 1 } {X 1 } y = x + 2 {X 1,Y 2 } What facts are known ini?ally? Reaching defini?ons Assuming nothing is defined before this program runs, no defini?ons can flow in, so no facts are known ini?ally if(x > 0) {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } x = x + y {X 4,Y 2 } {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } IN(1) = j, OUT(j) = Reaching Defini?ons - Formalized x = foo() { } {X 1 } {X 1 } y = x + 2 {X 1,Y 2 } if(x > 0) {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } x = x + y {X 4,Y 2 } How should the facts be interpreted once data- flow analysis stops propaga?ng? Reaching defini?ons The defini?ons that reach a node are the IN set of that node REACH(i) = IN(i) {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } 56

57 Reaching Defini?ons - Formalized Reaching defini?ons summary Forward- flow problem Any- path problem x = foo() y = x + 2 if(x > 0) { } {X 1 } {X 1 } {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } x = x + y {X 4,Y 2 } {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } Initial values: j, OUT(j) = GEN(i) = { v i REACH(i) = IN(i) if node i defines v otherwise { j, v j if node i defines v KILL(i) = otherwise if i = n IN(i) = s OUT(j) otherwise { j preds(i) OUT(i) = (IN(i) \ KILL(i)) GEN(i) Using Reaching Defini?ons for Anomaly Detec?on x = foo() y = x + 2 if(x > 0) { } {X 1 } {X 1 } {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } {X 1,Y 2 } x = x + y {X 4,Y 2 } {X 1,Y 2,X 4 } {X 1,Y 2,X 4 } Undefined referenced variable: For each node i, for each v REF(i) if there is no j, such that v j REACH(i) then v is an undefined ref at node i 57

58 foo() Example: Live Variables What definitions are live at a statement? A variable, x, is live at node i if there exists a def-clear path for x from node i to a use of x x = foo() y = x + 2 if(x > 0) { } {x} {x} {x,y} {x,y} {x,y} x = x + y {} {} {x,y} {} x = foo() y = x + 2 if(x > 0) { } {} Live Variables - Formalized {x} {x} {x,y} {x,y} {x,y} x = x + y {} {x,y} {} In what direc?on are the facts propagated? Live variables Keep track of which variables have a use on some path in the future Solve as a backward- flow problem Flow the uses of variables backwards to their defini?ons 58

59 x = foo() y = x + 2 if(x > 0) { } {} Live Variables - Formalized Live variables summary Backward- flow problem {x} {x} {x,y} {x,y} {x,y} x = x + y {} {x,y} {} Any- path problem Initial values: j, IN(j) = GEN(i) = REF(i) KILL(i) = DEF(i) OUT(i) = { j succs(i) IN(i) = (OUT(i) \ KILL(i)) GEN(i) LIVE(i) = IN(i) IN(j) if i = n f otherwise State Propaga?on Computer Science Fall 2011 Prof. L. J. Osterweil Material adapted from slides originally prepared by Prof. L. A. Clarke 59

60 A More General Conceptualiza?on Variables move around the flow graph in different states Start out in undefined state Can transi?on to defined Will the variable encounter a ref while in undefined state? THINK PACMAN? When Pacman is in the right color can it gobble up a token (e.g. an undefined- colored variable token gobbles up a reference)? A More General Conceptualiza?on Variables move around the flow graph in different states Start out in undefined state Can transi?on to defined Will the variable encounter a ref while in undefined state? THINK PACMAN? When Pacman is in the right color can it gobble up a token (e.g. an undefined- colored variable token gobbles up a reference)? What about situa?ons where >2 states is possible? 60

61 Example Property DFSA Property: The elevator always closes its doors before moving Events: open, close, move 0 close move close open 1 open move Assumes the doors are originally closed 2 close, open,move Annotate control flow graph with events close 0 close move close open 1 open move move 2 close, open,move open 61

62 Ini?alizing, Propaga?ng State Informa?on Forward Flow, Any Path Problem IN and OUT are sets of FSA states IN(n) = OUT(m) m pred(n) OUT(n) = δ(s, n) s IN(n) δ is the FSA transi?on func?on In Out Ini?alize OUT(i) =, for all i For the workist algorithm, ini?alize IN(1)=start state Result: Let f be the final node of the flow graph Define Accept(P) to be the set of accep?ng states of a property, P For an All property: want OUT(f) Accept(P) For a None property: want OUT(f) Accept(P) = The Elevator Controller Example void main() { 1: if (elevatorstopped) {... 3: opendoors(); }... 5: if (elevatorstopped) {... 7: closedoors(); } 9: movetonextfloor(); } 1: if 3: open 5: if 7: close 9: move 62

63 Worklist: 3, 5, 7,9 void main() { 1: if (elevatorstopped) {... 3: opendoors(); }... 5: if (elevatorstopped) {... 7: closedoors(); } 9: movetonextfloor(); } Elevator Controller <0> 3: open <1> 7: close <0> 1: if 5: if 9: move close <0,1> move Property <0,2> open close move open close open move State propaga?on Data Flow Analysis Problem - > la ce (P(S),, ) func?on space δ : P(S) P(S) facts at nodes are elements of P(S) Propagate states un?l convergence and check if terminal node in an accep?ng/non- accep?ng state of DFSA 63

64 Example Meet Semila ce values= P({open,close,move})" = { }" T = {open,close,move}" { }" Ordering = " {open}" {close}" {move}" Meet = " {open,close}" {open," move}" {close,move}" {open,close,move}" Verifying OO system method invoca?ons For OO systems, can reason about legal sequences of method invoca?ons Example: Must always check before popping a stack For events {pop, push, not_empty} show that for all paths ((push)*, (not_empty, (- pop)*, pop)* )* (not_empty, (- pop)*)* push pop -pop not_empty Note: Omi ed transi?ons go to trap state 64

65 Quan?ta?ve Proper?es Cause Problems Can not represent #Insert > #Delete N1 deletes, K1 inserts, N2 deletes, k2 inserts, etc. K1 + K2 + > N1 + N2 + But for fixed N, can show that #inserts #deletes insert insert insert insert insert insert N delete delete delete delete delete Dealing with methods foo If bar is a method call and it contains a foo, then must inline the code for bar CFG for bar bar foo foo 65

66 Can reduce the CFG before doing the analysis foo foo foo bar Can remove a node from the graph if it does not have an event associated with it, AND does not affect the flow of events through the graph foo bar Interprocedural Analysis- in- line reduced CFG foo CFG for bar bar foo foo foo2 If foo2 does not call foo or bar, do not need to inline its code 66

67 Advantages of State Propaga?on Data Flow Analysis determines if the property is valid or not Efficient Always terminates Conserva?ve Only validates the property if it is true for all/no possible execu?ons When it can not validate the property, it provides a counter example trace Rela?vely easy to use Do not have to understand how the system works Rela?vely easy to write proper?es Compared to predicate calculus or temporal logic Disadvantages of State Propaga?on Infeasible paths Can not usually express proper?es about compound data values E.g., For all I, A[ I ] > A[I+1] Can not express general ordering rela?onships # Insert > # Delete But, can ensure that every delete is preceded by at least one insert Or, can ensure # Insert > # Delete, for some specific n 67

68 Summary: Using Data Flow Analysis to Verify Proper?es Many interes?ng and important proper?es can be represented as DFSA or regular expressions Can efficiently determine if the property can be violated If it can be violated,can see a trace through the program that causes the viola?on May not correspond to an executable path For OO systems, works well for reasoning about legal sequences of method invoca?ons More DFA and Model Checking Prof. Leon Osterweil CS Fall Semester

69 High- Level Architecture of FSV Systems Property" Property! Translator! System" System! Translator" System Model" Property Representation Reasoning Engine! Property Verified" Counter Examples for Model" System Model Depends on property being verified Eliminate informa?on that does not impact the reasoning To keep the model as small as possible Abstrac?on techniques allow states in the model to be reduced/collapsed Only keep track of the variables that are important to the property Use slicing Abstract values whenever possible x<0, x=0, x>0 But add in informa?on when needed to improve the precision of the reasoning 69

70 Results in Conserva?ve Analysis If property verified, property holds for all possible execu?ons of the system If property not verified: An error found (in the system or in the property) OR A spurious result System model abstracts informa?on to be tractable Conserva?ve abstrac?ons usually over- approximate behavior If inconsistency relies upon over- approxima?ons, then a spurious result e.g. every counterexample corresponds to an infeasible path Recall our Previous Example

71 Produced this Result 1: if 2: open 3: if 5: move 3 Improving Precision Use constraints to improve precision Given a CFG G, a property P, Add constraints C 1,,C n that can be used to avoid propaga?on down infeasible paths Then use DFA to determine whether (L(G) L(C 1 ) L(C n )) L(P) Alphabet refine G wrt (Σ P Σ C1 Σ Cn ) 71

72 Improving Precision Property" Specification" Property! Translator! Constraints"..." Property FSA System" Trace Flow Graph" System! Translator" State Propagation! Property Verified" Counter Example Trace through TFG" Can add constraints incrementally as needed Constraints Are represented as FSAs Describe condi?ons necessary for feasible execu?on Have a special viola4on state that is entered when an infeasible path is detected Viola?on is a trap state; once it is entered, never leave that state 72

73 Boolean Variable Constraint t v Elevator Revisited 1: if 2: S==t 4: S==f 73

74 State Propaga?on State Propaga?on 1 t f 74

75 Model Checking: An Alterna?ve to DFA Proper?es usually expressed in a temporal logic System represented as a (possibly abstracted ) reachability graph State based=>show the values of all the relevant variables Reasoning engine propagates valid subformulas through the graph Model Checking Approach Property" Reachability Graph Property! Translator! Temporal Logic Specification Property Representation System" System! Translator" System Model" Reasoning Engine! Property Verified" Counter Examples for Model" 75

76 Reachability Graph Example task control flow graphs T1 T2 Reachability graph b1 begin b2 begin b1,b2 q T2.Q q Accept Q q,b2 b1,q e1 end e2 end q,q e1,q q,e2 waiting for q? Need to distinguish before a rendezvous from after a rendezvous e1,e2 Temporal Logic Path quan?fiers A, E Temporal quan?fiers Assume p,q are atomic proposi?ons Gp - p is globally true or always true Fp - p holds some?me in the future or eventually Xp- p holds in the next state p U q - p holds un?l q holds p R q - q is released from being true if p is true 76

77 More Familiar Examples The variable defined here is eventually subsequently used It is globally true that door is closed on moving elevator If the elevator stops, the next event is always open If a file is opened then it is always eventually closed Propaga?ng Proposi?ons: AFp F p - at some?me in the future, p is true AF p AF p p AF p p AF p p To propagate AF p: Mark nodes where p is true with AF p If all of a node s successors are marked with AF p, mark that node Repeat Step 2 un?l a fixed point is reached 77

78 Propaga?on rules Different rule for each formula type A property is true for a graph if it holds in the ini?al node(s) Need a reachability graph that shows the states (i.e., the values) of the relevant variables Example: process 1 can be null, trying to obtain the lock, or in its cri?cal region (n1, t1, c1) process 2 can be null, trying to obtain the lock, or in its cri?cal region (n2, t2, c2) turn is a variable that indicates which process can obtain the lock (0,1,2) Concurrent systems are complex Non- determinism means that the same inputs might produce different outputs on different execu?ons When reasoning about a system there are numerous alterna?ves to consider Usually more than a human can reasonably consider In addi?on to the problems that can arise with sequen?al programs, have problems that are unique to concurrent systems Data access problems Synchroniza?on problems 78

79 Data Access Anomalies Typically you want mutual exclusion shared resource (e.g., data) that should only have a single access at a?me e.g., don t want two travel agents assigning the last seat on a plane Typically you don t want race condi?ons order of execu?on affects results undesirable nondeterminism task A!!task B! x := x + 1;!x := x - 1;! write x;!!write x;! if initially x =5, then could output (6, 5), (4, 5), or (5, 5) Interleaved Model of Execu?on; Examples task A! x := x + 1;! write x;!! task B! x := x - 1;! write x;! task B! x := x - 1;! write x;! task A x := x + 1; write x;!! task B x := x - 1; task A x := x + 1; write x;!! write x;! task A! task B! x := x + 1;! x := x - 1;! write x;!! write x;! 79

80 Synchroniza?on Problems: Infinite wait anomalies Starva?on At least one task does not make progress on a aining a goal May con?nue to execute repeat select when not_ready clean- up; or when ready accept Goal; end select; un?l forever; Infinite wait anomalies (con?nued) Deadlock set of tasks mutually wai?ng on each other; none can advance Ooen tasks hold resources that other tasks need Also called, deadly embrace dining philosophers problem Livelock execu?on does not come to a stands?ll but none of the tasks can advance 80

81 Deadlock handling has been inves?gated extensively Deadlock preven?on techniques preassign all resources before beginning a task if all resources are not available, then assign none less efficient use of resources since not all may be needed at once preempt a process that holds a needed resource But, not all resources can be preempted Sta?c analysis Concurrent & distributed systems are inherently more difficult to analyze Alias resolu?on in addi?on to array references and pointers, can have dynamically allocated tasks e.g., Accept T.i Path feasibility inconsistent path condi?ons infeasible synchroniza?on a" a " a" a " 81

82 Sta?c analysis approaches for concurrent systems Specifica?on approaches Quan?fied regular expressions Determinis?c Finite State Automata Temporal logics - - an extension to classical logic that supports statements about sequences and?me Reachability graphs and reachability analysis Petri nets and Petri net based analysis Finite- State Verifica?on Data- flow analysis Extended to distributed systems Model checking Flow equa?ons represent necessary condi?ons for all or some program execu?ons Concurrency Analysis Using Reachability Graphs, Temporal Logic and Model Checking Computer Science Fall 2011 Prof. L. J. Osterweil Material adapted from slides originally prepared by Prof. L. A. Clarke 82

83 Use a worklist to build the reachability graph task control flow graphs T1 T2 Reachability graph b1 begin b2 begin b1,b2 q T2.Q q Accept Q b_q,b2 b1,b_q e1 end e2 end r(q, q ) Worklist: <b1,b2> <b_q,b2> <b1,b_q > <r(q,q )> <e1,q ><q,e2> <e1,e2> e1, q e1,e2 q,e2 Useful in determining possible/ impossible synchroniza?ons begin begin" T2.Q " Accept Q" T1" T2" begin begin" T2.Q" T2.Q " Accept Q" T2.Q" Accept Q" end end" Infeasible synchroniza?ons end end" Infeasible synchroniza?on?? 83