Automatically validating temporal safety properties of interfaces (2001)
Cached
Download Links
- [www.cs.sunysb.edu]
- [www.ece.cmu.edu]
- [www.research.microsoft.com]
- [www.research.microsoft.com]
- DBLP
Other Repositories/Bibliography
| Citations: | 348 - 18 self |
BibTeX
@INPROCEEDINGS{Ball01automaticallyvalidating,
author = {Thomas Ball and Sriram K. Rajamani},
title = {Automatically validating temporal safety properties of interfaces},
booktitle = {},
year = {2001},
pages = {103--122},
publisher = {Springer-Verlag}
}
Years of Citing Articles
OpenURL
Abstract
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.







