Under-approximating loops in C programs for fast counterexample detection

Many software model checkers only detect counterexamples with deep loops after exploring numerous spurious and increasingly longer counterexamples. We propose a technique that aims at eliminating this weakness by constructing auxiliary paths that represent the effect of a range of loop iterations. Unlike acceleration, which captures the exact effect of arbitrarily many loop iterations, these auxiliary paths may under-approximate the behaviour of the loops. In return, the approximation is sound with respect to the bit-vector semantics of programs. Our approach supports arbitrary conditions and assignments to arrays in the loop body, but may as a result introduce quantified conditionals. To reduce the resulting performance penalty, we present two quantifier elimination techniques specially geared towards our application. Loop under-approximation can be combined with a broad range of verification techniques. We paired our techniques with lazy abstraction and bounded model checking, and evaluated the resulting tool on a number of buffer overflow benchmarks, demonstrating its ability to efficiently detect deep counterexamples in C programs that manipulate arrays.


Introduction
The generation of diagnostic counterexamples is a key feature of model checking. Counterexamples serve as witness for the refutation of a property, and are an invaluable aid to the engineer for understanding and repairing the fault.
Counterexamples are particularly important in software model checking, as bugs in software frequently require thousands of transitions to be executed, and are thus difficult to reproduce without the help of an explicit error trace. Existing software model checkers, how-ever, fail to scale when analysing programs with bugs that involve many iterations of a loop. The primary reason for the inability of many existing tools to discover such "deep" bugs is that exploration is performed in a breadth-first fashion: the detection of an unsafe execution traversing a loop involves the repeated refutation of increasingly longer spurious counterexamples. The analyser first considers a potential error trace with one loop iteration, only to discover that this trace is infeasible. As consequence, the analyser will increase the search depth, usually by considering one further loop iteration. In practice, the computational effort required to discover an assertion violation thus grows exponentially with the depth of the bug.
Notably, the problem is not limited to procedures based on abstraction, such as predicate abstraction or abstraction with interpolants. Bounded model checking (BMC) is optimised for discovering bugs up to a given depth k, but the computational cost grows exponentially in k.
The contribution of this paper is a new technique that enables scalable detection of deep bugs. We transform the program by adding a new, auxiliary path to loops that summarises the effect of a parametric number of iterations of the loop. Similar to acceleration, which captures the exact effect of arbitrarily many iterations of an integer relation by computing its reflexive transitive closure in one step [4,8,11], we construct a summary of the behaviour of the loop. By symbolically bounding the number of iterations, we obtain an under-approximation which is sound with respect to the bit-vector semantics of programs. Thus, we avoid false alarms that might be triggered by modeling variables as integers.
In contrast to related work, our technique supports assignments to arrays and arbitrary conditional branching by computing quantified conditionals. As the computational cost of analysing programs with quantifiers is high, we introduce two novel techniques for summarising certain conditionals without quantifiers. The key insight is that many conditionals in programs (e.g., loop exit conditions such as i ≤ 100 or even i = 100) exhibit a certain monotonicity property that allows us to drop quantifiers.
Our approximation can be combined soundly with a broad range of verification engines, including predicate abstraction, lazy abstraction with interpolation [19], and bounded software model checking [5]. To demonstrate this versatility, we combined our technique with lazy abstraction and the Cbmc [5] model checker. We evaluated the resulting tool on a large suite of benchmarks known to contain deep paths, demonstrating our ability to efficiently detect deep counterexamples in C programs that manipulate arrays.

