Software Verification with BLAST

Henzinger, Thomas A.; Jhala, Ranjit; Majumdar, Rupak; Sutre, Grégoire

doi:10.1007/3-540-44829-2_17

Cited by 297 publications

(213 citation statements)

References 7 publications

Supporting

Mentioning

208

Contrasting

Unclassified

Order By: Relevance

“…Temporal logics have been used extensively in model checking [21], for example in the tools (there are too many others to fully list here): BLAST [37] Java Pathfinder [70] NuSMV [19] PRISM [48] SPIN [40] UPPAAL [9]. Temporal logics have also been used in run-time checking, even for the functional language Haskell [66].…”

Section: Context-free Grammarsmentioning

confidence: 99%

Combining Monitoring with Run-Time Assertion Checking

Boer

Gouw

2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

Abstract. According to a study in 2002 commisioned by a US Department, software bugs annually costs the US economy an estimated $59 billion 1 . A more recent study in 2013 by Cambridge University estimated that the global cost has risen to $312 billion globally 2 .There exists various ways to prevent, isolate and fix software bugs, ranging from lightweight methods that are (semi)-automatic, to heavyweight methods that require significant user interaction. Our own method described in this tutorial is based on automated run-time checking of a combination of protocol-and data-oriented properties of object-oriented programs. Run-Time Checking of Object-Oriented ProgramsGiven a program and a specification, a run-time verifier inserts checks in the code that determine whether the specification is satisfied. The checks are triggered during an actual execution of the program. In contrast to static verification, where properties are checked with respect to all executions (possibly there are infinitely many), run-time checkers only consider a single execution of the program. There is a wide range of specification languages used in run-time verification. They can be partitioned into two categories: languages that focus on the control-flow (these approaches are also called "monitoring"), and those focussing on data-flow.As an example, one can use regular expressions to specify the order in which functions or methods in a program should be called [18]. Such specifications describe the control-flow of the program. Other formalisms for specifying controlflow are temporal logics, various kinds of automata and context-free grammars. For these formalisms, checking whether a given property holds of the current execution involves parsing a word (where the word is some representation of the trace of method calls in the current execution) in an automata. Generally only formalisms are chosen with a decidable parsing problem (in particular, this is the case for regular expressions, context-free grammars and most automata), so Approaches that specify data-flow usually do so by annotating the source code with assertions: logical formulas that must be true whenever control passes them. The formulas constrain the values of the program variables. If assertions are expressed in first-order logic with arithmetic, it is in general undecidable due to unbounded quantification (i.e. ranging over an infinite number of values) whether the assertion is true, thus usually the assertions are restricted in some way. For instance, Java contains an assert-statement which restricts to quantifier-free formulas (i.e. Boolean expressions). Design by Contract [53] provides a systematic way of using assertions to specify classes, interfaces and methods with respectively class invariants and pre-and postconditions. It was first used in the programming language Eiffel, and subsequently has also been applied to many other programming languages. For example, JML [14] is one of the most popular specification languages for Java and supports Design by Contract. JML...

show abstract

Section: Context-free Grammarsmentioning

confidence: 99%

Combining Monitoring with Run-Time Assertion Checking

Boer

Gouw

2014

Lecture Notes in Computer Science

View full text Add to dashboard Cite

show abstract

“…While fast, it was limited to simple root causes for infeasible paths and much less precise than the SMT approach in this work. On the other hand, the application of predicate abstraction in conjunction with on-demand refinement has long been present in the CEGAR [6] approach and is used in many software model checkers such as SLAM [17] and BLAST [4,3]. This approach refines the whole model iteratively instead of eliminating sets of paths and using observers to learn from it.…”

Section: Related Workmentioning

confidence: 99%

SMT-Based False Positive Elimination in Static Program Analysis

Junker

Huuck

Fehnker

et al. 2012

Formal Methods and Software Engineering

View full text Add to dashboard Cite

Abstract. Static program analysis for bug detection in large C/C++ projects typically uses a high-level abstraction of the original program under investigation. As a result, so-called false positives are often inevitable, i.e., warnings that are not true bugs. In this work we present a novel abstraction refinement approach to automatically investigate and eliminate such false positives. Central to our approach is to view static analysis as a model checking problem, to iteratively compute infeasible sub-paths of infeasible paths using SMT solvers, and refine our models by adding observer automata to exclude such paths. Based on this new framework we present an implementation of the approach into the static analyzer Goanna and discuss a number of real-life experiments on larger C code projects, demonstrating that we were able to remove most false positives automatically.

show abstract

“…Table 1 shows the performance of SLAB on a range of benchmarks. For comparison, we also give the running times of the Abstraction Refinement Model Checker ARMC [7], the Berkeley Lazy Abstraction Software Verification Tool BLAST [4] and the New Symbolic Model Checker NuSMV [3], where applicable. The benchmarks include a finite-state concurrent systems (Deque and Philosophers), an infinite-state discrete system (Bakery), and a real-time system (Fisher).…”

Section: Armc Blastmentioning

confidence: 99%

SLAB: A Certifying Model Checker for Infinite-State Concurrent Systems

Dräger

Kupriyanov

Finkbeiner

et al. 2010

Tools and Algorithms for the Construction and Analysis of Systems

View full text Add to dashboard Cite

Abstract. Systems and protocols combining concurrency and infinite state space occur quite often in practice, but are very difficult to verify automatically. At the same time, if the system is correct, it is desirable for a verifier to obtain not a simple "yes" answer, but some independently checkable certificate of correctness. We present SLAB -the first certifying model checker for infinite-state concurrent systems. The tool uses a procedure that interleaves automatic abstraction refinement using Craig interpolation with slicing, which removes irrelevant states and transitions from the abstraction. Given a transition system and a safety property to check, SLAB either finds a counterexample or produces a certificate of system correctness in the form of inductive verification diagram. Slicing AbstractionsSLAB (for sl icing abstractions) is an automatic certifying model checker that implements the abstraction refinement loop presented in [1]. It interleaves refinement steps with slicing, which tracks the dependencies between variables and transitions in a system and removes irrelevant parts.SLAB maintains an explicit graph representation of the abstract model: each node represents a set of concrete states, identified by a set of predicates; each edge represents a set of concrete transitions, identified by their transition relations.Starting with the initial abstraction, the abstract model is transformed by refinement and slicing steps until the system is proved correct or a concretizable error path is found.A refinement step increases the precision of the abstraction by introducing a new predicate, which is obtained by Craig interpolation from the unsatisfiable formula corresponding to some spurious error path. To minimize the increase in the size of the graph, the new predicate is only applied to one specific node on the error path. This node is split into two copies, the labels of which now additionally contain the new predicate and its negation, respectively.A slicing step reduces the size of the abstraction while maintaining all error paths. Elimination rules drop nodes and edges from the abstraction if they have

show abstract

Software Verification with BLAST

Cited by 297 publications

References 7 publications

Combining Monitoring with Run-Time Assertion Checking

Combining Monitoring with Run-Time Assertion Checking

SMT-Based False Positive Elimination in Static Program Analysis

SLAB: A Certifying Model Checker for Infinite-State Concurrent Systems

Contact Info

Product

Resources

About