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

2. 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++.

3. 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

4. PathExplorer
Observer
Event stream
Running program
socket

5. … 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 …

6. 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.

7. 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

8. 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

9. 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.

10. 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 .

11. 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

12. 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.

13. 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 .

14. 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.

15. 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

16. 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 .

17. 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

18. 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

19. 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

20. 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.

21. 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 ? : tlc.state.getColor() == 2 ? tlc.state.getColor() == 1 ? : 2 : 1; break; case 2 : bttFsmState = tlc.state.getColor() == 3 ? : tlc.state.getColor() == 1 ? : 2; break; } if(bttFsmState == 0) throw new Exception("Prop. Failure"); } catch(Exception e) { System.out.println(e.getMessage() + String.valueOf(transCnt)); }

22. 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)

23. 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