Notation and preliminaries
We restrict our presentation to a simple imperative language comprising assignments, assumptions, and assertions. A program is a control flow graph V, E, λ , where V and E are sets of vertices and edges, respectively, and λ is a labelling function mapping vertices to statements. Procedure calls are in-lined and omitted in our presentation. The behaviour of a program is defined by the paths in the control flow graph (CFG). A path π of length m is a sequence of contiguous edges e 1 e 2 . . . e m (e i ∈ E, 1 ≤ i ≤ m). Abusing our notation, we use the corresponding sequence of statements λ(e 1 ); λ(e 1 ); . . . λ(e m ) to represent paths (where ; denotes the non-commutative path concatenation operator). We use ε to denote the path of length 0 and inductively define π n as π 0 = ε and π n+1 = π n ; π (for n ≥ 0). In accordance with [20], π 1 π 2 represents the non-deterministic choice between two paths, i.e., π1 π2 . The commutative operator is extended to sets of paths in the usual manner. Table 1 Predicate transformers for simple program statements and paths   Path Strongest postcondition Weakest liberal precondition π sp(π, P) w lp (π, Q) We use first-order logic (defined as usual) with background theories commonly used in software verification (such as arithmetic, bit-vectors, arrays and uninterpreted functions) to represent program expressions and predicates. T (F) represents the predicate that is always true (false). We use * to indicate non-deterministic values. The semantics for statements and paths is determined by the predicate transformers in Table 1 (see [20]). A Hoare triple {P} π {Q} comprises a pre-condition P, a path π, and a post-condition Q such that sp(π, P) implies Q. Given a set X = {x 1 , . . . , x k } of k variables, we introduce corresponding sets X = { x 1 , . . . , x k } and X = {x 1 , . . . , x k } of primed variables to refer to variables in prior and subsequent time-frames, respectively (where the term time-frame refers to an instance of π in π n ). We use X i = {x i 1 , . . . , x i k } to refer to the variables in a specific time-frame i. The transition relation of π is the predicate ¬wlp π, k i=1 x i = x i [20] and relates variables of two time frames (for example, for k = 2 and the path π = [x 1 < 0];

A motivating example
A common characteristic of many contemporary symbolic software model checking techniques (such as counterexample-guided abstraction refinement with predicate abstraction [1,10], lazy abstraction with interpolants [19], and bounded model checking [5]) is that the computational effort required to discover an assertion violation may increase exponentially with the length of the corresponding counterexample path (c.f. [16]). In particular, the detection of assertion violations that require a large number of loop iterations results in the enumeration of increasingly longer spurious counterexamples traversing that loop. This problem is illustrated by the following example. Figure 1 shows a program fragment derived from code permitting a buffer overflow (detected by the assertion) to occur in the nth iteration of the loop if i reaches (BUFLEN − 1) and the branch [ch = ] is taken in the (n − 1)th iteration. The verification techniques mentioned above explore the paths in order of increasing length. The shortest path that reaches the assertion does not violate it, as In a predicate abstraction or lazy abstraction framework, this path represents the first in a series of spurious counterexamples of increasing length. Let π denote the path empha-   Fig. 1, which traverses the loop once. The verification tool will generate a family of spurious counterexamples with the prefixes i := 0; π n (where 0 < n ≤ BUFLEN 2 ) before it detects a path long enough to violate the assertion. Each of these paths triggers a computationally expensive refinement cycle. Similarly, a bounded model checker will fail to detect a counterexample unless the loop bound is increased to BUFLEN 2 + 1.

Example 1
The iterative exploration of increasingly deeper loops primarily delays the detection of assertion violations (c.f. [16]), but can also result in a diverging series of interpolants and predicates if the program is safe (see [12]).

Approximating paths with loops
We propose a technique that aims at avoiding the enumeration of paths with an insufficient number of loop iterations. Our approach is based on the insight that the refutation of spurious counterexamples containing a sub-path of the form π n is futile if there exists an n large enough to permit an assertion violation. We add an auxiliary path that bypasses the original loop body and represents the effect of π n for a range of n (detailed later in the paper). Our approach comprises the following steps: 1. We sensitise an existing tool to detect paths π that repeatedly traverse the loop body B (as illustrated in the left half of Fig. 2). We emphasise that π may span more than one iteration of the loop, and that the branches of B taken by π in different iterations may vary. 2. We construct a path π whose behaviour under-approximates {π n | n ≥ 0}. This construction does not correspond to acceleration in a strict sense, since π (as an underapproximation) does not necessarily represent an arbitrary number of loop iterations. Section 3 describes techniques to derive π .
Detect path π that repeatedly traverses the loop body B Augment loop body with a branch containing the approximation π 3. By construction, the assumptions in π may contain universal quantifiers ranging over an auxiliary variable which encodes the number of loop iterations. In Sect. 4, we discuss two cases in which (some of) these quantifiers can be eliminated, namely (a) if the characteristic function of the predicate ¬wlp (π n , F) is monotonic in the number of loop iterations n, or (b) if π n modifies an array and the indices of the modified array elements can be characterised by means of a quantifier-free predicate. We show that in certain cases condition (a) can be met by splitting π into several separate paths. 4. We augment the control flow graph with an additional branch of the loop containing π (Fig. 2, right). Section 5 demonstrates empirically how this program transformation can accelerate the detection of bugs that require a large number of loop iterations.
The following example demonstrates how our technique accelerates the detection of the buffer overflow of Example 1.
Example 2 Assume that the verification tool encounters the node u in Fig. 1 a second time during the exploration of a path (u is the head of a natural loop with back-edge v → u). We conclude that there exists a family of (sub-)paths π n induced by the number n of loop iterations. The repeated application of the strongest post-condition to the parametrised path π n for an increasing n gives rise to a recurrence equation i n = i n−1 + 1 (for clarity, we work on a sliced path omitting statements referring to ch): where i n in the last line represents i after the execution of π n . This recurrence equation can be put into its equivalent closed form i n = i 0 + n. By assigning n a (positive) non-deterministic value, we obtain the approximation (which happens to be exact in this case): Let us ignore arithmetic over-or under-flow for the time being (this topic is addressed in Sect. 3.4). We can then observe the following: if the predicate i + j < BUFLEN is true for j = n − 1, then it must be true for any j < n − 1, i.e., the characteristic function of the predicate is monotonic in its parameter j. It is therefore possible to eliminate the universal quantifier and replace the assumption in π with (i + (n − 1) < BUFLEN). The dashed path in Fig. 1 illustrates the corresponding modification of the original program. The resulting transformed program permits the violation of the assertion in the original loop body after a single iteration of π (corresponding to BUFLEN-1 iterations of π).
The following presents techniques to compute the under-approximation π .

Under-approximation techniques
This section covers techniques to compute under-approximations π of {π n | n ≥ 0} such that π is a condensation of the CFG fragment to the right. Formally, we only require that sp( π , P) ⇒ ∃n ∈ N . sp(π n , P) for all P.
The construction of π has two aspects. Firstly, we need to make sure that all variables modified in π are assigned values consistent with π n for a non-deterministic choice of n. Secondly, π must only allow choices of n for which ¬wlp (π n , F) is satisfiable, i.e., the corresponding path π n must be feasible.
Our approximation technique is based on the observation that the sequence of assignments in π n to a variable x ∈ X corresponds to a recurrence equation (c.f. Example 2). The goal is to derive an equivalent closed form x := f x (X, n). While there is a range of techniques to solve recurrence equations, we argue that it is sufficient to consider closed-form solutions that have the form of low-degree polynomials. The underlying argument is that a super-polynomial growth of variable values typically leads to an arithmetic overflow after a small number of iterations, which can be detected at low depth using conventional techniques.
The following sub-section focuses on deriving closed forms from a sequence of assignments to scalar integer variables, leaving conditionals aside. Section 3.2 covers assignments to arrays. Conditionals and path feasibility are addressed in Sect. 3.3. Section 3.4 addresses bit-vector semantics and arithmetic overflow.

Syntactic matching
A simple technique to derive closed forms is to check whether the given recurrence equation matches a pre-determined format. In our work on loop detection for predicate abstraction [16,17], we apply the following scheme: where n > 0 and α, β, and γ are numeric constants or loop-invariant symbolic expressions and x is the variant. This technique is computationally cheap and sufficient to construct the closed form i n = i 0 + n of the recurrence equation i n = i n−1 + 1 derived from the assignment i := i + 1 in Example 2.

Constraint-based acceleration
The disadvantage of a syntax-based approach is that it is limited to assignments following a simple pattern. Moreover, the technique is contingent on the syntax of the program fragment and may therefore fail even if there exists an appropriate polynomial representing the given assignments. In this section, we present an alternative technique that relies on a constraint solver to identify the coefficients of the polynomial f x . Let X be the set {x 1 , . . . , x k } of variables in π. (In the following, we omit the braces {} if clear from the context.) As previously, we start with the assumption that for each variable x modified in π, there is a low-degree polynomial in n (2) over the initial variables x 0 1 , . . . , x 0 k which accurately represents the value assigned to x in π n (for n ≥ 1). In other words, for each variable x ∈ X modified in π, we assume that the following Hoare triple is valid: For each x ∈ {x 1 , . . . , x k } we can generate 2 · k + 2 distinct assignments to x 0 1 , . . . , x 0 k , and n in (2) which determine a system of linearly independent equations over α i , 0 < i ≤ 2 · k + 2. If a solution to this system of equations exists, it uniquely determines the parameters α 1 , . . . , α 2·k+2 of the polynomial f x for x. We will now examine the details of this construction and prove that it allows us to generate polynomial closed forms.

Lemma 1 A set of vectors
Proof Let Y = {y 1 , . . . , y m } be the projection of X onto W. Assume for contradiction that X is linearly dependent, then there is a set of scalars a 1 , . . . , a n such that i a i x i = 0. But when we project onto W we have i a i y i = 0, contradicting the assumption that Y is linearly independent.

Theorem 1
We can uniquely determine the coefficients for a polynomial over k variables by evaluating the loop at 2k + 2 points with n ≤ 2.
Proof Our polynomial is of the form There are 2 · k + 2 undetermined coefficients α i (1 ≤ i ≤ 2k + 2) that we need to find. We need to generate a system of 2k + 2 linearly independent equations to uniquely fix these coefficients. This is equivalent to finding a set of 2k + 2 vectors We generate this set inductively.
Basis For k = 1, the set generated by is which is linearly independent.
Induction Assume we have a linearly independent set of 2 · k + 2 equations for k variables. We can extend the vectors by setting x k+1 = 0 in the vectors with n = 0 and n = 1, and by setting x k+1 = 1 in the vector with n = 2. By Lemma 1 this maintains linear independence.
Subsequently, we add two new vectors generated by The resulting 2 · k + 4 vectors are still linearly independent, which can be seen by projecting onto the space (x k+1 , x k+1 · n, n, n 2 )-the only way to generate the 0 vector is by taking combinations of vectors all of which have x k+1 = 0. But that set is a subset of the 2 · k + 2 equations we started with, which are linearly independent, and so the extended set is also linearly independent by Lemma 1. So we have 2 · k + 4 = 2 · (k + 1) + 2 linearly independent vectors and the induction is complete.
In particular, the satisfiability of the encoding from which we derive the assignments guarantees that (3) holds for 0 ≤ n ≤ 2. For larger values of n, we check the validity of (3) with respect to each f x by means of induction. The validity of (3) follows (by induction over the length of the path π n ) from the validity of the base case established above, the formula (4) given below (which can be easily checked using a model checker or a constraint solver), and Hoare's rule of composition: If for one or more x ∈ {x 1 , . . . , x k } our technique fails to find valid parameters α 1 , . . . , α 2·k+2 , or the validity check for f x fails, we do not construct π .
Remark The construction of under-approximations is not limited to the two techniques discussed above and can be based on other (and potentially more powerful) recurrence solvers. that are commonly applied in compiler construction [23] and in the context of invariant generation (see [14], for instance). While techniques such as [7] support a larger class of recurrence equations, our approach suffices cover the most common cases like linear counters. Given that we restrict acceleration to intervals in which overflows can be ruled out (see Sect. 3.4), there is no necessity to handle loop counters that increase exponentially, as these cases can be handled efficiently by traditional unwinding.

Assignments to arrays
Buffer overflows constitute a prominent class of safety violations that require a large number of loop iterations to surface. In C programs, buffers and strings are typically implemented using arrays. Let i be the variant of a loop which contains an assignment a[i]:=e to an array a. For a single iteration, we obtain Assume further that closed forms for the variant i and the expression e exist (abusing our notation, we use f e to refer to the latter). Given an initial pre-condition P = T, we obtain the following under-approximation after n iterations: where the domain (dom a) of a denotes the valid indices of the array. Condition (6) underapproximates the strongest post-condition, since there may exist j 1 , j 2 ∈ [0, n) such that (6) is unsatisfiable. A similar situation arises if a loop body π contains multiple updates of the same array.
Notably, the membership test determining whether an array element is modified or not introduces quantifier alternation, posing a challenge to contemporary decision procedures. Section 4 addresses the elimination of the existential quantifier.

Assumptions and feasibility of paths
The techniques discussed in Sect. 3.1 yield polynomials and constraints representing the assignment statements of π n , but leave aside the conditional statements which determine the feasibility of the path. In order to guarantee that only states that are reachable in the original program can be reached via accelerated paths, we need to make sure that π is only feasible for values of n for which π n is also feasible. We achieve this by computing a pre-condition for π that rules out values of n for which π n is not feasible. In the following, we demonstrate how to derive such a pre-condition ¬wlp (π n , F) using the polynomials f x for x ∈ X. n)] denote the simultaneous substitution of all free occurrences of the variables x ∈ X in Q with the corresponding term f x (X, n). Accordingly, given a path π modifying the set of variables X and a corresponding set f X of closed-form assignments, we can construct an accurate representation of π n as follows: The construction of ¬wlp (π n , F) is based on the following lemma:

