Development of Formally Verified Erlang Programs

a case study

Thomas ArtsClara Benac Earle

Computer Science LabStockholm, Sweden

Research question

how can we identify the hard-to-find errors in the code?

can formal methods help infinding errors not uncovered by testing?

AXD 301 Architecture

CP CP CP CP CP CP

Switch Core

DP

DP

DP

DP

DP

DP

DP

AXD 301 Call setup

AXD 301 Architecture

CP CP CP CP CP CP

Switch Core

DP

DP

DP

DP

DP

DP

DP

CP

OM

CP

OM

CP

OMCC CC CC CC

CPCCOM

AXD 301 fault tolerance

AXD 301 fault tolerance

CP

CC

CP CP CP CP

CC

CP

Switch Core

DP

DP

DP

DP

DP

DP

DP

CP

OM

CP

OM

CP

OM

CPCCOM

CP

OM

CP

CC

CP

CC

node

OM

nodeapp

appapp

app

Billing application

Take over

CP

OM

node

app

CP

CC

node

OM

node

Billing application

app

app

app

Take over

app

Billing application

CP

CC

node

OM

node

Billing application

app

appapp

app

Take over

take

ove

r

CP

OM

node

app

Billing application

Application lock

Some operations don’t like a takeover to happen; they can prevent a

takeover to take place.

distributed resource locker with shared and exclusive locks

CLIENTS RESOURCES

A

C

BLOCKER

CLIENT 1

CLIENT 2

CLIENT 3

ok

{request,[A],shared}

ok

{request,[A],exclusiv

e}

ok

{release}

done

{release}

done

{request,[A,B],shared} C1

C1

C2

C3

C3

example

-module(client).

start_link(Locker) -> {ok,spawn_link(loop,[Locker])}.

loop(Locker) -> gen_server:call(Locker,request), critical(), gen_server:call(Locker,release), loop(Locker).

examplestart_link() -> gen_server:start_link(locker,[],[]).

init([]) -> {ok,[]}.

handle_call(request,Client,Pending)-> case Pending of [] -> {reply, ok, [Client]}; _ -> {noreply, Pending ++ [Client]} end;

handle_call(release, Client, [_|Pending]) -> case Pending of [] -> {reply, done, []}; _ -> gen_server:reply(hd(Pending), ok), {reply, done, Pending} end.

Supervisor processes

standard supervision structure can be used to obtain initialization information for transition diagram

supervisor

supervisorlocker

gen_server

clientclient client clientclient

start supervision tree with 5 clients

supervisor:start(locker_sup,start,[5]).

Testing versus Verification

Thus, for one input, 100% coverage with verification

testing: many program runs on different inputverification: all runs on different input

verify:allruns(locker_sup,start,[8]).

Mutual exclusion(at most one client has access to resource)

-module(client).

start_link(Locker) -> {ok,spawn_link(loop,[Locker])}.

loop(Locker) -> gen_server:call(Locker,request), critical(), gen_server:call(Locker,release), loop(Locker).

io:format(“enter cs~n”),critical(),io:format(“exit cs~n”),

erlang:tracefor gen_server:call

testing

io client 2client 1

enter cs

exit csenter cs

enter cs

exit cs

enter cs

exit csexit cs

Verification:generate State Space

clients states transitions 2 14 18 3 53 75 4 230 344 5 1177 1805 6 7100 10980 8 398074 617216

Erlang -> transitionsstart verification with 2 clients

verify:allruns(locker_sup,start,[2])

ourToollocker.erl

client.erl

locker_sup.erl

client_sup.erl

ourTool

ourTool

ourTool

ourTool

EtoE rest tool

locker.erlclient.erl

init.erl

inst

antia

tion

Erlang -> transitionsstart verification with 2 clients

etomcrl:instantiator(locker_sup,start,[2])

locker.erlclient.erl

locker_sup.erl

client_sup.erl

locker.erlclient.erl

init.erl

inst

antia

tion tomcrl.erl

inst

antia

tion

EtoE rest tool rest toolrest toolrest toolrest toolEtoPmcrl

Erlang -> transitions

locker.erlclient.erl

locker_sup.erl

client_sup.erl

inst

antia

tion tomcrl.erl

inst

antia

tion

EtoE rest tool rest toolEtoPmcrl rest toolrest toolrest toolCWI toolinstantiator

locker.mCRL

toMCRL

start verification with 2 clients

etomcrl:instantiator(locker_sup,start,[2])

locker.erlclient.erl

init.erl

Erlang -> transitions

locker.erlclient.erl

locker_sup.erl

client_sup.erl

inst

antia

tion tomcrl.erl

inst

antia

tion

EtoE rest tool rest toolEtoPmcrl CWI toolinstantiator

locker.mCRL

toMCRL

start verification with 2 clients

etomcrl:instantiator(locker_sup,start,[2])

locker.erlclient.erl

init.erl

Aldebaran

locker.aut

State Space analysissimulation with backtrack possibilities

find execution sequencedeadlock check states in the graph without out-arrow

property check such as mutual exclusion

State Space analysis

Between two handle_call(request,_,_) there should be ahandle_call(release,_,_).

[-*,“handle_call(request,_,_)”, (not “handle_call(release,_,_)”)*, “handle_call(request,_,_)” ]false

Properties are specified as regular expressions over Erlang function calls in combination with [] and <> operators.

After a gen_server:call(locker, request) there is always a gen_server:call(locker,release) possible.

[-*,“gen_server:call(locker, request)”] < -*,“gen_server:call(locker, request)”>true

Conclusions

• We developed software to verify properties of Erlang programs

• We verified a resource locker program featuring multiple resources with shared and exclusive access (upto 6 clients in many different configurations)

• State space upto a million states (several techniques to reduces state space if property is given)

• Working on addition of Erlang constructs to cover more of the language (fault tolerance handling, gen_fsm)