Presentation is loading. Please wait.

Presentation is loading. Please wait.

FMuOS: Java PathFinder Model checking of Java programs Prepared by: dr. sc. Alan Jović Ac. year. 2014/2015.

Similar presentations

Presentation on theme: "FMuOS: Java PathFinder Model checking of Java programs Prepared by: dr. sc. Alan Jović Ac. year. 2014/2015."— Presentation transcript:

1 FMuOS: Java PathFinder Model checking of Java programs Prepared by: dr. sc. Alan Jović Ac. year. 2014/2015

2 Contents About Java PathFinder Structure of Java Pathfinder Program properties specification and checking Advanced topics and extensions About 2nd homework

3 ABOUT JAVA PATHFINDER P. MehlitzN. RungtaC. PasareanuW. Visser

4 What is Java Pathfinder? Java PathFinder (JPF) is a framework and tool set for formal verification of programs written in Java programming language using model checking JPF is a very complex framework that offers many possibilites for extensions ◦ “...the swiss army knife of Java TM verification” JPF is being developed by a team of NASA scientists in collaboration with a significant number of universities, individuals and companies throughout the world (alegedly more then two dozen of collaborators, including the Fujitsu company) At the moment, verification of Android application using several JPF extensions is a hot research topic JPF is an open source tool distributed under GPL license The main project (jpf-core) 200+ kSLOC + extensions The core of JPF is a virtual machine (VM) which is run on top of Java VM in order to enable model checking of user programs

5 Development of JPF-a 1999 - the projekt started by development of JPF as a translator for a subset of Java 1.0 language into the Promela language for the SPIN tool used in formal verification 2000 - re-implemenation of the system as a virtual machine for model checking (discovery of typical defects in concurrent execution) 2003 - introduction of extensions interface 2005 - the system becomes open code on the SourceForge website 2008 + - code improvements by taking part in the Google Summer of Code 2009 - the system was transfered to its own server that supports various extensions as well as Wiki pages: 2010+ - further improvements in system extensions and documentation

6 Why was JPF developed in the first place? Code coverage is an important property to verify in critical applications – e.g. orbiter launch (NASA) It was required that automatic encoding of UML statechart diagram into Java programs and then testing in order to discover whether all parts of the code are reachable If parts of the code are represented as program states, then we talk about reachability analysis In this particular case, the action checkSensors() testing sensors at the entrance of the state EarthOrbit, however, the exact variable earthSensorsOk/Failed is checked later – it is entirely possible that the action setMajorMode() resets sensors so that SafeHold state becomes unreachable

7 Why was JPF developed in the first place? The event lasJetisson() – separation of launch abort system (LAS) from craft lsamRendevous() – connect with second craft – it won’t work if lasJetisson() is not performed in the Second Stage state, however this is not ensured in the diagram Ascent and EarthOrbit module may have been developed by different engineers Assertions are introduced that should be satisfied: class OrbitOps {… void lsamRendezvous(){… assert !spacecraft.contains(LAS) : ”lsamRendezvous with LAS attached” … } … }

8 What can Java PathFinder do? JPF performs model checking over compiled Java applications (in the simplest case if checks only one class) – application that is being checked is called “System under Test” (SUT) SUT Java application can be written in three ways: 1.independent of JPF (the most common case) support of JPF – contain certain annotations used by JPF 3.dependent of JPF – written exclusively for JPF (rare case) Specification of properties that SUT should satisfy is done through JPF configuration (a set of configuration files) JPF generates a report in which the result of model checking is provided