Lemma 2
The following equivalence holds: Proof Intuitively, the path π n is infeasible if for any j < n the first time-frame of the suffix π (n− j) is infeasible. We prove the claim by induction over n. Due to (3) and (4) we have f X (X, 0) = X and f X ( f X (X, n), 1) = f X (X, n + 1) (for n ≥ 0).

Induction step
We start by applying the induction hypothesis: We consider the effect of assignments and assumptions occurring in π on the post- -The effect of assignments in π on Q is characterised by Q[X/ f X (X, 1)]. We obtain: -Assumptions in π contribute the disjunct wlp (π, F).

By combining both contributions into one term we obtain
which establishes the claim of Lemma 2.
We emphasise that our construction (unlike many acceleration techniques such as [11]) does not restrict the assumptions in π to a limited class of relations on integers. The construction of the path (7), however, does require closed forms of all assignments in π. Since we do not construct closed forms for array assignments (as opposed to assignments to array indices, c.f. Sect. 3.2), we cannot apply Lemma 2 if wlp (π, F) refers to an array assigned in π. In this case, we do not construct π .
For assignments of variables not occurring in wlp (π, F), we augment the domain(s) of the variables X with an undefined value ⊥ (implemented using a Boolean flag) and replace f x with ⊥ whenever the respective closed form is not available. Subsequently, whenever the search algorithm encounters an (abstract) counterexample, we use slicing to determine whether the feasibility of the counterexample depends on an undefined value ⊥. If this is the case, the counterexample needs to be dismissed. Thus, any path π containing references to ⊥ is an under-approximation of π n rather than an acceleration of π.

