Problem Sheet 9: Software Model Checking Sample Solutions

Size: px

Start display at page:

Download "Problem Sheet 9: Software Model Checking Sample Solutions"

Peregrine O’Neal’
8 years ago
Views:

1 Problem Sheet 9: Software Model Checking Sample Solutions Chris Poskitt ETH Zürich 1 Predicate Abstraction i. Let us first visualise c and not c in a Venn diagram: not c c P red(not c) gives the weakest under-approximation of not c. In other words, P red(not c) implies not c, but not (in general) the converse. A possible visualisation in a Venn diagram might then be: Pred(not c) c In negating P red(not c), we then get the strongest over-approximation, visualised as follows: Pred(not c) c not Pred(not c) Some exercises adapted from ones written by Stephan van Staden and Carlo A. Furia. 1

2 ii. We build a Boolean abstraction from C 1, one line at a time. First, we over-approximate assume x > 0 with assume P red( x > 0), followed by a parallel conditional assignment updating the predicates with respect to the original assume statement. P red( x > 0) = ( p) Hence we add assume p to A 1. This should be followed by a parallel conditional assignment (as described in the slides): if Pred(+ex(i)) then p(i) := True if Pred(-ex(i)) then p(i) := False p :=? Using the axiom {c post} assume c {post} for the weakest precondition of assume statements, we compute every +/ ex(i) for predicates i: = p +ex(p) = (x > 0 x > 0) ex(p) = (x > 0 x > 0) +ex(q) = (x > 0 y > 0) ex(q) = (x > 0 y > 0) +ex(r) = (x > 0 z > 0) ex(r) = (x > 0 z > 0) We apply the simplification step from the slides, and omit each P red(ex(i)) that is not unconditionally valid. It so happens that only: P red(+ex(p)) = P red(x > 0 x > 0) = P red(true) = true is valid, hence the parallel conditional assignment reduces to simply: if True then p :=? This reduces even further to, which we add to A 1. 2

3 Next, we address the assignment z := (x y) + 1. Recall that an assignment x := f is over-approximated by a parallel conditional assignment: if Pred(+f(i)) then p(i) := True if Pred(-f(i)) then p(i) := False p :=? Using the axiom {post[f/x]} x := f {post} and the definition of +/ f(i) for predicates i, we get: P red(+f(p)) = P red(x > 0) = p P red( f(p)) = P red( x > 0) = p P red(+f(q)) = P red(y > 0) = q P red( f(q)) = P red( y > 0) = q P red(+f(r)) = P red((x y) + 1 > 0) = (p q) ( p q) P red( f(r)) = P red( (x y) + 1 > 0) = P red((x y) + 1 0) = false The parallel conditional assignments for p, q have no effect, hence we add only the following to A 1 : if (p and q) or (not p and not q) then r := True if False then r := False Finally, we address the assertion assert z >= 1. The Boolean abstraction is simply assert P red(z 1). We have: and hence add assert r to A 1. P red(z 1) = r 3

4 Altogether, A 1 is the following program: assume p if (p and q) or (not p and not q) then r := True if False then r := False assert r With a further simplification, we get: assume p if (p and q) or (not p and not q) then r := True assert r 4

5 iii. (a) After normalising the program (following the details in the slides) we get: assume x > 0 y := x + x assume x <= 0 assume x = 0 y := 1 assume x /= 0 y := x * x assert y > 0 (b) To build A 2 from the normalised code above, apply the transformations to each assignment, assume, and assert, analogously to how I did when constructing A 1 (except that this time you only have two predicates, p and q). The resulting abstraction (after some simplifications) should be equivalent to this: assume p q := True assume not p p := False assume not p p := False q := True assume True -- can delete this assume q :=? assert q 5

6 2 Error Traces i. An abstract error trace is: [p, not q, r] assume p [p, not q, r] [p, not q, r] [p, not q, not r] assert r Observe that each concrete instruction corresponds to a (compound) abstract instruction. We can check whether or not this is a feasible concrete run by computing the weakest precondition of the concrete instructions with respect to p q r, interpreting conditions (assume, conditionals, or exit conditions) as asserts: {x > 0 and y <= 0 and (x*y)+1 <= 0} {(x > 0 and y <= 0 and (x*y)+1 <= 0) and x > 0} assert x > 0 {x > 0 and y <= 0 and (x*y)+1 <= 0} z := (x*y) + 1 {x > 0 and y <= 0 and z <= 0} [p, not q, not r] Executing the concrete program on a state s such that s = x > 0 y 0 (x y) will reveal the fault. One possible input state (of many) is s = {x 3, y 2, z }. ii. Here is an abstract counterexample trace: assume not p p := False assume True q :=? assert q As before, we check whether or not this abstract execution reflects a feasible, concrete counterexample, by computing the weakest precondition of the corresponding concrete instructions with respect to p q. Again, we interpret conditions (assume in this case) as asserts, and apply the corresponding Hoare logic axioms: 6

7 {x < 0 and x*x <= 0} {x <= 0 and x /= 0 and x <= 0 and x*x <= 0} assert x <= 0 {x /= 0 and x <= 0 and x*x <= 0} assert x /= 0 {x <= 0 and x*x <= 0} y := x*x {x <= 0 and y <= 0} Observe that in this case, the weakest precondition we have constructed is equivalent to false. There is no assignment to x that will satisfy the assertion. Hence the abstract counterexample is infeasible (spurious) in the concrete program; abstraction refinement is needed. 7

Static Program Transformations for Efficient Software Model Checking

Static Program Transformations for Efficient Software Model Checking Shobha Vasudevan Jacob Abraham The University of Texas at Austin Dependable Systems Large and complex systems Software faults are major