InterpChecker: Reducing State Space via Interpolations
Abstract
InterpChecker is a tool for verifying safety properties of C programs. It reduces the state space of programs throughout the verification via two new kinds of interpolations and associated optimization strategies. The implementation builds on the opensource, configurable software verification tool, CPAChecker.
1 Verification Approach
Our approach to scalable CEGARbased model checking is to exploit Craig interpolation [3] to learn abstractions that can systematically reduce the program state space which must be explored for a given safety verification problem. In addition to the interpolants for parsimonious abstraction [4] (called reachability interpolants (RInterp) here for clarity), we introduce two new kinds of interpolants, called universal safety interpolants and existential error interpolants.

A universal safety interpolant (or SInterp) is useful for determining whether all the paths emanating from a state are safe, without exploring all the possible branches from it.

An existential error interpolant (or EInterp) is useful for determining whether there exists an unsafe path emanating from a state, without exploring all the possible branches from it.
The SInterp at a location of a control flow graph (CFG) collects predicates that are relevant to a yesinstance of the safety verification, so that whenever the SInterp is implied by the current path, all paths emanating from this location are guaranteed to be safe. Dually, whenever the EInterp at a location of a CFG is implied by the current path, there is an unsafe branch from it, and so, one can immediately conclude that the program is unsafe. We learn SInterp and EInterp from spurious error traces and apply them to reduce the state space of programs throughout the CEGARbased program verification process. For convenience, we denote a CFG as a tuple \(G=(L, T, l_{0}, f)\), where L is the set of program locations, \(l_{0} \in L\) is the initial location, \(f \in L\) is the final location, \(T \subseteq L\times Ops \times L\) is the transition relation, and Ops is the set of instructions.
When verifying a programs, we first unwind the CFG to generate an Abstract Reachability Tree (ART). An ART \(A = (S_{A}, E_{A})\), obtained from a CFG \(G=(L, T, l_{0}, f)\), consists of a set \(S_{A}\) of abstract states and a set \(E_{A}\) of edges. An abstract state \(s\in S_A\) is a triple \(s=(l, c, p)\) where l is a location in the CFG, c is the current call stack, and p is an abstract predicate indicating the reachable region of the current state which is determined by the reachable interpolant, RInterp. Given two states s and \(s'\), we say s is covered by \(s'\) just if \(s[0]=s'[0]\), \(s[1]=s'[1]\), and \(s[2]\rightarrow s'[2]\). (Notation: for a tuple e, we write e[i] for the ith component of e.) Further, if s is covered by \(s'\) and all the future of \(s'\) (i.e. all abstract states reachable from \(s'\)) has been explored, then it is safe to not explore the future of s. A branch (path) \(\varPi \) of an ART, denoting a possible execution of the program, is a finite alternating sequence of states and edges, \(\varPi = \langle s_0, e_{0}, \cdots , e_{n1}, s_n \rangle \), such that for all \(0\le i<n\), \(e_i[0]=s_i\) and \(e_i[2]=s_{i+1}\). Given a path \(\varPi \) of an ART, we write \( P_f (\varPi )\) for the path formula \(\textsc {ssa}(e_0[1])\wedge \cdots \wedge \textsc {ssa}(e_{n1}[1])\) obtained from \(\varPi \). Here \(\textsc {ssa}( op )\) is the static single assignment (SSA) of an operation op where every variable occurring in \(\varPi \) is assigned a value at most once.
 (1)Reversely traverse the current path for other possibilities if one of the following three conditions holds:

\(p= false \);

\(p\not = false \), \(F(l)=f\), and \(P_f(s_0,\cdots , s)\rightarrow I_s(l)\);

