Java PathFinder JPF 2 Second Generation of Java Model Checker

Size: px

Start display at page:

Download "Java PathFinder JPF 2 Second Generation of Java Model Checker"

Agatha Ferguson
6 years ago
Views:

1 Java PathFinder JPF 2 Second Generation of Java Model Checker Guenther Brand Mat. Nr Abstract This essay is based on the papers Java PathFinder, Second Generation of Java Model Checker and Model Checking Programs, both written by Guillaumme Brat, Klaus Havelund, SeungJoon Park and Willem Visser. They describe a verification and testing environment for Java, the Java PathFinder (JPF), that integrates model checking, program analyses and testing. JPF uses state compression, partial order reduction, slicing, abstraction, and runtime analysis techniques. The first developed Java model checker, the Java PathFinder 1 (JPF1), was highly successful in finding errors in complex Java programs. However, it could not handle features like floating point numbers. Furthermore the complete Java source code is required. JPF2 solves this problems, because it works directly on Java bytecode. 0

2 1 Motivation The usual approach of model checking is to extract portions of the code, create a model, and then check that model. But this has the drawback that it requires expertise in the use of model checking tools. The first Java model ckecker, the Java PathFinder 1 (JPF1), automatically translated from Java source code to PROMELA in order to do model checking. JPF1 was highly successful in finding errors in complex Java programs. However, it could not handle specific features that were not supported by PROMELA, for example floating point numbers. Furthermore, all the Java source code is required to be available which is for example not the case if libraries are used. In order to solve this problems a new Java model checker, JPF2, was built. JPF2 works directly on Java bytecode, Model checking often suffers from the state-explosion problem. In order to alleviate some of this problems abstraction, static analysis, and runtime analysis are used. 2 Introduction With the Java PathFinder (JPF), an expicit-state model checker for Java programs, a verification, analysis and testing environment has been developed. It combines model checking techiques and techniques for dealing with large or infinite state spaces. These techniques include static analysis, predicate abstraction, and runtime analyses. The JPF itself is written in Java and contains a therefore new built Java Virtual Machine (MC-JVM) that interprets Java bytecode. The MC-JVM, suitable for model checking, requires efficient memory management rather than blistering speed. Currently, JPF can only check invariants and deadlocks. An invariant is specified as a Java method that returns a boolean value - this method can examine the contents of the memory of the program as well as special-purpose methods provided by the MC-JVM. The model checker consists of two parts: the MC-JVM that executes the bytecode and a depth-first algorithm that does the actual traversal of the state-graph of the program. Both the MC-JVM and the traversal algorithm are written in Java and hence executed by a commercial available JVM. The output of the model checker is whether or not the invariant holds, or the program is deadlock free - and in negative case a counter example is produced. Some of the novel features of MC-JVM are: Canonical Heap Representation: Regardless of which interleaving of statements is executed, memory will always be allocated in the same memory locations. This reduces the size of state-space. Garbage Collection: The MC-JVM has its own garbage colletion scheme, since without it statespace would grow to infinite. Nondeterminism: The MC-JVM traps certain method calls having nondeterministic behavior, namely Verify.Random(i) and Verify.RandomBool(). Atomicity: The level of atomicity during execution can be set to be one bytecode instruction, the bytecodes for one Java instruction, the bytecodes for one line of Java code or all bytecodes in a block of Java code. Structured State: Each state is highly structured, since it is consisting of a number of different Java classes. 2.1 Why Analyze Code? It is often argued that verification technologies should be applied to designs rather than to programs since catching errors early at the design level will reduce maintenance costs later on. However, there is a number of reasons for using formal methods on programs: 1

