Results 1 - 10
of
20
Parametric Shape Analysis via 3-Valued Logic
, 1999
"... Shape Analysis concerns the problem of determining "shape invariants"... ..."
Abstract
-
Cited by 465 (64 self)
- Add to MetaCart
Shape Analysis concerns the problem of determining "shape invariants"...
Automatically validating temporal safety properties of interfaces
, 2001
"... We present a process for validating temporal safety properties of software that uses a well-defined interface. The process requires only that the user state the property of interest. It then automatically creates abstractions of C code using iterative refinement, based on the given property. The pro ..."
Abstract
-
Cited by 348 (18 self)
- Add to MetaCart
We present a process for validating temporal safety properties of software that uses a well-defined interface. The process requires only that the user state the property of interest. It then automatically creates abstractions of C code using iterative refinement, based on the given property. The process is realized in the SLAM toolkit, which consists of a model checker, predicate abstraction tool and predicate discovery tool. We have applied the SLAM toolkit to a number of Windows NT device drivers to validate critical safety properties such as correct locking behavior. We have found that the process converges on a set of predicates powerful enough to validate properties in just a few iterations. 1 Introduction Large-scale software has many components built by many programmers. Integration testing of these components is impossible or ineffective at best. Property checking of interface usage provides a way to partially validate such software. In this approach, an interface is augmented with a set of properties that all clients of the interface should respect. An automatic analysis of the client code then validates that it meets the properties, or provides examples of execution paths that violate the properties. The benefit of such an analysis is that errors can be caught early in the coding process. We are interested in checking that a program respects a set of temporal safety properties of the interfaces it uses. Safety properties are the class of properties that state that "something bad does not happen". An example is requiring that a lock is never released without first being acquired (see [24] for a formal definition). Given a program and a safety property, we wish to either validate that the code respects the property, or find an execution path that shows how the code violates the property.
Boolean and Cartesian Abstraction for Model Checking C Programs
, 2001
"... The problem of model checking a specification in form of a C program with recursive procedures and many thousands of lines of code has not been addressed before. In this paper, we show how we attack this problem using an abstraction that is formalized with the Cartesian abstraction. It is implemente ..."
Abstract
-
Cited by 130 (12 self)
- Add to MetaCart
The problem of model checking a specification in form of a C program with recursive procedures and many thousands of lines of code has not been addressed before. In this paper, we show how we attack this problem using an abstraction that is formalized with the Cartesian abstraction. It is implemented through a source-to-source transformation into a `Boolean' C program; we give an algorithm to compute the transformation with a cost that is exponential in its theoretical worst-case complexity but feasible in practice.
Temporal-Safety Proofs for Systems Code
, 2002
"... We present a methodology and tool for verifying and certifying systems code. The veri cation is based on the lazy-abstraction paradigm for intertwining the following three logical steps: construct a predicate abstraction from the code, model check the abstraction, and automatically re ne the a ..."
Abstract
-
Cited by 66 (9 self)
- Add to MetaCart
We present a methodology and tool for verifying and certifying systems code. The veri cation is based on the lazy-abstraction paradigm for intertwining the following three logical steps: construct a predicate abstraction from the code, model check the abstraction, and automatically re ne the abstraction based on counterexample analysis. The certi cation is based on the proof-carrying code paradigm. Lazy abstraction enables the automatic construction of small proof certi cates. The methodology is implemented in Blast, the Berkeley Lazy Abstraction Software veri cation Tool. We describe our experience applying Blast to Linux and Windows device drivers. Given the C code for a driver and for a temporal-safety monitor, Blast automatically generates an easily checkable correctness certi cate if the driver satis es the speci cation, and an error trace otherwise.
Relative Completeness of Abstraction Refinement for Software Model Checking
, 2002
"... Automated methods for an undecidable class of verification problems cannot be complete (terminate for every correct program). We therefore consider a new kind of quality measure for such methods, which is completeness relative to a (powerful but unrealistic) oracle-based method. More precisely, we a ..."
Abstract
-
Cited by 49 (4 self)
- Add to MetaCart
Automated methods for an undecidable class of verification problems cannot be complete (terminate for every correct program). We therefore consider a new kind of quality measure for such methods, which is completeness relative to a (powerful but unrealistic) oracle-based method. More precisely, we ask whether an often implemented method known as "software model checking with abstraction refinement" is complete relative to fixpoint iteration with "oracle-guided" widening. We show that whenever backward fixpoint iteration with oracle-guided widening succeeds in proving a property' (for some sequence of widenings determined by the oracle) then software model checking with a particular form of backward refinement will succeed in proving'. Intuitively, this means that the use of fixpoint iteration over abstractions and a particular backwards refinement of the abstractions has the effect of exploring the entire state space of all possible sequences of widenings.
Heuristics for Model Checking Java Programs
, 2002
"... Model checking of software programs has two goals: one is the veri cation of correct software. The other is the discovery of errors in faulty software. Some techniques for dealing with the most crucial problem in model checking, the state space explosion problem, concentrate on the rst of these go ..."
Abstract
-
Cited by 49 (7 self)
- Add to MetaCart
Model checking of software programs has two goals: one is the veri cation of correct software. The other is the discovery of errors in faulty software. Some techniques for dealing with the most crucial problem in model checking, the state space explosion problem, concentrate on the rst of these goals. In this paper we present an array of heuristic model checking techniques for combating the state space explosion when searching for errors. Previous work on this topic has mostly focused on property-speci c heuristics closely related to particular kinds of errors. We present structural heuristics that attempt to explore the structure (branching structure, thread inter-dependency structure, abstraction structure) of a program in a manner intended to expose errors eciently. Experimental results show the utility of this class of heuristics. In contrast to these very general heuristics, we also present very lightweight techniques for introducing program-speci c heuristic guidance. 1
Incompleteness, Counterexamples and Refinements in Abstract Model-Checking
- In P. Cousot (ed), Proc. 8 th Int. Symp. SAS '01, LNCS 2126
, 2001
"... In this paper we study the relation between the lack of completeness in abstract interpretation of model-checking and the structure of the counterexamples produced by a model-checker. We consider two dual forms of completeness of an abstract interpretation: Forward and backward completeness. They co ..."
Abstract
-
Cited by 46 (9 self)
- Add to MetaCart
In this paper we study the relation between the lack of completeness in abstract interpretation of model-checking and the structure of the counterexamples produced by a model-checker. We consider two dual forms of completeness of an abstract interpretation: Forward and backward completeness. They correspond respectively to the standard / completeness of an abstract interpretation and can be related with each other by adjunction. We give a constructive characterization of Clarke et al.'s spurious counterexamples in terms of both forward and backward completeness of the underlying abstract interpretation. This result allows us to understand the structure of the counterexamples that can be removed by systematically refining abstract domains to achieve completeness with respect to a given operation. We apply our result to improve static program analysis by re ning the model-checking of an abstract interpretation.
Model Checking Java Programs using Structural Heuristics
- IN INTERNATIONAL SYMPOSIUM ON SOFTWARE TESTING AND ANALYSIS
, 2002
"... We describe work introducing heuristic search into the Java PathFinder model checker, which targets Java bytecode. Rather than focusing on heuristics aimed at a particular kind of error (such as deadlocks) we describe heuristics based on a modi cation of traditional branch coverage metrics and othe ..."
Abstract
-
Cited by 46 (12 self)
- Add to MetaCart
We describe work introducing heuristic search into the Java PathFinder model checker, which targets Java bytecode. Rather than focusing on heuristics aimed at a particular kind of error (such as deadlocks) we describe heuristics based on a modi cation of traditional branch coverage metrics and other structural measures, such as thread inter-dependency. We present experimental results showing the utility of these heuristics, and argue for the usefulness of structural heuristics as a class.
Adaptive Model Checking
, 2002
"... We consider the case where inconsistencies are present between a system and its corresponding model, used for automatic verification. Such inconsistencies can be the result of modeling errors or recent modifications of the system. Despite such discrepancies we can still attempt to perform automatic ..."
Abstract
-
Cited by 43 (1 self)
- Add to MetaCart
We consider the case where inconsistencies are present between a system and its corresponding model, used for automatic verification. Such inconsistencies can be the result of modeling errors or recent modifications of the system. Despite such discrepancies we can still attempt to perform automatic verification. In fact, as we show, we can sometimes exploit the verification results to assist in automatically learning the required updates to the model. In a related previous work, we have suggested the idea of black box checking, where verification starts without any model, and the model is obtained while repeated verification attempts are performed. Under the current assumptions, an existing inaccurate (but not completely obsolete) model is used to expedite the updates. We use techniques from black box testing and machine learning.

