Arindam%20Chakrabarti

1
Interface Compatibility Checking for Software
Modules

• Arindam Chakrabarti
• Luca de Alfaro
• Thomas A Henzinger
• Marcin Jurdziñski
• Freddy Y C Mang
• UC Berkeley

2
Outline

• Motivation
• Example to show the method
• The method in detail
• Implementation issues
• Current and future work

3
Motivation

• Find more errors at compile time
• Focus incorrect call order
• What is a module ?

4
Example

• Brief description of TinyOS, an operating system
  for ad-hoc networked sensors
• The error in TinyOS
• How it can be detected

5
TinyOS Culler et. al.
6
RFM
RFM
Rx, Tx, LowPow
7
RadioByte
Radio Byte
Rx, Tx, LowPow
8
The Error
RadioByte
RFM
LowPow

9
The Error
RadioByte
LowPow
RFM
LowPow

10
The Error
RadioByte
LowPow
RFM
LowPow

11
The Error

• RBPower1 fails to call RFMPower1 before calling
  RxMode
• Makes RBPower1 unavailable at all states
• Once RB is powered down, it can never be powered
  up again

12
Whats the talk about ?

• We can find this at compile-time !
• We can work with open systems !
• We take the optimistic approach !
• Heres how !

13
Enter Interfaces

• Verify that module interfaces are compatible
• Verify that the interface matches the
  implementation
• Module interface a behavioral type for the
  module

14
The Model
Methods implemented in this module
Methods implemented by the environment
Local methods not called transitively
Interface states in which a local method is
available
15
Example
Var StateRx, Tx, LwPw Local interrupt
notcallinterrupt available atRx,Tx
if(state Rx) RxBitEv else if(state Tx)
choose() TxBitEv return
16
The Method

• Consider a pushdown automaton
• The control states consist of (interface
  state,program counter) pairs.

if(state Rx) RxBitEv else if(state Tx)
100
(Rx, 100) (Tx, 100) (LowPow,100)
17

• Assignment or choice statements are translated
  to skip rules.

(Tx,L1) (Rx,L2)
State Rx
L1
L2
skip
(Tx,L1)
(Rx,L2)
18

• Method calls translate to push rules.

L2
RxBitEv RxBitEv
L1
Push L2
(,L1)
(,L3)
L2
L3
19

• Return statements correspond to pop rules.

L
return
Pop L
L1
(,L1)
(,L)
20
The Game

• Environment gets control when an external method
  is called.
• Interface tries to violate availability
  constraints, the environment tries to prevent it.

21
Interface consistency

• Error state where availability constraint is
  violated
• Consistency criterion Environment has a
  strategy to never enter an error state
• Reachability game on PDA configuration graph

(LowPow,Loc(RxMode))
22

• For every local method we play a game, starting
  from appropriate PDA control states.
• A local method is usable at only those states it
  is available at, from where the environment is
  also able to avoid losing.

23
Implementation Issues

• Good news Pushdown reachability games can be
  solved.
• Walukiewicz gave a translation from (infinite
  state) parity pushdown games to finite state
  parity games.
• Bad news The problem is DEXPTIME-Complete.

24
Walukiewiczs approach

• For every PDA control state q 2 Q, every stack
  symbol g 2 G, and every subset s 2 2Q, make a
  state (q,g,s) in the finite game
• This state represents the (finite) information
  that starting from PDA control state q with g on
  top of stack, player 1 has a strategy to reach
  some state q 2 s, or pop g off the stack,
  without ever letting player 2 force him into an
  error state

25

• Edges are put in corresponding to edges in the
  pushdown configuration graph
• Correspondence of memoryless winning strategies

26
Our optimization for pushdown reachability games

• We do not need to explicitly construct
  exponentially bigger game
• Sets of states represented and manipulated
  symbolically
• Fixed point computation converges relatively fast

27
The Symbolic Approach

• For every PDA control state q 2 Q, and every
  stack symbol g 2 G, we keep track of SETS(q,g)
  the set of sets of PDA control states that the
  environment has a strategy to reach, starting in
  state q with g on top of stack

28

• If , the empty set of PDA control states, is in
  SETS(q,g) it means that player 1 can force the
  stack to be emptied, starting from q with g on
  stack.

29

• If q is a state where method m is available, and
  g is the return address for method m, then 2
  SETS(q,g) means that the invocation of m in state
  q (resulting in a possibly recursive sequence of
  method calls) will be error-free

30
Symbolic Solver

• If player 1 has a strategy to reach set
• S from B then he can use it to find a
• strategy to reach S from A.

31
In the following case player 1 has a strategy to
reach any superset of B from A.
32
If there exists a set U of game states which
player 1 has a strategy to reach from A by
popping g from stack, and for each u 2 U, player
1 has a strategy to reach S, then player 1 has a
strategy to reach S from A.
33

• SETS(A,g) SETS(A,g)
• 9 z1,z2, ,zn.(SETS(B,g)zi/xi Æ
• Æi1n (zi ) ) SETS(i,g)))
• Similar rules for player 2 8 (Æ) composition of
  rules instead of 9 (Ç)
• Observation Push, pop and skip rules do not
  have the same cost

34
Should have called RFMPower1 here first !
Prog RxMode available atRx,Tx RFMstate
Rx return
Prog RBPower1 available atLowPow RxMode
RBstate Rx return
RFM
RadioByte
35
Observation Code Correction

• Introduce an environment move between every two
  interface moves.
• The right thing to do can be automatically found
  from the winning environment strategy.

36
Results

• Module implementation 460 LOC, 8 variables (1
  byte each)
• Module interface lt50 LOC, 2 variables (3-value
  domain)

37
Implementation Status

• Symbolic solver implemented in Java.
• Composition of two TinyOS interfaces gives a
  game with 117 control states and 5 stack symbols.
• Game state space 11752117
• Solution takes 30 CPU minutes on 256MB RAM 200
  MHz dual CPU Sun workstation

38
Current and Future Work

• Type qualifiers and interfaces
• Faster solution of pushdown games
• Semi-automatic extraction of interfaces