1 / 23

Development of Formally Verified Erlang Programs a case study

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.

dorian-bryan
Download Presentation

Development of Formally Verified Erlang Programs a case study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Development of Formally Verified Erlang Programsa case study Thomas Arts Clara Benac Earle Computer Science Lab Stockholm, Sweden

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

  3. CP CP CP CP CP CP Switch Core DP DP DP DP DP DP DP AXD 301 Call setup AXD 301 Architecture

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

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

  6. Billing application Take over CP CP Billing application CC node OM node OM node app app app app app

  7. CP CC node OM node app app app app Take over CP Billing application Billing application take over OM node app

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

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

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

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

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

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

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

  15. enter cs exit cs enter cs enter cs exit cs exit cs enter cs exit cs testing client 1 client 2 io

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

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

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

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

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

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

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

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

More Related