1 Verification Approach

Ultimate Automizer implements an automata-based approach to software verification that we call trace abstraction [4]. The key concept in this approach is the notion of a trace which is a sequence of program statements. We consider a program as a set of traces, namely the set of all traces that are labellings of paths in the control flow graph. For the verification of a property, we start with all traces that potentially violate the property, e.g., for checking non-reachability of an error location we start with all traces that lead from the initial location to the error location. Then, we iteratively prove that all these traces are infeasible, i.e., we prove that none of these traces corresponds to a concrete program execution. In each iteration we take a sample trace \(\pi \) that potentially violates the property and analyze its feasibility. If the trace \(\pi \) is feasible, we found a concrete counterexample to the validity of the property. Otherwise, we construct a proof for the infeasibility of \(\pi \). Next, we generalize the trace \(\pi \) to a set of traces that are infeasible and whose infeasibility can be shown using the proof that was constructed for \(\pi \).

We use automata to represent sets of traces. The underlying alphabet is the set of all program statements. The traces that potentially violate the non-reachability property are the words that are accepted by the automaton that resembles the control flow graph of the program and whose final state is the node that corresponds to the error location of the program. The procedure for obtaining sample traces is implemented as an emptiness check and in each iteration we use a difference operation on automata to ensure that we exclude all traces whose infeasibility was already shown.

In the following we present new features of this year’s competition candidate.

Two-track Proofs. In former versions of our tool, the above mentioned infeasibility proof for a trace was an inductive sequence of state predicates. Such a sequence was obtained via Craig interpolation or via a technique that combines unsatisfiable cores, live variables and the post predicate transformer. In this year’s competition contribution, we use this technique to compute two sequences of predicates. One sequence is obtained by the post predicate transformer, the other sequence is obtained by the wp predicates transformer. A second sequence of predicate is redundant to prove the infeasibility of the trace \(\pi \) but it improves the generalization from one infeasible trace \(\pi \) to a set of infeasible traces.

Semi-deterministic Büchi Automata. In our termination analysis we consider infinite traces and use Büchi automata to represent sets of traces [5]. The subtraction of traces whose infeasibility was already proven involves the complementation of Büchi automata which is known to be expensive. In order to overcome this bottleneck, we adjusted our algorithm such that the input of complementation operations is always a semi-deterministic Büchi automaton. This allows us to use a specialized complementation whose result has at most \(4^n\) states [2].

Bitprecise Analysis. We use SMT-LIB to represent sets of program states and the transition relation of program statements. First, we try to verify a program by using the theory of (mathematical) integers. In order to soundly capture the semantics of machine integers we use modulo operations and we overapproximate bitwise operations, e.g., bitshifts, by a havoc operation. Whenever this analysis returns a counterexample that contains an overapproximated bitwise operation, we redo the analysis and use the SMT-LIB theory of bitvectors.

2 Software Project

Ultimate Automizer is one toolchain of the Ultimate program analysis framework. Our competition candidate uses several libraries provided by Ultimate, e.g., an automata library, the LassoRanker library which is used for the termination analysis of lasso-shaped infinite traces [6], the SMT solver SMTInterpol [3], and an interface that allows us to communicate with any SMT-LIBv2 compatible SMT solver, The source code is available on GithubFootnote 1 and several toolchains of Ultimate are available via a web interface.

3 Tool Setup and Configuration

A zip archive that contains the competition candidate is available at the website of Ultimate Automizer Footnote 2. The archive contains a binary of Z3Footnote 3 and the installation of external tools is not required. Furthermore, the archive contains the Python script Ultimate.py, which maps the input given in the competition to the arguments that are required by the actual binary of Ultimate. At the SV-COMP the input to a tool is a C program inputfile, a property file prop.prp, an architecture which is either 32bit or 64bit, and a memory model which is either simple or precise. Given these arguments, the script should be invoked by the following command.

figure a

The output of Ultimate Automizer is written to the file Ultimate.log and the result is written to stdout. When using BenchExec the output can be translated by the ultimateautomizer.py tool-info moduleFootnote 4.

If the checked property does not hold, a human readable counterexample is written to UltimateCounterExample.errorpath and an error witness is written to witness.graphml.

4 Witness Validator

Verifiers that participate in the SV-COMP output an error witness [1] if they find a violation of the given property. An error witness is a machine readable counterexample to the validity of the property. An error witness may not represent a single program execution that violates the property, it may represent a set of program executions. The idea is that it narrows down the space in which verifiers have to search for possible violations of the property.

Ultimate Automizer can be used to validate error witnesses. For validating an error witness wtns.graphml we invoke the command mentioned in the preceding section and append wtns.graphml as a fifth argument.

figure b

The witness is confirmed if and only if Ultimate Automizer reports a violation of the property. I.e., the witness is confirmed if and only if a counterexample was found in the search space restricted by the witness.