Abstraction Refinement of Linear Programs with Arrays

Abstract

Abstract. In previous work we presented a model checking procedure for linear programs, i.e. programs in which variables range over a numeric domain and expressions involve linear combinations of the variables. In this paper we lift our model checking procedure for linear programs to deal with arrays via iterative abstraction refinement. While most approaches are based on predicate abstraction and therefore the abstraction is relative to sets of predicates, in our approach the abstraction is relative to sets of variables and array indexes, and the abstract program can express complex correlations between program variables and array elements. Thus, while arrays are problematic for most of the approaches based on predicate abstraction, our approach treats them in a precise way. This is an important feature as arrays are ubiquitous in programming. We provide a detailed account of both the abstraction and the refinement processes, discuss their implementation in the eureka tool, and present experimental results that confirm the effectiveness of our approach on a number of programs of interest.

Augmenting Counterexample-Guided Abstraction Refinement with Proof Templates

“…Augmenting SMCs with looping counterexamples [12], [13], or concrete execution [14] enables efficient falsification rather than verification. Replacing boolean programs with linear programs enables some problems involving array traversal to be solved efficiently, but sacrifices completeness of the SMC's modelchecking phase [15]. Using a split prover [16] for refinement ensures eventual convergence if a proof of safety exists within difference logic, but does not guarantee that the proof is efficient, and can drastically increase the number of predicates used if a predicate with a large difference bound is needed.…”

CPBPV: a constraint-programming framework for bounded program verification

“…The initial constraint store of the CPBPV verifier, assuming an input array of length 8, is the precondition 3 …”

“…Since l 0 ≤ u 0 , the execution enters the loop body, adds the constraint m 0 = (l 0 + u 0 )/2, which simplifies to m 0 = 3 (3.5 is rounded down to the integer 3, since / is the division on integers), and considers the conditional statement on lines 6-7. The execution of the statement is nondeterministic: Indeed, both t 0 [3] = v 0 and t 0 [3] = v 0 are consistent with the constraint store, and thus the two alternatives, which give rise to two execution paths, must be explored. Note that these two alternatives correspond to actual execution paths in which t [3] in the input is equal to, or different from, input v. The first alternative adds the constraint t 0 [3] = v 0 to the store and executes line 7, which adds the constraint result = m 0 .…”

“…The execution of the statement is nondeterministic: Indeed, both t 0 [3] = v 0 and t 0 [3] = v 0 are consistent with the constraint store, and thus the two alternatives, which give rise to two execution paths, must be explored. Note that these two alternatives correspond to actual execution paths in which t [3] in the input is equal to, or different from, input v. The first alternative adds the constraint t 0 [3] = v 0 to the store and executes line 7, which adds the constraint result = m 0 . CPBPV has thus obtained a complete execution path p whose final constraint store c p is:…”

“…First, contrary to earlier work using model checking or constraint programming [3,16,17], CPBPV does not use predicate abstraction or abstraction refinement techniques. As a consequence, it does not explore spurious execution paths, i.e., paths that do not correspond to actual executions over inputs satisfying the pre-condition.…”