Arithmetic overflows
The fact that the techniques in Sect. 3.1 used to derive closed forms do not take arithmetic overflow into account may lead to undesired effects. For instance, the assumption made in Example 2 that the characteristic function of the predicate (i + n < BUFLEN) is monotonic in n does not hold in the context of bit-vectors or modular arithmetic. Since, moreover, the behaviour of arithmetic over-or under-flow in C is not specified in certain cases, we conservatively rule out all occurrences thereof in π . For the simple assignment i := i + n in Example 2, this can be achieved by adding the assumption (i + n ≤ 2 l − 1) to π (for unsigned l-bit vectors). In general, we have to add respective assumptions (e 1 ⊗ e 2 ≤ 2 l − 1) for all arithmetic (sub-)expressions e 1 ⊗ e 2 of bit-width l and operations ⊗ in π .
While this approach is sound (eliminating paths from π does not affect the correctness of the instrumented program, since all behaviours following an overflow are still reachable via non-approximated paths), it imposes restrictions on the range of n. Therefore, the resulting approximation π deviates from the acceleration π * of π. Unlike acceleration over linear affine relations, this adjustment makes our approach bit-level accurate. We emphasise that the benefit of the instrumentation can still be substantial, since the number of iterations required to trigger an arithmetic overflow is typically large.

