Monitoring Programs using Rewriting Information Sciences & Technology Monitoring Programs using Rewriting Klaus Havelund Kestrel Technology Grigore Rosu RIACS NASA Ames Research Center

A multi-language solution: Java, C, C++. Project Goal Observations: Traditional formal methods solutions to program correctness require high amounts of computer memory and time in addition to manual assistance. Testing is still the most used way to verify software. Goal: Combine formal methods with testing in a lightweight manner. A multi-language solution: Java, C, C++.

Program Monitoring Specification based monitoring: Specification given in a high level specification language Events are interpreted against specification When the specification is violated, a warning is issued Predictive monitoring: From one trace predict properties about other traces Examples: Datarace potentials : Keep a lockset for each variable (Eraser) Deadlock potentials : Keep a lockgraph and detect cycles Look for a bug’s footprints instead of looking for the bug

PathExplorer Observer Event stream Running program socket

… PathExplorer deadlock … dispatcher Standard input datarace … paxrules rule deadlock =‘java pax.Deadlock’; rule datarace =‘java pax.Datarace’; rule temporal =‘java pax.Temporal spec’; end deadlock warning … dispatcher Standard input datarace warning … temporal warning … Event stream = character stream …

Code Instrumentation Jtrek used for Java bytecode instrumentation. Gives access to class files as abstract syntax trees Allows to browse bytecode instructions and to insert new event transmitting instructions. Instrumentation is automated guided by instrumentation scripts telling what to instrument. Monitoring applied to a 70,000 lines of C++ Rover controller For deadlocks: Interface module to POSIX threads instrumented Deadlock found For data races: manual instrumentation of selected variable accesses. Suspicion about race condition confirmed For specification based monitoring : manual instrumentation tried.

