Presentation is loading. Please wait.

Presentation is loading. Please wait.

Runtime Verification Ali Akkaya Boğaziçi University.

Similar presentations


Presentation on theme: "Runtime Verification Ali Akkaya Boğaziçi University."— Presentation transcript:

1 Runtime Verification Ali Akkaya Boğaziçi University

2 Motivation The Remote Agent Experiment During the May 1999 RAX mission, the satellite deadlocked in space, causing the ground crew to put the spacecraft on standby. Ariane 5 Flight 501 Airane 5 Flight 501 was destroyed 40 seconds after take off. The US$1 billion prototype rocket self-destructed due to a bug in the on-board guidance software

3 Motivation Air-Traffic Control System in LA Airport The controllers lost contact with the planes when the main voice communications system shut down unexpectedly. To make matters worse, a backup system that was supposed to take over in such an event crashed within a minute after it was turned on. The outage disrupted about 800 flights ac ross the country.

4  Introduction  Runtime Verification Tools  Java PathExplorer (JPaX)  Java MultiPathExplorer (JMPaX)  Conclusion  Further Study Outline

5  Runtime Verification is the study of monitoring and analyzing system executions to detect/recover faults.  Two important aspects of program verification are  Testing  Use of Formal Methods Runtime Verification

6 Testing Formal Methods Ideal Runtime Verification Scalibility Coverage

7 Runtime Verification Architecture Reaction Instrumentation Specification Code Monitoring Execution

8 while (true) { lock(r1); processShared(); unlock(r2); } while (true) { lock(r1); logLock(p,r1); processShared(); release(r2); logRelease(p,r1); } Instrumentation Execution Traces: lock(p1,r1) release(p1,r1) lock(p2,r1) release(p2,r1)

9  Dispatching of trace events to a set of specification rules.  Specification Language  Boolean Logic provides formulation of statements for a specific time.  Not sufficient to express time based changes in states Monitoring

10  If A happens now, B must happen   (A → ◊ B) Future Time Temporal Logic AB p ∧ q = p and q p ∨ q = p or q p → q = p implies q ¬p = not p  p = always p ◊ p = eventually p p U q = p until q

11  If A happens now, B must have happened   (A → ♦ B) Past Time Temporal Logic BA p ∧ q = p and q p ∨ q = p or q p → q = p implies q ¬p = not p ■ p = sofar p ♦ p = previously p p S q = p since q

12  Offline  Monitor does not run in parallel but runs after program  Online  Outline: Runs in parallel with program as an external entity.  Inline: Runs in parallel with program as embedded in the code. Monitoring

13  Action to be taken in case faults are detected  Error mesage  Exception  Seperate code execution  Integrated code execution Reaction

14  Java PathExplorer (JPaX)  Java MultiPathExplorer (JMPaX)  Temporal ROVER (Commercial)  Cadence, Synopsys, Mentor (Commercial HW Tools)  Java MaC  Partial Order Trace Analyzer (POTA)  …. Runtime Verification Tools

15 Java PathExplorer (JPaX)  Monitors Java programs by analyzing (exploring) particular execution traces.  The observer performs two kinds of verification  Logic based monitoring  Future Time Temporal Logic  Past Time Temporal Logic  Error pattern analysis  Deadlocks  Data Races

16 JPaX Architecture