\(p\not = false \) and s is covered by a visited state \(s'\).

 (2)
Report the program is unsafe, if \(p\not = false \) and \(P_f(s_0,\cdots , s)\rightarrow {E\text{ } Interp }(l)\).
 (3)
Explore the succeeding state \(s'': (suc(l), c, p')\), otherwise.
To maximise the effect of the proposed interpolations, we also present two kinds of optimizing strategies: pruning CFG and weightguided search. In realworld programs, there may exist some locations in a CFG which can never reach any error location. To avoid exploring these locations when verifying the program, the first strategy is to prune the CFG by removing these locations and the relative control flow edges in advance. A safety interpolant works only when it is full. Hence, the earlier full safetyinterpolants are formed, the more effective the performance will be. To form full interpolants, the second strategy is to explore one side of a branch as early as possible if the other side has been explored. The goal is achieved by introducing an attribute weight to transitions of a CFG. Throughout the verification, the branch with the largest weight will be explored first.
2 Software Architecture
Our implementation of InterpChecker builds on the opensource, configurable software verification tool, CPAChecker [1]. Like CPAChecker, InterpChecker can verify safety properties of C program via reachability checking of the instrumented error labels. All extra functions are implemented in Java, using the existing libraries provided by CPAChecker. In Fig. 1, the white parts are new, while the grey parts are original CPAChecker functions. We set up the InterpChecker interpolants and optimizations as an option of CPAChecker, organised as a refinementselection configuration, in the sense of [2].
3 Strengths and Weakness
The new interpolants implemented in InterpChecker do not affect the existing configurations of CPAChecker. InterpChecker supports the verification of safety properties of C program via reachability checking of the instrumented error labels. The power of InterpChecker is best illustrated when analysing largescale programs because it can avoid exploring more paths. The current version does not support the verification of the properties written as temporal logic formulas. Like CPAChecker, we skip recursive functions and treat them as pure functions. Thus, false negatives may occur for programs with recursive functions.
4 Tool Setup and Configuration
A zipped file containing InterpChecker 1.0 is available at http://github.com/duanzhaodz/interpchecker. It contains all the required libraries: no installation of external tools is required. To run InterpChecker, first download the code from the website, then run the following command to install the package in Ubuntu 16.04: sudo aptget install openjdk8jdk.
To process a benchmark example test.c, invoke the script by the following command: ./scripts/cpa.sh svcomp18interpcpachecker test.c. The output of InterpChecker is written to the file output/Statistics.txt. When using BenchExec, the output can be translated by the interpchecker.py toolinfo module. The categories verified by the competition candidate are listed in the file interpchecker.xml. The two files are contained in the zipped file. If the checked property does not hold, a human readable counterexample is written to output/ErrorPath.txt and an error witness is written to the zipped file witness.graphml.gz. Note that Java Runtime Environment is required, which should be at least Java 8 compatible.
5 Software Project and Contributors
Based on the open source tool CPAChecker, InterpChecker is developed by Xidian University, China, and the University of Oxford, UK. We thank Dirk Beyer and his team for their original contributions to CPAChecker.
References
 1.Beyer, D., Keremoglu, M.E.: CPAchecker: a tool for configurable software verification. In: Gopalakrishnan, G., Qadeer, S. (eds.) CAV 2011. LNCS, vol. 6806, pp. 184–190. Springer, Heidelberg (2011). https://doi.org/10.1007/9783642221101_16CrossRefGoogle Scholar
 2.Beyer, D., Löwe, S., Wendler, P.: Refinement selection. In: Fischer, B., Geldenhuys, J. (eds.) SPIN 2015. LNCS, vol. 9232, pp. 20–38. Springer, Cham (2015). https://doi.org/10.1007/9783319234045_3CrossRefGoogle Scholar
 3.Albarghouthi, A., Gurfinkel, A., Chechik, M.: Craig interpretation. In: Miné, A., Schmidt, D. (eds.) SAS 2012. LNCS, vol. 7460, pp. 300–316. Springer, Heidelberg (2012). https://doi.org/10.1007/9783642331251_21CrossRefGoogle Scholar
 4.Henzinger, T.A., Jhala, R., Majumdar, R., McMillan, K.L.: Abstractions from proofs. In: Proceedings of POPL, pp. 232–244 (2004)CrossRefGoogle Scholar
 5.Tian, C., Duan, Z., Duan, Z.H., Ong, L.: More effective interpolations in software model checking. In: The 32nd IEEE/ACM International Conference on Automated Software Engineering, ASE 2017, pp. 183–193. IEEE (2017)Google Scholar
Copyright information
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.