9 When to use JPF? JPF is not suitable for use in sequential programs with small number of well-defined input values – unit tests are more suitable! JPF is mainly used for 1) exploring alternative executions and 2) execution inspection 1. Exploring alternative execution ◦ Scheduling sequences – concurrent applications are the most common reason of use because:  Defects such as deadlocks and races are usually subtle and difficult to find  Job scheduler is usually difficult to control from the testing environment. JPF is essentially the owner of job scheduler because JPF is a VM that explores all interesting scheduling combinations ◦ Variations in input data – JPF allows exploration of the set of input values which can be defined by heuristics (e.g. values on or above certain threshold), which is useful for writing testing drivers ◦ Environment events – program types such as Swing or web applications usually react to external events such as button press. These events can be simulated in JPF ◦ Program control flow choices - JPF systematically explores the control structure of the programs (branching instructions) by calculating the input values required in order to pass through every branch of code 2. Execution inspection ◦ In JPF, code coverage analyzers can be implemented or specific noninvasive tests can be performed that can discover conditions which are usually difficult to find (e.g. overflow, underflow)

10 What can JPF discover? The core of JPF-a ( jpf-core project) discovers so called “nonfunctional properties” – defects which VM can identify without the need for specification of any additional program properties. This includes: deadlock, races, uncaught exceptions (also Java’s assert checks). Manifestion of nonfunctional properties should not occur in any application Extensions of JPF discover various properties specified by the user – mainly using listeners – add-ons which enable strict monitoring of all actions performed by JPF, e.g. certain instruction executions, object creation, occurrence of certain program states and far more. A typical example is a specific race detector, which clearly identifies asynchronous access to shared variable in concurrent programs JPF enables reporting of complete execution history – trace, down to the level of single bytecode instruction, that lead to defect detection. This is particularly useful for understanding deadlock and similar situations that are difficult to detect by common testing

