230 likes | 331 Views
Development of Formally Verified Erlang Programs a case study. Thomas Arts Clara Benac Earle Computer Science Lab Stockholm, Sweden. Research question. how can we identify the hard-to-find errors in the code?. can formal methods help in finding errors not uncovered by testing?. CP.
E N D
Development of Formally Verified Erlang Programsa case study Thomas Arts Clara Benac Earle Computer Science Lab Stockholm, Sweden
Research question how can we identify the hard-to-find errors in the code? can formal methods help in finding errors not uncovered by testing?
CP CP CP CP CP CP Switch Core DP DP DP DP DP DP DP AXD 301 Call setup AXD 301 Architecture
CP OM CP OM CP OM CP CP CP CP CP CP CC CC CC Switch Core DP DP DP DP DP DP DP AXD 301 fault tolerance AXD 301 Architecture CP CCOM CC
CP CC node Billing application OM node app app app app Take over AXD 301 fault tolerance CP CC CP CP OM CP CP OM CP CP OM CP CC OM CP CC CP CC CP OM CP Switch Core DP DP DP DP DP DP DP
CP CC node OM node app app app app Take over take over Billing application
OM node app Take over CP CP Billing application CC node OM node app app app
Application lock During take over the respective application should not be used. distributed resource locker with shared and exclusive locks
CLIENTS RESOURCES {release} {request,[A,B],shared} C1 done ok {request,[A],shared} {release} C1 done ok {request,[A],exclusive} ok CLIENT 1 A C2 C3 C3 B LOCKER CLIENT 2 C CLIENT 3
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). simplified
example start_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 start supervision tree with 5 clients supervisor:start(locker_sup,start,[5]). supervisor locker gen_server supervisor client client client client client standard supervision structure can be used to obtain initialization information for transition diagram
Testing versus Verification testing: many program runs on different input verification: all runs on different input Thus, for one input, 100% coverage with verification 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:trace for gen_server:call
enter cs exit cs enter cs enter cs exit cs exit cs enter cs exit cs testing client 1 client 2 io
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
locker.erl our Tool client.erl init.erl our Tool our Tool our Tool our Tool EtoE rest tool start verification with 2 clients verify:allruns(locker_sup,start,[2]) Erlang -> transitions locker.erl client.erl locker_sup.erl client_sup.erl instantiation
locker.erl client.erl locker.erl client.erl init.erl locker_sup.erl client_sup.erl instantiation EtoE rest tool rest tool rest tool rest tool rest tool start verification with 2 clients etomcrl:instantiator(locker_sup,start,[2]) Erlang -> transitions tomcrl.erl instantiation EtoPmcrl
locker.erl client.erl locker.erl client.erl init.erl locker_sup.erl client_sup.erl instantiation locker.mCRL EtoE rest tool toMCRL rest tool rest tool rest tool CWI tool instantiator start verification with 2 clients etomcrl:instantiator(locker_sup,start,[2]) Erlang -> transitions tomcrl.erl instantiation rest tool EtoPmcrl
locker.erl client.erl locker.erl client.erl init.erl locker_sup.erl client_sup.erl instantiation locker.aut EtoE rest tool Aldebaran start verification with 2 clients etomcrl:instantiator(locker_sup,start,[2]) Erlang -> transitions tomcrl.erl instantiation locker.mCRL toMCRL rest tool CWI tool instantiator EtoPmcrl
simulation with backtrack possibilities find execution sequence deadlock check states in the graph without out-arrow property check such as mutual exclusion State Space analysis
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 State Space analysis Between two handle_call(request,_,_) there should be a handle_call(release,_,_). [-*,“handle_call(request,_,_)”, (not “handle_call(release,_,_)”)*, “handle_call(request,_,_)” ]false
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) Conclusions