Lazy abstraction

Abstract

One approach to model checking software is based on the abstract-check-refine paradigm: build an abstract model, then check the desired property, and if the check fails, refine the model and start over. We introduce the concept of lazy abstraction to integrate and optimize the three phases of the abstract-cheek-refine loop. Lazy abstraction continuously builds and refines a single abstract model on demand, driven by the model checker, so that different parts of the model may exhibit different degrees of precision, namely just enough to verify the desired property. We present an algorithm for model checking safety properties using lazy abstraction and describe an implementation of the algorithm applied to C programs. We also provide sufficient conditions for the termination of the method.One traditional flow for model checking a piece of code proceeds through the following loop [5, 10, 28]:Step i ("abstraction") A finite set of predicates is chosen, and an abstract model of the given program is built automatically as a finite or push-down automaton whose states represent truth assignments for the chosen predicates.Step 2 ("verification") The abstract model is checked automatically for the desired property. If the abstract model is error-free, then so is the original program (return "program correct"); otherwise, an abstract eounterexample is produced automatically which demonstrates how the model violates the property.Step 3 ("counterexample-driven refinement") It is checked automatically if the abstract eounterexample corresponds to a concrete eounterexample in the original program. If so, then a program error has been found (return "program incorrect"); otherwise, the chosen set of predicates does not contain enough information for proving program correctness and new predicates must be added. The selection of such predicates is automated, or at least guided, by the failure to concretize the abstract counterexample [i0]. Goto Step i.The problem with this approach is of course that both Step 1 and Step 2 are eomputationally hard problems, and without additional optimizations, the method does not scale to large systems. We believe that in order to evaluate the full promise of this approach, the loop from abstraction to verification to refinement should be short-circuited. We show that all three steps can be integrated tightly through a concept we call "lazy abstraction," and that this integration can offer significant advantages in performance, by avoiding the repetition of work from one iteration of the loop to the next.Intuitively, lazy abstraction proceeds as follows. In Step 3, call the abstract state in which the abstract eounterexample fails to have a concrete counterpart, the pivot state. The pivot state suggests which predicates should be used to refine the abstract model. However, instead of building an entire new abstract model, we refine the current abstract model "from the pivot state on." Since the abstract model may

Typestate Verification: Abstraction Techniques and Complexity Results

“…Several recent verification approaches [2,15], based on predicate abstraction [14], avoid imprecision (e.g., due to aliasing or infeasible paths) by iteratively refining the abstractions as necessary, but are fundamentally exponential algorithms. These techniques use symbolic and theorem-proving techniques (during verification) to identify a set P of "relevant" predicates, and then use the powerset lattice 2 P →{true,f alse} for abstraction, and then model check the resulting finite state system (and usually iterate with increasingly larger sets of predicates until a satisfactory result is obtained).…”

Analyzing Loop Paths for Execution Time Estimation

“…see [11]). These works search through an abstract model of the program to generate a counter-example trace and then show that the given counter-example trace is an infeasible path in the program's control flow graph.…”

Verifying Concurrent Message-Passing C Programs with Recursive Calls

“…CEGAR-based predicate-abstraction techniques are used in several C-program model-checking tools, such as SLAM [12], BLAST [13], ZING [27], and KISS [24]. However, as mentioned previously, SLAM cannot deal with concurrency, BLAST cannot handle recursion, and KISS cannot discover errors that appear after a number of interleavings between the parallel components greater than three.…”

“…This schema has been successfully applied to handle both pure non-concurrent (sequential) recursive programs in the tool SLAM [12], and concurrent non-recursive programs in the tools BLAST [13] and MAGIC [14].…”