11 An example of race detection public class Racer implements Runnable { int d = 42; public void run () { doSomething(1001); d = 0; // (1) } public static void main (String[] args){ Racer racer = new Racer(); Thread t = new Thread(racer); t.start(); doSomething(1000); int c = 420 / racer.d; // (2) System.out.println(c); } static void doSomething (int n) { // not very interesting.. try { Thread.sleep(n); } catch (InterruptedException ix) {} } Two threads are accessing the same variable d. Division by zero occurs when the second thread (the one created from the first one inside of main method) executes instruction (1) before the first thread executes instruction (2). If the first thread executes instruction (2) first, the division will be find (the result is 420 / 42 = 10) Without any additional configuration, JPF will find the uncaught exception: java.lang.ArithmeticException – division by zero With configuration (using PreciseRaceDetector listener), JPF will give exact code lines (1) and (2) that cause the race.

12 How does Java PathFinder work? JPF is a virtual machine which executes our SUT not only once (as Java VM does), but in all possible ways, checking whether deadlocks occur, or whether uncaught exceptions happen If defect location is found, it will report about every step from the start to the place of the defect In the common way JPF is used ( jpf-core ), JPF is an explicit state model checking tool. This means that it memorizes: ◦ specific local variable values ◦ thread stack frame ◦ heap objects ◦ thread states Explicit state model checking leads to state explosion problem

13 Java virtual machine internals These two areas are shared by all threads

14 Java virtual machine internals Class files – compiled code – intermediate code (bytecode) of application classes with additional informations Class loader subsystem – mechanism for loading types (classes and interfaces) given with fully qualified names (e.g. java.awt.Rectangle) Runtime data areas – memorijski prostori koje organizira JVM (ovisno o implementaciji VM) ◦ Method area – contains information about class methods, attributes and others ◦ Heap – a space in memory used for storing objects, reserved when starting VM, garbage collector operates over it ◦ Java stacks and PC register – each thread, when it is created, it obtains its own stack and program counter (PC register). The stack is organized into stack frames, each frame is a single method call – arguments of the call, return value, local variables and intermediate results are stored; PC register shows the next instruction which will be executed ◦ Native method stack – threads that execute native methods (methods dependent on the operating system), they have a separate stack reserved for these methods Execution engine – mechanism for bytecode instructions execution

15 Thread states in Java Thread scheduler of JVM controls thread execution sequence, here the priority of the thread plays and important role The thread ends after exiting its run() method

16 Thread states in Java Critical section (monitor) in Java can be a method or a block of instructions that have synchronized keyword written in front, e.g. synchronized(obj) { while ( ) obj.wait();... // Perform action appropriate to condition } Thread that calls wait() or notify() or notifyAll() has to be found in the critical section (so called monitor owner) By calling wait(), a thread stops being an owner of the monitor and waits until another thread calls notify() By calling notify(), a single thread is picked that was waiting for the monitor and that thread will now continue to compete for critical section execution when the current thread is done with it By calling notifyAll() all threads are awoken that are waiting over an object’ts monitor and then they continue to compete

17 “Solving” state explosion problem in JPF – state space reduction The first way: state matching ◦ Each time JPF gets to branching instruction, it checks whether it has already explored the same program state. If it has, then it can safely abort further search and backtrack to a point in which there are still unexplored paths (nondeterminism) and resume execution. In this way, JPF actually restores previous program state completely, which would be similar to a debugger going backwards by N instructions! The second way: partial order reduction ◦ Namely, in concurrent execution of transition between states, it is possible that different sequences of program execution lead to the same states. In that case, JPF tries to reduce the number of context switching between threads that do not lead to new interesting states by grouping in the same transition all instruction sequences which do not cause effects outside of a single thread. This is performed without prior analysis, at execution time, by tracking instructions that could lead to problems in threads interaction – these are those that are relevant for scheduling (e.g. synchronized methods) or the ones that simulate non-determinism ◦ More at: The third way: delegation of method execution to JVM, the ones that are known to not influence the verification procedure (e.g. System.out.println() )


19 JPF and program execution JPF can be understood as a separate VM performed above our installed JVM for a specific operating system (OS) (host JVM) JPF determines by itself which parts of our program it processes, and which parts are being delegated to the host JVM Effectively, JPF significantly slows down the execution of our program (SUT), because it adds a layer above the existing JVMa SUT – a collection of our *.class files with compiled bytecode + any libraries inside JPF that our files use. Our application uses standard Java installation in order to work, just like JPF. rt.jar ends up both in JPF classpath and in host JVM classpath. Both VM and JPF execute their own class instances. Some of them are different in JPF in relation to host JVM (e.g. Java.lang.String)

20 Structure of JPF Our application (*. class) files JPF libraries used by our application Standard JPF packages (part of jpf-core ) Extensions to jpf-core (e.g. jpr-aprop ) The set of configuration files

21 Principal structure of jpf-core folders

22 Structure of src folder Folder that contains JPF source code Divided into subfolders: ◦ Main  Packets containing classes essential for jpf-core functioning (e.g. state space search packets, VM execution, listeners, etc.). These are performed on the host JVM (as specified in JPF native_classpath ) ◦ Peers  Native peer classes – Packets with other classes that contain methods implementation that redirect execution to host JVM (as specified in JPF native_classpath ) ◦ Classes  Model classes – Classes performed directly on the JPF VM, these can be used (imported) by our application (these are specified in JPF classpath) ◦ Annotations  These contain Java annotations (starting with “@”) that should be processed by JPF. Our programs can use these annotations (e.g. @JPFConfig, @FilterField). ◦ Examples  Contains SUTs and the corresponding specification (configuration) files ◦ Tests  Constains typical test cases for a large number of standard Java classes and JPF classes themselves

23 Structure of build folder Similar to src folder (division into six subfolders) The build folder is created by building – compiling and combining all source files ( *.java ) from the src directory For that purpose, the Ant build system is used – there is an already written Ant build script for building JPF that is just executed; the best way is directly from the IDE (e.g. NetBeans) or from the Ant itself The most significant file for starting JPF is the Java- executable file RunJPF.jar which can be found in the root of the build folder

24 Other significant folders Folders nbproject and eclipse ◦ Contain files for configuration and starting jpf- core in Eclipse and NetBeans IDEs Folder lib ◦ Here can be put additional libraries to be used aside jpf-core (e.g. JUnit for testing) Folder doc ◦ Documentation of jpf-corea in textual format (*.md readme files)

25 The main content of the main subfolder – the core part of jpf-core Classes Search and JVM are the most important ones JVM produces program states Search is a driver over JVM which enables program state search For searching, various strategies (e.g. DFSearch, RandomSearch) and heuristics are used, depending on the specification


27 Program properties specification and checking Specification of properties that should be checked (model checking) in JPF is not as simple as in other systems (e.g. NuSMV) Specifications in temporal logics are not given, but rather program properties that should be checked are given (e.g. Nonnull, Deadlock...) JPF is highly configurable, which allows great extendability of the system, however the main disadvantage is the high complexity of configuration Different parts of the system can have their own different parameters (e.g. search strategy, listeners, instruction sets...) With this, a configuration object having predefined input parameters is deemed impossible

28 Program properties specification and checking The idea is to have a configuration object that: ◦ is based on Strings ◦ is expandable at will ◦ Is transfered in a top-down manner in a hierarchical process so that each component extracts only its own requested parameters The configuration object is achieved by the class gov.nasa.jpf.Config, and it uses notification of further classes when any of the parameters is added / changed Further classes check the parameters, and if they assert that they are responsible for their processing, they continue with their work using the parameters The system configuration is achieved on four levels: ◦ The whole installation on the computer ◦ The project installation (for each JPF component installed) ◦ Application specific (SUT) ◦ Command line arguments (if needed) A lower level can always overpower the properties of a higher level!

29 Configuring the whole installation The file with parameters for the whole JPF installation is called and it should be found at the default location /.jpf/ It is a usual Java properties file, which means that most properties are defined based on the principle: = This file describes to the JPF during startup where to look for for the projects related to JPF that are installed in order to set their corresponding classpaths, so that a user would not have to write each of them down every time at startup file has to be written manually during first installation of JPF, because otherwise JPF simply would not work

30 Configuring the whole installation An example of file: # JPF site configuration jpf.home = ${user.home}/projects/jpf # can only expand system properties jpf-core = ${jpf.home}/jpf-core extensions=${jpf-core} # annotation properties extension jpf-aprop = ${jpf.home}/jpf-aprop extensions+=,${jpf-aprop} # numeric extension jpf-numeric = ${jpf.home}/jpf-numeric extensions+=,${jpf-numeric} We define the location jpf.home The location of jpf.core installation extensions defines all extension (all installed projects). In newer versions of JPF extensions is not necessary to include explicitly in Locations of other project that need to be considered Notice: other projects can be listed in even though they are not installed. JPF will simply ignore them. Our SUT project does not have to be listed in the file, it is only used for JPF!

31 Configuring project installation Each project in JPF (including jpf-core and all extension), contains in its root folder the file In this file, all parameters and specification characteristic to the project as a whole are listed Typically, here we find classpaths to all JPF applications that the project contains, and other project specific parameters Project made by a user that will be SUT can also contain the file, but it is not obligatory The files are executed in the sequence that is determined by the file, with the exception if JPF is started within a specific project, in which case, the file of the project takes precedence specification can always overpower the specification given in, but the relevant thing is that the two files are mutually consistent, which means that the project names are equal (e.g. “ jpf-aprop ” has to be the same both in and )

32 Configuring project installation An example of the file: jpf-aprop = ${config_path} #--- path specifications jpf-aprop.native_classpath = build/jpf-aprop.jar;lib/antlr-runtime-3.1.3.jar jpf-aprop.classpath = build/examples jpf-aprop.test_classpath = build/tests jpf-aprop.sourcepath = src/examples #--- other project specific settings listener.autoload=${listener.autoload},javax.annotation.Nonnull,... listener.javax.annotation.Nonnull=gov.nasa.jpf.aprop.listener.NonnullChecker The first property always defines the name of the project, {config_path} is always expanded with the name of the folder where is found Path to classes that will execute programs, It has to be visible to the host JVM Path to folder with examples (SUT) Path to folder with common tests Path to folder that contains source code, which is used if JPF needs to generate program trace Setting additional project specific properties for the jpf-aprop project, specifically in this case, a listener will be loaded that will check @Nonnull annotation property. Now, it is not necessary to include in the application (SUT) configuration files this particular listener!

33 Configuring application specific (SUT) properties The path to the folder containing SUT.class files is usually defined in the file (.classpath property) Configuration of properties specific for particular SUT is given in a *.jpf file which can be found anywhere, but is usually placed in the same folder where the program source that is being checked is found It is common to give the name to this file so that it corresponds to the name of the application class that is checked, e.g. oldclassic.jpf and, but this is not a necessary condition In order to start the JPF, in the *.jpf file, it is obligatory to define which is the main class of the application (the one that contains the main method) that has to be executed (the key target ) Arguments of the static method main of the main class can be provided (key target_args ) Beside that, a set of properties is listed that specify in what way do we wish to check our application (listeners, search strategies, way and order of reporting...)

34 Configuring application specific (SUT) properties Example of the SUT properties file (shortened) RobotManager.jpf #--- dependencies on other JPF modules @using = jpf-awt @using = jpf-shell #--- what JPF should run target = RobotManager #--- other stuff that defines how to run JPF listener+=,.listener.OverlappingMethodAnalyzer cg.enumerate_random=true “@using= ” is instruction to JPF to load file of the given project (which has to be defined in file ). In this way, the need for listing extensions in the file Defining main target class of the application that is started in order to perform model checking Additional listeners to the ones in files taken into consideration. This particular listener is found in jpf-core : gov.nasa.jpf.listener.OverlappingMethodAnalyzer Specification of properties to enumerate all possibilities during random choice that appears insider a program(e.g. Random.nextInt(2); will give two options: 0 or 1). The key cg.enumerate_random is tested in Native peer JPF_java_util_Random of jpf-core

35 Configuring properties through command line All upper hierarchy parameters can be overpowered In this case, the most common is to add properties using notation +=, but other notations are also possible, see: ki/user/config (the part: Special Property syntax) The most flexible, but mostly unnecessary solution except in the case of debugging of JPF itself You should know what you are doing

36 An overview diagram of configuration files (with examples)

37 Reports For generating the final report about model checking of programs JPF uses: ◦ The Reporter class ◦ The Publisher classes, which types depend on specification of the type of reporting ◦ Classes that extend publishers – PublisherExtensions – specific publishers for specific properties

38 Reports Reporter controls and notifies publishers when certain report stage is reached (start, property_violation, finish) Stage property_violation has specific reporting topics: ◦ error – shows type and and details of property violation that is found ◦ trace – shows program trace which leads to property violation ◦ snapshot – provides a list of states for each thread at the moment of property violation ◦ output – shows the program output for the trace Stage finish has set, by default, reporting topics: ◦ results – shows whether property violation happened and gives a short list of defects ◦ statistics – shows overall statistics of JPF execution on the SUT Publishers produce system output depending on the wanted form (e.g. text, XML). The common publisher is ConsolePublisher ( report.console.* for reporting into the console in the textual form) For each symbolic name of the publisher and report stage, one has to specify in which order are the topics shown (in *.jpf file): Primjer: report.console.property_violation=error,trace,snapshot


40 Advanced topics and JPF extensions Listeners Choice generators Anotation properties checking – jpf- aprop

41 Listeners The most important mechanism of extension in JPF They enable a way for observing, interaction with and extending JPF execution There is a larger number of developed listeners for various purposes so an average user usually has no need to develop their own listeners, just include them in the configuration files The listeners are Observers that react to specific event during search ( SearchListener ) or JVM funcioning of JPF (VMListener ) They are configured by listing properties listener in file if they are valid for the whole project, or in *.jpf file (most commonly), or through the command line JPF also starts the corresponding listener when it encounters @JPFConfig annotation in the source file

42 Listeners In implementational sense, specific listeners usually inherit a single Adapter class which contains empty implementations of corresponding methods of interfaces VMListener, SearchListener and others (e.g. NullTracker extends ListenerAdapter ) and then override those methods for which they are interested in ListenerAdapter is used for collecting information about JPF execution so it will be used by listeners such as CoverageAnalyzer, DeadlockAnalyzer and NullTracker PropertyListenerAdapter is used when a listener implements certain program property related to search (e.g. PreciseRaceDetector, NoStateCycles )

43 Choice generators Model checking has the assignment to arrive at interesting program states constrained by scarce resources that it has at its disposal ChoiceGenerators is a JPF mechanism that it systematically explores state space in order to found solution Many existing choice options: thread scheduling, data values, control flow of the programs Mechanism of corresponding choice generator and heuristic parameters is detached from the SUT – it is listed in the configuration file as a property with the corresponding name together with other properties

44 Choice generators In order to reduce the number of possibilities when checking int, double and other variable types, search heuristics are introduced

45 Choice generators Caution: using heuristics moves one away from the fundamental (but idealistic) request in model checking: that all paths through the program are being checked, in this case only the interesting paths are checked (interest is a subjective criterion!!!) Internally, in JPF, choice generators enable choice in the process of thread scheduling of our program that is performed in JPF as bytecode ( ChoiceGenerator and ThreadChoiceGenerator ) More details:

46 Checking annotation properties Project jpf-aprop represents jpf-core extension with the purpose of model checking of specific program annotation properties A general idea is that SUT can be executed aside from JPF, entirely independent of JPF, because annotating certain program properties would not prevent program compilying and program build If, in a certain moment, one wants to check annotation properties, the corresponding listeners will be given in *.jpf configuration file and the program will be able to be checked In ideal case, these annotations are useful even for program documentation and it can be processed with certain tools for static code analysis In implementation, before SUT compiling, one has to import corresponding classes for given annotations and include a program library called jpf-aprop-annotations.jar in which a list of annotation classes is given

47 Checking annotation properties Structure of jpf-aprop is similar to jpf- core project, only jpf-aprop is significantly smaller and has a simpler file Annotation properties cover the following tasks: ◦ Unallowed assignment of null values (@Nonnull) ◦ Contracts (@Requires, @Ensures, @Invariant) ◦ Field access thread safety properties (@GuardedBy) ◦ Object mutability (@Const) ◦ and others…


49 Instalacija JPF-a 1. Installation of Java and NetBeans IDE 2. Installation of Mercurial DVCS 3. Cloning repository ( jpf-core ) from Mercurial 4. Building project jpf-core using Ant script build.xml 5. Making of file 6. Installation of NetBeans plugin for model checking (“Verify...”) 7. Ready!

50 About 2nd homework JPF installation The homework is divided into 4 sections: “The purpose of the 1. part of the 2. homework is acquainting oneself with the jpf-core project and starting model checking of simple program examples. In the 2. part of the homework additional listeneres are introduced that extend basic functionality of jpf-core project. The 3. part of the homework covers model checking over examples from jpf- aprop project, which is the additional project that can be used for model checking various annotations in programs. Finally, in the 4. part of the homework the students will make their project from scratch, include the use of jpf-core project and jpf-aprop projects and check the model of the given program with constant changes to the program.”

51 What we did not talk about Model Java Interface (MJI) ◦ Mechanism for redirecting method execution from JPF to JVM and within JPF. ◦ Bytecode factories ◦ How JPF internally processes program bytecode instructions ◦ Logging ◦ Recording errors with respect to severity in a log ◦ ◦ Symbolic Pathfinder ◦ Executing programs using simbolic (limited numeric) values of input variables based on code analysis – it is mostly used for automation of testing ◦ A large number of other extensions: ◦

52 Conclusion JPF is an advanced and extendable framework for model checking Java programs It extends Java VM with its own VM, which enables undisturbed transiting through program states It uses several techniques for state search Relatively complex project configuration which enables extensibility, but also complicates use

Download ppt "FMuOS: Java PathFinder Model checking of Java programs Prepared by: dr. sc. Alan Jović Ac. year. 2014/2015."

Similar presentations

Ads by Google