3 Programs often contain fatal errors, deadlocks and critical section violations for example, in spite of the existing of careful design, because design typically do not deal with them. Any research result on programming languages can benefit design verification since designs typically are less complex. Studying verification of real programs may drive the research into new areas. It is believed to be advantageous for formal methods to be combined with research fields more focused on programs, such as program analysis and testing. There may be some derived advantages for formal methods due to the fact that there is a tendency to standardize programming languages. 3 Model Checking Java Programs With Java the capability of writing concurrent programs, which is known as non-trivial, is given to everyone, so a model checker for Java might have a bright future. 3.1 Complexity of Language Constructs To allow efficient processing during model checking the input languages for model checker are often kept relatively simple. General programming lanugages, however, contain new features like classes, dynamic memory allocation, exceptions, floating point numbers, method calls, and so on, never seen in model checking input languages. To treat this there are three solutions pursued: Translation The new features are translated to existing ones. For example JPF1 and the JCAT system were base on a translation from Java to PROMELA. But there are two serious drawbacks: Each new feature in the source language must be coverd by a counterpart in the destination language (which in the case of Java and PROMELA is not true). And the original source code is required, which is often not the case. This can be overcome by rather doing a translation from bytecodes. Custom-made Model Checker In order to overcome the language coverage problem either the current model checkers need to be extended, or a new custom-made model checker must be developed. With JPF2 a new model-checker has been developed that can execute all the bytecode instructions, and hence allow the whole of Java to be model checked. It consists of an own Java Virtual Machine (MC-JVM) that executes the bytecodes and a search component that guides the execution. The current model checker can check for deadlocks, invariants and user-defined assertions in the code; temporal logic model checking will be added in the near future. Combination A combination of translation and a new/extended model checker is used. 3.2 Complex States In order to ensure termination during explicit state model checking it must be known when a sate is revisited. It is common for a hashtable to be used to store states, which means an efficient hash function is required as well as fast state comparison. In the JPF2 approach the states of the JVM are kept in a complex data-structure in order to determine if they have been visited before. Each state consists of three components: information for each thread in the Java program, the static varaibles and the dynamic variables in the system. The information of each thread consists of a stack of frames, one for each method called, whereas the static and dynamic information consists of information about the locks for the classes/objects and the fields in the classes/objects. 2

4 To make the storing of states more efficient each component of the JVM state is stored seperately in a table, and the index at which the component is stored is then used to represent the component. This has the effect of encoding a large structure into no more than an integer. Fast state comparison is possible, because only the indeces need to be compared and not the structures themselves. JPF in its current state already illustrates that software systems with complex states can be efficiency analyzed. 4 Curbing the State-explosion Maybe the most challenging part of model checking is reducing the size of the state-space to something that could be handled. So model checking is augmented with information gathered from other techniques in order to handle large programs. Specifically, abstract interpretation, static analysis and runtime analysis is used for more efficient model checking of Java programs. 4.1 Abstraction The basic idea underlying abstraction algorithms is that user specifies an abstraction function for certain parts of the data-domain of a system, and the model checking system then either automatically generates a state-graph over the abstract data or automatically generates an abstract system, that manipulates the abstract data. Ths generation of the state-graph can be more precise at the price of calling the decision procedures troughout the model checking process. An automated abstraction tool, that takes a Java program as input and, by using the Stanford Validity Checker (SVC), has been developed. With respect to user-defined predicates, another (abstract) Java program that operates on the abstract predicates will be generated. For example: x++ x == 0 Abstract.addBoolean( B, x == 0) if (B) then B = false else B = Verify.randomBool() original statement abstraction predicate (in code) abstracted code The abstraction tool is designed for object-oriented programs and the user can specify abstraction criteria. It can be used for abstracting subcomponents in a program and the user can specify abstract variables which depend on variables from different classes (inner-class abstraction). 4.2 Static Analysis Static analysis as program reduction technique has a wide range in software engineering. Specifically, slicing can be a useful way of reducing program size to allow more efficient model checking. JPF uses the slicing tool of the BANDERA toolset to reduce Java programs. The slicing criteria are automatically extracted. JPF also uses static analysis to compute information to perform partial-order reduction during model checking. Partial-order reduction techniques ensure that only one interleaving of independent statements is executed within the model checker and achieve an enormous state-space reduction. Model checking of program will not be tractable in general if partial-order reductions are not suppurted. 4.3 Runtime Analysis Runtime analysis is conceptually based on the idea of executing the program once, while observing the generated execution trace to extract various kinds of information. This information can then be 3

