McErlang: A Model Checker for a Distributed Functional Programming Language

1
McErlang A Model Checker for a Distributed
Functional Programming Language

• Hans Svensson
• Chalmers University of Technology
• Lars-Åke Fredlund
• Universidad Politécnica de Madrid
• ICFP 2007, Freiburg 2 Oct. 2007

2
Erlang

• Functional programming language
• Concurrency oriented
• Lightweight processes
• No shared memory
• Communication via asynchronous message passing
• (Almost) transparent distribution
• Powerful supervision primitives

3
Model Checking
Model
OK
System
Model checker
Specification
Counter example

• Establish program correctness
• System modeled by states and actions

4
Model Checking Programs

• What do we need to model check a program
• against a correctness property?
• Compute state transitions for a state s
• Compare program states for equality
• Inspect states and/or actions to detect property
  violations
• Here we do explicit state model checking

5
Model Checking Erlang programs

• Transitions occur between stable states
• A process is stable
• When it has just been spawned
• When it is waiting in a receive statement
• Actions are exactly the side effects that are
  caused by a process between stable states
• Message passing
• Disk write, network interaction, etc

6
McErlang model checking approach

• The lazy solution Execute Erlang functions in
  Erlang
• The catch We need access to the combined
  resulting system state
• Ideally Extract system state (processes, queues,
  function contexts) from the Erlang Runtime
  System. However
• We have plenty of excuses not to mess with the
  Runtime System (written in C, distributed,
  complex, level of detail, etc)

7
Erlang System State
N2
P3
N1
Ether

• Node
• A collection of running processes
• A register with symbolic process names
• A set of links between processes

• System state
• A collection of nodes
• Messages in transit between nodes (Ether)

• Process
• Executes some expression
• Identified by a Pid
• Has a queue of incoming messages

8
A new Runtime System

• We have developed a new simplistic runtime
• system for Erlang (module evOS)
• No reflection in Erlang ? a (straightforward)
  source-to-source transformation is needed
• Calls to old API replaced by calls to evOS
• Replace blocking receive statements
• Most of the complexity in McErlang lies in the
  accuracy of the runtime system
• The semantic model is fully documented1

1. H. Svensson and L-Å Fredlund, A more
accurate semantics for distributed Erlang. Erlang
Workshop 2007
9
McErlang model checking

• Pure functions executed by the standard Erlang
  interpreter
• Functions with side effects are executed by the
  new API functions by the standard Erlang
  interpreter
• Global system state is easily accessible
• Checking state equality is trivial ()
• Full control of system execution we can break
  communication links, kill processes, etc

10
Property Checking

• We need a language for properties Erlang!
• We use monitors, implemented as
• monitor(State,OldMonState).
• The monitor has full access to the current state
  (and the actions leading to the state).
• If there is no violation of the property a new
  monitor-state is returned.
• For liveness-properties, states are marked as
  accepting/non accepting.

11
McErlang workflow
Program
Property (Monitor)
Environmental constraints
McErlang
Counter example
Property holds
12
Modularity of McErlang

• Source language
• Transitions
• Commit
• Algorithm
• Safety
• Liveness
• State table
• Abstractions
• Property

McErlang
13
Abstraction

• Important ingredient in model checking
• Reduces the checked state space
• General abstractions
• Hash value, etc
• Program specific abstractions
• Boolean abstractions, etc
• In general safety can not be guaranteed
• Any abstraction that can be expressed in Erlang
  can be used in McErlang

14
Results

• Resource manager (not fault tolerant)
• Comparing McErlang to etomcrl
• The generated state spaces was equally large
• McErlang is 2-5 times faster
• Distributed leader election
• Search for known errors
• Error only present in distributed setting
• Counter example including 50 states is found in
  a few seconds
• Looking for the shortest possible counter example
  takes around 20 minutes and explore over 10
  million states

On a very modest workstation with a 2.4 GHz
Pentium4 processor and 1GB memory.
15
Summary

• Lightweight everything-in-Erlang approach
• Support for a large language subset
• Full support for distribution and fault tolerance
• Modular implementation
• Clearly separated input
• Expressive specification and abstraction language

16
Road map

• Partial order reductions
• Special treatment of standard Erlang components
• Add support for a smaller-step semantics
• Library of state abstractions
• Support for more Erlang constructions (ports,
  etc.)