17 Data Race Analysis class Value { private int x = 1 ; public synchronized void add(Value v) { x = x + v.get() } ; public int get() { return x ; } } class Task extends Thread { Value v1 ; Value v2 ; public Task(Value v1, Value v2) {this.v1=v1;this.v2=v2;this.start()} public void run(){v1.add(v2)} ; } class Main { public static void main(String [] args) { Value d1 = new Value() ; Value d2 = new Value() ; new Task(d1, d2) ; new Task(d2, d1) ; }

18 Data Race Analysis  Task 1 start() d1.lock.acquire() d1. add(d2) d1.x = d1.x + d2.get() R 1 = d2.get() = 1 d1.x = 1 + R 1 = 2  Task 2 start() d2.lock.acquire() d2. add(d1) d2.x = d2.x + d1.get() R2 = d1.get() = 1 d2.x = 1 + R 2 = 2

19 Data Race Analysis  Task 1 Task 2 start() d1.lock.acquire() Thread-map[Task1] = {d1.lock} d1. add(d2) start() d2.lock.acquire() Thread-map[Task 2 ] = {d2.lock} d2. add(d1) d1.x = d1.x + d2.get() Variable-map[d1] = {d1.lock} R 1 = d2.get() = 1 Variable-map[d2] = {d 1.lock} d1.x = 1 + R 1 = 2 d2.x = d2.x + d1.get() Variable-map[d1] = {} R2 = d1.get() = 2 Variable-map[d1] = {} d2.x = 1 + R 2 = 3

20 Deadlock Analysis class Value { private int x = 1 ; public synchronized void add(Value v) { x = x + v.get() } ; public synchronized int get() { return x ; } } class Task extends Thread { Value v1 ; Value v2 ; public Task(Value v1, Value v2) {this.v1=v1;this.v2=v2;this.start()} public void run(){v1.add(v2)} ; } class Main { public static void main(String [] args) { Value d1 = new Value() ; Value d2 = new Value() ; new Task(d1, d2) ; new Task(d2, d1) ; }

21 Deadlock Analysis  Task 1 start() d1.lock.acquire() d1. add(d2) d1.x = d1.x + d2.get() d2.lock.acquire()  Task 2 start() d2.lock.acquire() d2. add(d1) d2.x = d2.x + d1.get() d1.lock.acquire() Deadlock occurred!!

22 Deadlock Analysis  Task 1 Task 2 start() d1.lock.acquire() Thread-map[Task1] = {d1.lock} d1. add(d2) d1.x = d1.x + d2.get() d2.lock.acquire() Thread-map[Task1] = {d1.lock, d2.lock} d1.lock → d2.lock R 1 = d2.get() = 1 d1.x = 1 + R 1 = 2 start() d2.lock.acquire() Thread-map[Task2] = {d2.lock} d2. add(d1) d2.x = d2.x + d1.get() d1.lock.acquire() Thread-map[Task 2 ] = {d 2.lock, d 1.lock} d2.lock → d1.lock Cycle!! R2 = d1.get() = 2 d2.x = 1 + R 2 = 3

23 Possible Implementation class Value { private int x = 1 ; public void add(Value v) { x = x + v.get() } ; public int get() { return x ; } } class Task extends Thread { Value v1 ; Value v2 ; public Task(Value v1, Value v2) {this.v1=v1;this.v2=v2;this.start()} public void run(){ synchronized (lock) { v1.add(v2)} ; } class Main { public static Object lock = new Object(); public static void main(String [] args) { Value d1 = new Value() ; Value d2 = new Value() ; new Task(d1, d2) ; new Task(d2, d1) ; }

24 Possible Implementation  Task 1 start() lock.acquire() d1. add(d2) d1.x = d1.x + d2.get() R 1 = d2.get() = 1 d1.x = 1 + R 1 = 2 lock.release ()  Task 2  start() lock.acquire() d2. add(d1) d2.x = d2.x + d1.get() R2 = d1.get() d2.x = 1 + R2 lock.release()

25 Java MultiPathExplorer (JMPaX)  Monitors multithreaded Java programs.  The observer performs Logic based monitoring based on Past Time Temporal Logic  Have the ability to predict safety violation errors in multithreaded programs by observing successful executions.

26 JMPaX Architecture

27 Vector Clocks  Vector Clocks is an algorithm for generating a partial ordering of events in a distributed system and detecting causality violations. A A:0 B B:0 C C:0 C:1 B:1 C:1 B:2 C:1 A:1 B:2 C:1 A:2 B:2 C:1 B:3 C:1 A:3 B:4 C:1 B:3 C:2 B:3 C:3 A:3 B:3 C:3

28 Example  Suppose that one wants to monitor some safety property of the multithreaded program below. The program involves relevant variables x, y and z: Initially: x = −1; y = 0; z = 0; thread T1{... x++;... y = x + 1;... } thread T2{... z = x + 1;... x++;... }

29 Example

30 Multithreaded Safety Analysis  Checking safety against single run  Suppose we want to monitor “if (x > 0), then (x = 0) has been true in the past, and since then (y > z) was always false.” (x > 0) → [(x = 0), y >z)s (−1, 0, 0), (0, 0, 0), (0, 0, 1), (0, 1, 1), (1, 1, 1) -> satisfied (−1, 0, 0), (0, 0, 0), (0, 1, 0), (0, 1, 1), (1, 1, 1) -> not satisfied

31 Multithreaded Safety Analysis  Checking safety against all runs  The major hurdle in monitoring all possible runs is that the number of possible runs can be exponential in the length of the computation  The problem is avoided by traversing the computation lattice level by level.

32 JPaX vs JMPaX  JPaX uses total ordering of events  JMPaX uses partial ordering of events  In JPaX it is possible to reveal errors in multithreaded programs that are hard to detect by observing successful executions.  JMPaX extends JPaX

33 Conclusion  Runtime verification combines testing and formal methods to provide scalable solutions with bigger coverage.  Several academic and commercial tools available to be used for runtime verification.

34 Further Study  Other runtime verification tools.  Use of tools on small scale real-life problems.

35 References  “ Runtime Safety Analysis of Multithreaded Programs ”, Koushik Sen, Grigore Rosu, and Gul Agha.  “ Monitoring Java Programs with Java PathExplore ”, K. Havelund and G. Rosu,    

36 Thank you Questions ?


Download ppt "Runtime Verification Ali Akkaya Boğaziçi University."

Similar presentations


Ads by Google