Path selection
In the following, we discuss heuristics to select paths π to accelerate. Depending on which model checking technique we are incorporating acceleration into, several path selection strategies are available. Some model checkers already come equipped with a strategy for enumerating paths, for example Impact [19] enumerates paths by iteratively unrolling the CFG of the program under analysis. During this process, if a path is found to be "looping" (i.e. some program location is visited repeatedly) then that path is a candidate for acceleration. By contrast, if we use a model check technique that is not explicitly path based (such as bounded model checking), we must devise a strategy for selecting paths to accelerate.
A necessary condition for π to be acceleratable is that π 2 is feasible, for if it were not, π n (for n > 1) would be infeasible, resulting in a trivial accelerator. Accordingly, paths π for which π 2 is feasible are promising candidates for acceleration. We can find such paths by using symbolic execution to build a system of constraints and solving the system with a SAT solver. Our encoding guarantees that if these constraints have a solution, the solution includes a path π where π 2 is feasible. Our encoding can be easily generalised and applied to paths π k with a higher number k of iterations, though this results in a higher computational effort. In practice, choosing k = 2 results in a reliable predictor that enables us to identify candidates efficiently.
Let L denote the program fragment denoting the loop body. We instrument L with "distinguisher" and "shadow distinguisher" variables, which indicate which branches are taken. Concretely, for each statement π i π j in L we create boolean variables d i , s i , d j , and s j . We create the instrumented program Instr(L) by prepending the statement d i := false, appending the statement assume(d i = s i ), and then replacing the statement π i π j with (d i := true; π i ) (d j := true; π j ) Instr(L) has the property that when it has finished executing, each of the d i will be true iff the corresponding branch was taken. Furthermore, we have d i = s i for each i. We now sequentially compose two copies of this instrumented program: We assume that the s i are initialised non-deterministically at the beginning of this program fragment. An example of this construction is shown in Fig. 3.
Since each of the distinguisher variables d i is equal to the shadow distinguisher s i at the end of each copy of Instr(L), we know that the only feasible paths through this program are those in which both copies took the same path. This path is identified by the values of the s i . So if there are any feasible paths through this program, they identify a path π such that π 2 in the original program is feasible. We can identify a feasible path through this program by appending the statement assert(false) to the end of the program and using a BMC-based model checker (which ultimately creates a SAT/SMT instance) to check the (assume(x > 0); x := x-1) (assume(x < 0) ; x := x+1) (d 1 := false; d 2 := false); (d 1 := true; assume(x > 0); x := x-1) (d 2 := true; assume(x < 0) ; x := x+1); (assume(d 1 = s 1 ); assume(d 2 = s 2 )); (d 1 := false; d 2 := false); (d 1 := true; assume(x > 0); x := x-1) (d 2 := true; assume(x < 0) ; x := x+1); (assume(d 1 = s 1 ); assume(d 2 = s 2 )) Fig. 3 A program instrumented to enumerate acceleratable paths safety of the constructed program. We can iterate this process to enumerate candidate paths: if we have previously found the paths π 1 , . . . , π n we can add assumptions to the end of our path-enumerating program to prevent the rediscovery of these π i .

