Witness validation and stepwise testification across software verifiers

Beyer, Dirk; Dangl, Matthias; Dietsch, Daniel; Heizmann, Matthias; Stahlbauer, Andreas

doi:10.1145/2786805.2786867

Cited by 77 publications

(70 citation statements)

References 42 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…where prop.prp is the SV-COMP property file, input.c is the C file that should be analyzed, 32bit or 64bit is the architecture of the input file, and --full-output enables writing all output instead of just the status of the property to stdout. The option --validate witness.graphml is only used during witness validation and allows the specification of a file containing a violation [2] or correctness witness [1]. Depending on the status of the property, a violation or correctness witness may be written to the file witness.graphml.…”

Section: Path Program Focused Techniques (Abstract Interpretationmentioning

confidence: 99%

Ultimate Automizer and the Search for Perfect Interpolants

Heizmann

Chen

Dietsch

et al. 2018

Tools and Algorithms for the Construction and Analysis of Systems

Self Cite

View full text Add to dashboard Cite

Abstract. Ultimate Automizer is a software verifier that generalizes proofs for traces to proofs for larger parts for the program. In recent years the portfolio of proof producers that are available to Ultimate has grown continuously. This is not only because more trace analysis algorithms have been implemented in Ultimate but also due to the continuous progress in the SMT community. In this paper we explain how Ultimate Automizer dynamically selects trace analysis algorithms and how the tool decides when proofs for traces are "good" enough for using them in the abstraction refinement. Verification ApproachUltimate Automizer (in the following called Automizer) is a software verifier that is able to check safety and liveness properties. The tool implements an automata-based [6] instance of the CEGAR scheme. In each iteration, we pick a trace (which is a sequence of statements) that leads from the initial location to the error location and check whether the trace is feasible (i.e., corresponds to an execution) or infeasible. If the trace is feasible, we report an error to the user; otherwise we compute a sequence of predicates along the trace as a proof of the trace's infeasibility. We call such a sequence of predicates a sequence of interpolants since each predicate "interpolates" between the set of reachable states and the set of states from which we cannot reach the error. In the refinement step of the CEGAR loop, we try to find all traces whose infeasibility can be shown with the given predicates and subtract these traces from the set of (potentially spurious) error traces that have not yet been analyzed. We use automata to represent sets of traces; hence the subtraction is implemented as an automata operation. The major difference to a classical CEGAR-based predicate abstraction is that we never have to do any logical reasoning (e.g., SMT solver calls) that involves predicates of different CEGAR iterations.We use this paper to explain how our tool obtains the interpolants that are used in the refinement step. The Ultimate program analysis framework

show abstract

Section: Path Program Focused Techniques (Abstract Interpretationmentioning

confidence: 99%

Ultimate Automizer and the Search for Perfect Interpolants

Heizmann

Chen

Dietsch

et al. 2018

Tools and Algorithms for the Construction and Analysis of Systems

Self Cite

View full text Add to dashboard Cite

show abstract

“…The complete output of Taipan is also written to the file Ultimate.log. Depending on the status of the property, a violation [3] or correctness [2] witness may be written to the file witness.graphml.…”

Section: Dynamic Block Encodingmentioning

confidence: 99%

Ultimate Taipan with Dynamic Block Encoding

Dietsch

Greitschus

Heizmann

et al. 2018

Tools and Algorithms for the Construction and Analysis of Systems

Self Cite

View full text Add to dashboard Cite

Abstract. Ultimate Taipan is a software model checker that uses trace abstraction and abstract interpretation to prove correctness of programs. In contrast to previous versions, Ultimate Taipan now uses dynamic block encoding to obtain the best precision possible when evaluating transition formulas of large block encoded programs. Verification ApproachUltimate Taipan (or Taipan for brevity) is a software model checker which combines trace abstraction [9,10] The initial abstraction of the program is an automaton with the same graph structure as the program's control flow graph, where program locations are states, transitions are labeled with program statements, and error locations are accepting. Thus, the language of the automaton consists of all traces, i.e., sequences of statements, that, if executable, lead to an error. In each iteration, the algorithm chooses a trace from the language of the current automaton and constructs a path program from it. A path program is a projection of the (abstraction of the) program to the trace. The algorithm then uses abstract interpretation to compute fixpoints for the path program. If the fixpoints of the path program are sufficient to prove correctness, i.e., the error location is unreachable, at least the chosen trace and all other traces that are covered by the path program are infeasible. The computed fixpoints constitute a proof of correctness for the path program and can be represented as a set of state assertions. From this set of state assertions, the abstraction is refined by constructing a new automaton whose language only consists of infeasible traces and then subtracting it from the current abstraction using an automatatheoretic difference operation. If abstract interpretation was unable to prove correctness of the path program, the algorithm obtains a proof of infeasibility of the trace using either interpolating SMT solvers or a combination of unsatisfiable cores and strongest post or weakest pre [6]. If the currently analyzed trace is feasible,

show abstract

“…Finally, nodes in the wait list are only connected to a single node FALSE. An Assumption Automaton encodes the progress achieved throughout an earlier incomplete verification attempt in a machine-readable format [4], which is the fundamental reason why we use it.…”

Section: B Assumption Automatamentioning

confidence: 99%

Model checker execution reports

Castaño

Braberman

Garbervetsky

et al. 2017

2017 32nd IEEE/ACM International Conference on Automated Software Engineering (ASE)

View full text Add to dashboard Cite

Abstract-Software model checking constitutes an undecidable problem and, as such, even an ideal tool will in some cases fail to give a conclusive answer. In practice, software model checkers fail often and usually do not provide any information on what was effectively checked. The purpose of this work is to provide a conceptual framing to extend software model checkers in a way that allows users to access information about incomplete checks. We characterize the information that model checkers themselves can provide, in terms of analyzed traces, i.e. sequences of statements, and safe cones, and present the notion of execution reports, which we also formalize. We instantiate these concepts for a family of techniques based on Abstract Reachability Trees and implement the approach using the software model checker CPAchecker. We evaluate our approach empirically and provide examples to illustrate the execution reports produced and the information that can be extracted.

show abstract

Witness validation and stepwise testification across software verifiers

Cited by 77 publications

References 42 publications

Ultimate Automizer and the Search for Perfect Interpolants

Ultimate Automizer and the Search for Perfect Interpolants

Ultimate Taipan with Dynamic Block Encoding

Model checker execution reports

Contact Info

Product

Resources

About