5 used to predict whether this trace or other different execution traces may violate some properties of interest. These algorithms typically will not guarantee that errors are found since they work on an arbitrary trace. They also may yield false positives. However, such algorithms scale very well, and they often catch the problems they are designed to. An example implemented in JPF is the data race detection algorithm Eraser. A data race occurs when two concurrent threads access a shared variable and when at least one access is a write, and the threads use no explicit mechanism to prevent from simultaneous accesses. Another example of runtime analysis algorithm is the locking order algorithm, which looks for potential deadlocks by detecting differences in the order in which threads take locks. A classical deadlock situation can occur then one thread accesses two locks in one order, while another thread accesses then in the reverse order. The algorithm searches for the violation of such orderings. Runtime analysis can be used in two models within JPF. It can first of all be used stand-alone in simulation mode. Second, runtime analysis can be used to guide the model chekcer. 5 Example: The Remote Agent Spacecraft Controller The Remote Agent (RA) is an AI-based spacecraft controller that has been developed at NASA Ames Research Center. It consists of three conponentes: a Planner that generates plans from mission goals; an Executive that executes the plans; and finally a Recovery system that monitors the RAs status, and suggests recovery actions in case of failures. Hence, the Executive contains multi-threaded features and exchanges interactive messages with the Planner, this system is highly vulnerable to multi-threaded errors. On this system a combination of code review, abstraction, and model checking to identify a known error has been applied. In the following there will be described the abstraction and the runtime analysis to reduce the state-space in order to find the known error in the RA. The major two components to be modeled were events and tasks: class Event int count = 0; public synchronized void wait_for_event() try wait(); catch( InterruptedException e ) ; public synchronized void signal_event() count = count + 1; notifyall(); class Planner extends Thread Event event1, event2; int count = 0; public void run() count = event1.count; while( true ) if( count == event1.count ) event1.wait_for_event(); count = event1.count; 4

6 /* Generate plan */ event2.signal_event(); 5.1 Applying Abstraction Due to the repeated increment of the count variable the program has theoretically infinitely many reachable states. To remove this Abstract.remove(counter) has been specified and for instance Abstract.addBoolean( EQ, count == event1.count ) has been put in the definition of the class Planner. With this annotations a new abstracted program is generated by the abstraction tool. JPF thereafter reveals a deadlock in this abstracted program. The solution is to enclose the conditional wait in a critical section such that no events can occur in between the test and the wait. 5.2 Applying Runtime Analysis The abstract Java model was created based on a suspicion about the source of the error obtained during code review. The source of the error, a missing critical section, could, however, have been found atomatically using the Eraser data detection algorithm. The variable count is accessed unsynchronized by the by run method in the class Planner. When running JPF in Eraser mode it detects this race condition immediately. To illustrate JPFs integration of runtime analysis and model checking, extra threads had been added to make it slightly more realistic, so that it had more than states. JPF applied in runtime analysis mode immediately identified the race condition. This illustrates the philosophy of integrating techniques from different disciplines: abstraction turns an infinite program to a finite one, slicing reduces it, and the model checker analyzes the result. 6 Conclusions So it has been depicted why sofware engineering should devote some efforts in using formal methods to the analysis of systems in real programming languages. It also has been described how this philosophy had been applied to the analysis of Java programs. Furthermore it has been shown that augmenting model checking with abstraction, static analysis and runtime analysis can lead to efficient analysis of complex (Java) software. Since there is drawing on different techniques and the synergy between them it should be clear that many areas for future research exists. 5

Model Checking Programs

Automated Software Engineering, 10, 203 232, 2003 c 2003 Kluwer Academic Publishers. Manufactured in The Netherlands. Model Checking Programs WILLEM VISSER RIACS/NASA Ames Research Center, Moffet Field,