Concrete and Abstract Events for Specification Based Monitoring class Light{ int color; void goRed(){ color = 1; } … Program predicate red = (Light.color == 1); predicate yellow = (Light.color == 2); prediacte green = (Light.color == 3); Instrumentation Script property p = [](green -> !red U yellow); Specification

Java Bytecode Instrumentation class Light{ void goRed(){ color = 1; } … program predicate red = (Light.color == 1); predicate yellow = (Light.color == 2); prediacte green = (Light.color == 3); Instrumentation Script compile byte code instrument property p = [](green -> !red U yellow); Specification instrumented byte code execute green yellow red green … Java Virtual Machine

Maude Specification and verification system In the OBJ family Algebraic specification Signatures + equations Mixfix notation Easy to define syntax of new logics. Fast rewriting Efficient semantics for monitoring.

Propositional Logic in Maude fmod PROP-CALC is sort Formula . op true : Formula . op false : Formula . op _/\_ : Formula formula -> Formula . op _++_ : Formula formula -> Formula . … eq X /\ (Y ++ Z) = (X /\ Y) ++ (X /\ Z) . op _\/_ : Formula Formula -> Formula . op !_ : Formula -> Formula . op _->_ : Formula Formula -> Formula . op _<->_ : Formula Formula -> Formula . . … eq X <-> Y = true ++ X ++ Y . endfm .

Propositional LTL for Finite Traces [] P = always P <>P = eventually P P U Q = P until Q O P = next P [](green -> <> red) [](yellow -> o red) [](green -> !red U yellow) F ::= true | false | Id | F and F | F ++ F | []F | <>F | F U F | o F |= : Trace x F -> Bool t |= []X iff (FORALL I <= length(t)) t(I) |= X T |= X U Y iff (EXISTS I <= length(t)) t(I) |= Y and (FORALL j < I)t(j) |= X

Finite Trace Semantics versus Infinite Trace Semantics <>([]X or []!X) The formula: Is valid in a finite trace model but not in an infinite trace model. X or !X !<>([]X or []!X) The negated formula: Is satisfiable in an infinite trace model but not in a finite trace model.

Semantics of Finite Trace LTL in Maude fmod LTL is extending PROP-CALC . op []_ : Formula -> Formula . op <>_ : Formula -> Formula . op o_ : Formula -> Formula . op _U_ : Formula Formula -> Formula . vars X Y : Formula . var E : Event . var T : Trace . eq E,T |= []X = E,T |= X and T |= []X . eq E,T |= <>X = E,T |= X or T |= <>X . eq E,T |= X U Y = E,T |= Y or (E,T |= X and T |= X U Y) . eq E,T |= o X = T |= X . … endfm .

Performance of Semantics Polynomial O(m^n) in length of trace (m) and formula (n). For each event, the trace is copied into several sub-formulae: eq E,T |= X U Y = E,T |= Y or (E,T |= X and T |= X U Y) . Since traces of different sizes occur in new sub-formula Idempotency of boolean ‘and’ cannot be applied.

Towards and Improved Implementation Idea: maintain a set of proof obligations: those formulae that must hold in the future. A formula transforming approach: [](green -> !red U yellow) green !red U yellow and

Efficient Semantics in Maude fmod LTL-REVISED is protecting LTL . op _{_} : Formula Event -> Formula . vars X Y : Formula . var E : Event . var T : Trace . eq []X {E} = X {E} /\ []X . eq <> X {E} = X {E} \/ <>X . eq o X {E} = X . eq X U Y {E} = Y{E} \/ (X {E} /\ (X U Y)) . eq []X {last E} = X {last E} . eq <> X {last E} = X {last E} . eq o X {last E} = X {last E} . eq X U Y {last E} = Y {last E} . op _ |-_ : Trace Formula -> Bool . eq E,T |- X = T |- X{E} . eq E |- X = [X{last E}] . endfm .

Example P =[](green -> !red U yellow) {green} {yellow} fmod LTL-REVISED is eq []X {E} = X {E} /\ []X . eq <> X {E} = X {E} \/ <>X . eq o X {E} = X . eq X U Y {E} = Y{E} \/ (X {E} /\ (X U Y)) . endfm . P =[](green -> !red U yellow) {green} {yellow} = (!red U yellow){green} /\ P = (Yellow{green} \/ (!red{green} /\ !red U yellow)) /\ P = (false \/ (true /\ !red U yellow)) /\ P = !red U yellow /\ P {green} {red} = !red U yellow /\ !red U yellow /\P = (!red U yellow){red} /\ P = !red U yellow /\P = (yellow{red} \/ (!red{red} /\ !red U yellow)) /\ P = (false \/ (false /\ !red U yellow) = false

Using “memo” to Generate Automata Specialized to Trace fmod LTL-REVISED is protecting LTL . op _{_} : Formula Event -> Formula [memo] . … endfm . P =[](green -> !red U yellow) {green} !red U yellow /\ P false {yellow} {red} [](green -> !red U yellow){green} -> !red U yellow /\ P …. Hash Table

Correctness of Algorithm Theorem For any trace T and any formula X: T |= X if and only if T |- X Proved in Maude and in PVS

Evaluation [](a -> <>b) First Semantics: Second Semantics: 100 events : 30 ms (74 K rewrites) 1,000 events : 3 sec ( 7,3 million rewrites) 10,000 events : > 10 hours (did not terminate over night) Second Semantics: <= 10,000 events : << 1 sec 100,000 events : <= 3 sec 100 million events : 1,500 sec (4,9 billion rewrites) Second Semantics with “Memo” 100 million events : 185 seconds (230 million rewrites) [](a -> <>b) Conclusion: an algebraic specification environment such as Maude can be used not only for prototyping but also for final implementation.

An Alternative: Inline Expansion of Annotations /* JPaX: after green comes yellow Atom isRed = tlc.state.getColor() == 1; Atom isGreen = tlc.state.getColor() == 2; Atom isYellow = tlc.state.getColor() == 3; Formula : []( isGreen -> ( ! isRed U isYellow )); */ try { switch(bttFsmState) { case -1 : break; case 1 : bttFsmState = tlc.state.getColor() == 3 ? 1 : tlc.state.getColor() == 2 ? tlc.state.getColor() == 1 ? 0 : 2 : 1; break; case 2 : bttFsmState = tlc.state.getColor() == 3 ? 1 : tlc.state.getColor() == 1 ? 0 : 2; break; } if(bttFsmState == 0) throw new Exception("Prop. Failure"); } catch(Exception e) { System.out.println(e.getMessage() + String.valueOf(transCnt)); }

Conclusions Future time LTL: Past time LTL: Future Work Binary Transition Diagrams (automata) Modification of Buchi automata (Giannakopoulou) Dynamic algorithm going backwards: need to store trace Past time LTL: Defined in Maude in 130 lines Dynamic Algorithm (dual of the above, no storing of trace) Future Work Real-time logics Other error patterns for multi-threaded programs Scheduling (test case generation for multi-threaded programs)

RV’02 RV’01 : Paris, July 2001 Workshop Runtime Verification Second International Workshop on Runtime Verification RV’02 FLoC’02 July 20 – August Copenhagen 2002 Denmark RV’01 : Paris, July 2001 http://ase.arc.nasa.gov/rv