Eliminating quantifiers from approximations
A side effect of the approximation steps in Sects. 3.2 and 3.3 is the introduction of quantified assumptions. While quantification is often unavoidable in the presence of arrays, it is a detriment to performance of the decision procedures underlying the verification tools. In the worst case, quantifiers may result in the undecidability of path feasibility.
In the following, we discuss two techniques to eliminate or reduce the number of quantifiers in assumptions occurring in π .

Eliminating quantifiers over monotonic predicates
We show that the quantifiers introduced by the technique presented in Sect. 3.3 can be eliminated if the predicate is monotonic in the quantified parameter.

Definition 1 (Representing function, monotonicity)
The representing function f P of a predicate P with the same domain takes, for each domain value, the value 0 if the predicate holds, and 1 if the predicate evaluates to false, i.e., P(X) ⇔ f P (x) = 0. A predicate P(n) : N → B is monotonically increasing (decreasing) if its representing function f P (n) : N → N is monotonically increasing (decreasing), i.e., ∀m, n . m ≤ n ⇒ f P (m) ≤ f P (n).
We extend this definition to predicates over variables X and n ∈ N as follows: P(X, n) is monotonically increasing in n if (m ≤ n) ∧ P(X, n) ∧ ¬P(X, m) is unsatisfiable.

