Software Tools for Technology Transfer manuscript No. (will be inserted by the editor) Efficient Monitoring of Safety Properties Klaus Havelund 1 , Grigore Ro¸ su 2 ⋆ 1 Kestrel Technology NASA Ames Research Center, USA. e-mail: havelund@email.arc.nasa.gov 2 Department of Computer Science, University of Illinois at Urbana-Champaign, USA. e-mail: grosu@cs.uiuc.edu Received: date / Revised version: date Abstract. The problem of testing whether a finite ex- ecution trace of events generated by an executing pro- gram violates a linear temporal logic (LTL) formula oc- curs naturally in runtime analysis of software. Two ef- ficient algorithms for this problem are presented in this paper, both for checking safety formulae of the form “al- ways P ”, where P is a past time LTL formula. The first algorithm is implemented by rewriting and the second synthesizes efficient code from formulae. Further opti- mizations of the second algorithm are suggested, reduc- ing space and time consumption. Special operators suit- able for writing succinct specifications are discussed and shown equivalent to the standard past time operators. This work is part of NASA’s PathExplorer project, the objective of which is to construct a flexible framework for efficient monitoring and analysis of program executions. 1 Introduction The work presented in this paper is part of a project at NASA Ames Research Center, called PathExplorer [19, 18,14,17,34], that aims at developing a practical testing environment for NASA software developers. The basic idea of the project is to analyze the execution trace of a running program to detect errors. The errors that we are considering at this stage are multi-threading errors such as deadlocks and data races, and non-conformance with linear temporal logic specifications, which is the main focus of this paper. Linear Temporal Logic (LTL) [33,27,28] is a logic for specifying properties of reactive and concurrent systems. The models of LTL are infinite execution traces, reflect- ing the behavior of such systems as ideally always being ready to respond to requests, operating systems being ⋆ Supported in part by joint NSF/NASA grant CCR-0234524. a typical example. LTL has been mainly used to spec- ify properties of concurrent and interactive down-scaled models of real systems, so that fully formal correctness proofs could subsequently be carried out, for example us- ing theorem provers or model checkers (see for example [21,20,15]). However, formal proof techniques are usu- ally not scalable to real sized systems without a sub- stantial effort to abstract the system more or less manu- ally to a model which can be analyzed. Model checking of programs has received an increased attention from the formal methods community within the last couple of years, and several systems have emerged that can di- rectly model check source code, such as Java and C [16, 37,9,22,8,3,32]. Stateless model checkers [12,36] try to avoid the abstraction process by not storing states. Al- though these systems provide high confidence, they scale less well because most of their internal algorithms are exponential or worse. Testing scales well, and is by far the most used tech- nique in practice to validate software systems. The merge of testing and temporal logic specification is an attempt to achieve the benefits of both approaches, while avoid- ing some of the pitfalls of ad hoc testing and the com- plexity of full-blown theorem proving and model check- ing. Of course, there is a price to pay in order to obtain a scalable technique: the loss of coverage. The suggested framework can only be used to examine single execution traces, and can therefore not be used to prove a system correct. Our work is based on the belief that software en- gineers are willing to trade coverage for scalability, so our goal is to provide tools that are completely automatic, implement very efficient algorithms and find many er- rors in programs. A longer term goal is to explore the use of conformance with a formal specification to achieve fault tolerance. The idea is that the failure may trigger a recovery action in the monitored program. The idea of using LTL in program testing is not new. It has already been pursued in commercial tools such as