Proposition 1 P(X, n − 1) ≡ ∀i ∈ [0, n) . P(X, i) if P is monotonically increasing in i.
The validity of Proposition 1 follows immediately from the definition of monotonicity. Accordingly, it is legitimate to replace universally quantified predicates in π with their corresponding unquantified counterparts (c.f. Proposition 1).
This technique, however, fails for simple cases such as x = c (c being a constant). In certain cases, the approach can still be applied after splitting a non-monotonic predicate P into monotonic predicates {P 1 , . . . , P m } such that P ≡ m i=1 P i (as illustrated in the Figure to the right). Subsequently, the path π guarded by P can be split as outlined in Fig. 4. This transformation preserves reachability (a proof for m = 2 is given in Fig. 4).
This approach is akin to trace partitioning [9], however, our intent is quantifier elimination rather than refining an abstract domain. We rely on a template-based approach to identify predicates that can be split (a constraint solver-based approach is bound to fail if c is symbolic). While this technique effectively deals with a broad number of standard cases, it does fail for quantifiers over array indices, since the array access operation is not monotonic.

Eliminating quantifiers in membership tests for array indices
This sub-section aims at replacing the existentially quantified membership test in Predicate (6) by a quantifier-free predicate. To define a set of sufficient (but not necessary) conditions for when this is possible, we introduce the notion of increasing and dense array indices (c.f. [13]):

Definition 2 (Increasing and Dense Variables)
Variables decreasing in π n are defined analogously. A variable is monotonic (in π n ) if it is increasing or decreasing (in π n ).
Note that if the closed form f x (X 0 , n) of a variable x is a linear polynomial, then x is necessarily monotonic. The following proposition uses this property: Lemma 3 Let f x (X 0 , j) be a linear polynomial representing the closed form (2) of x j (as in Proposition 2). The following logical equivalence holds: The validity of Lemma 3 follows immediately from Proposition 2. Using Lemma 3, we can replace the existentially quantified membership test in Predicate (6) by a quantifier-free predicate if one of the side conditions in (8) holds. Given that the path prefix reaches the entry node of a loop, these conditions f x > 0 and 0 ≤ f x ≤ 1 can be checked using a satisfiability solver.
Example 4 Let π def = a[x] := x; x := x + 1 be the body of a loop. By instantiating (6), we obtain the condition in which the existentially quantified term can be replaced by x − x < n.

Implementation and experimental results
Our under-approximation technique is designed to extend existing verifiers. To demonstrate its versatility, we implemented Impulse, a tool combining under-approximation with the two popular software verification techniques lazy abstraction with interpolants (LAwI) [19] and bounded model checking (specifically, Cbmc [5]). The underlying SMT solver used throughout was version 4.2 of Z3. Impulse comprises two phases: 1. Impulse first explores the paths of the CFG following the LAwI paradigm. If Impulse encounters a path containing a loop with body π, it computes π (processing inner loops first in the presence of nested loops), augments the CFG accordingly, and proceeds to phase 2. 2. Cbmc inspects the instrumented CFG up to an iteration bound of 2. If no counterexample is found, Impulse returns to phase 1.
In phase 1, spurious counterexamples serve as a catalyst to refine the current approximation of safely reachable states, relying on the weakest precondition 1 to generate the required Hoare triples. Phase 2 takes advantage of the aggressive path merging performed by Cbmc, enabling fast counterexample detection.
We evaluated the effectiveness of under-approximation on the Verisec benchmark suite [18], which consists of manually sliced versions of several open source programs that contain buffer overflow vulnerabilities. We chose Verisec over the small synthetic benchmarks in the loop-acceleration category of the competition on software verification [2], since the Verisec suite is based on real-world vulnerabilities.
Of the 284 test cases of Verisec, 144 are labelled as containing a buffer overflow, and 140 are labelled as safe. 2 The safety violations range from simple unchecked string copy into static buffers, up to complex loops with pointer arithmetic. The buffer size in each benchmark (c.f.  BUFLEN in Fig. 1) is adjustable and controls the depth of the counterexample. We compared our tool with Satabs (which outperforms Impulse w/o approximation) on buffer sizes of 10, 100 and 1000, with a time limit of 300 s and a memory limit of 2 GB on an 8-core 3 GHz Xeon CPU. Figures 5a through 5c show the cumulative run-time for the whole benchmark suite, whereas Fig. 5d and e show only unsafe program instances. Table 2 provides an overview of the test cases solved by Impulse with or without acceleration compared to the test cases solved by Satabs, including the number of loops and programs that were accelerated. Further, our static acceleration tool accelerates loops (with symbolic rather than static bounds) in 42 programs out of the 79 candidates from the 2013 software verification competition. Finally, on the 8 safe instances from the Verisec benchmark that Impulse can solve (using interpolants computed via the weakest pre-condition), under-approximation did not improve (or impair) the run-time on safe instances.  Figure 6 demonstrates that the time Impulse requires to detect a buffer overflow does not depend on the buffer size. Figure 6a compares Satabs and Impulse on a single Verisec benchmark with a varying size parameter, showing that Satabs takes time exponential in the size of the buffer. Figure 6b provides a qualitative comparison of the loop-detection technique presented in [16] with Impulse on the Aeon 0.02a mail transfer agent. Figure 6b shows the run-times of Satabs'06 with loop detection as reported in [16], 3 as well as the run-times of Impulse on the same problem instances and buffer sizes. Satabs'06 outperforms similar model checking tools that do not feature loop-handling mechanisms [16]. However, the runtime still increases exponentially with the size of the buffer, since the technique necessitates a validation of the unwound counterexample. Impulse does not require such a validation step.

Related work
The under-approximation technique presented in this paper is based on our previous work on loop detection [16,17]. The algorithm in [16], however, does not yield a strict under-approximation, and thus necessitates an additional step to validate the unwound counterexample. Our new technique avoids this problem.
The techniques in Sect. 3.1 constitute a simple form of acceleration [4,8]. The subsequent restrictions in Sects. 3.3 and 3.4 on π , however, impose a symbolic bound on the number of iterations, yielding an under-approximation. In contrast to acceleration of integer relations, our approximation is sound for bit-vector arithmetic. Sinha uses term rewriting to compute symbolic states parametrised by the loop counter, stating that his technique can be extended to support bit-vectors [22].
The quantifier elimination technique of Sect. 4.1 bears similarities with splitter predicates [21], a program transformation facilitating the generation of disjunctive invariants. Similarly, trace partitioning [9] splits program paths to increase the precision of static analyses. Neither technique aims at eliminating quantifiers.
Loop summarisation [15] and path invariants [3] avoid loop unrolling by selecting an appropriate over-approximation of the loop from a catalogue of invariant templates. Overapproximations are also used in the context of loop bound inference [24] and reasoning about termination [6]. However, over-approximations do not enable the efficient detection of counterexamples.
Hojjat et al. [11] uses interpolation to derive inductive invariants from accelerated paths. While this work combines under-and over-approximation, it is not aimed at counterexample detection. Motivated by the results of [11], we believe that under-approximation can, if combined with interpolation, improve the performance of verification tools on safe programs. We plan to support interpolation in a future version of our implementation.
Techniques to solve recurrences are frequently used in compiler construction [23]. For example, van Engelen et al. [7] present an algorithm to compute closed forms for systems of recurrence equations, which also supports induction variables that are updated conditionally by introducing a dynamic range for each variable. While it would be straight forward to incorporate these ideas into our work, the technique discussed in Sect. 3 is sufficient for all practical purposes if the bounded range of program variables is taken into account (see our remark at the end of Sect. 3.1.2).
We refer the reader to [17] for a description of additional related work.

Conclusion and future work
We present a sound under-approximation technique for loops in C programs with bit-vector semantics. The approach is very effective for finding deep counterexamples in programs that manipulate arrays, and compatible with a variety of existing verification techniques. A short-coming of our under-approximation technique is its lack of support for dynamic data structures, which we see as a challenging future direction.