How to verify Erlang Programs?

1. How to verify Erlang Programs? Philippe Giabbanelli CMPT 894 – Spring 2008

2. We can try to look directly at how people modeled languages such as Erlang in order to do some model checking… If you really want to begin by doing that, it might not be a great success. Lots of signs and abstract things that would pretty much look like another language… So, we will take the time we need to put the basis. Algebraic Process Verification Syntax/Semantics of µCRL Semantics for Erlang 1

3. Algebraic Proc. Verification Timed µCRL Application to Erlang • The easier way to think of a program is that it takes an input, runs, and if it terminates produces an output. • This maybe worked 20 years ago for « Batch Processing », but it doesn’t work if we have processes interacting with their environnement. • There has been many formalisms, or algebras, to describe that: CCS (Calculus of Communicating Systems), CSP (Communicating Sequential Processes), ACP (Algebra of Communicating Processes)… • We have processes and we combine them with operators, with some restrictions with axioms to specify correctly the behaviour. • Domain of process + operators satisfying axioms = Process Algebra. 2

4. Algebraic Proc. Verification Timed µCRL Application to Erlang • Before we go any further, just notice that process algebra is not the only way to describe processes. There are things called Trace, event structures, objets in metric spaces… • If you want an overview of how processes can be modelled in general: The Semantics of sequential processes with silent moves, R. J. Van Glabbeck, CONCUR’93 (Lecture Notes on Computer Science Vol715) • A basic process algebra can be seen as we did previously: an automaton where we have actions on the transitions. This is a good illustration but is not always very convenient to deal with data. y|pp(UZ) y|A ε|B y|A x|p(XY) • A process algebra extended to deal with data is µCRL. With µCRL, people have described interacting programs, done some mathematical analysis and implemented a toolset (in 2000). 3

5. Algebraic Proc. Verification Timed µCRL Application to Erlang • We have messages, we have data… what else? aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaWe had an ordering on the actions, but we might need an accurate notion ot time. Time! ∙ We could say that A happens before B, but how to say that it happens 10 seconds before B? ∙ How to say that if nothing is done within 5 secondes, then some actions happens? (timer effect) ∙ How to deal about real-time systems where some actions must be done by a given time deadline? Example of real-time. To destroy some moving target, we must fire at 10:05. A missile must be unlocked in at most 5 seconds. 4

6. Algebraic Proc. Verification Timed µCRL Application to Erlang • µCRL could express how processes communicate and handle datas. It has been extended by the time as a new layer in the version timed µCRL. timed µCRL µCRL + time = • What we mean with a « new layer » is that if you do not need to speak about time in your application, then a timed µCRL is just a simple µCRL. • How many operators do you need to handle time? Only two! ∙ xct : the first action of x takes place at time t. When? ∙ x << y : the process x starting before y must have performed one action. How long? • Just to be able to read some articles using µCRL, let explain a bit the language. First of all: abstract data types. 5

7. Algebraic Proc. Verification Timed µCRL Application to Erlang • In µCRL, a data type is declared with the keyword sort and is thus called a data sort. sort Bool func t, f: → Bool sort Bool, N func t, f: → Bool 0: → N S: N→ N • We declare that ‘t’ and ‘f’ are the only elements of Bool. They are called the constructors of sort Bool. • Each natural number can be written as 0 or as the application of a finite number of successors to 0. • To define functions for a domain where the structure is given: map ^: Bool x Bool → Bool +: N x N → N 6

8. Algebraic Proc. Verification Timed µCRL Application to Erlang • To have a better specification for the behaviour of functions, we can add some rewriting rules: var x:Bool n, n’: N rew x ^ t = x aaaaaiiix ^ f = f aaaaaiiin + 0 = n aaaaaiiin + S(n’) = S(n+n’) ↑ Invalid (infinite…) map ^: Bool x Bool → Bool +: N x N → N ← Specification of discrete time 7

9. Algebraic Proc. Verification Timed µCRL Application to Erlang • Now that we defined objects and functions on them, we can define actions which are more or less just a function’s header. act a:Bool iiiiiiiiiiia:N x D • A process is only specified by the set of its variables: proc X(name1:type1, …, nameN:typeN) = p • With p . q, we perform actions of p and when it terminates, actions of q. • With p + q, we either do « p » or « q », depending on which one does the first action. a(3,d) + timeout.a(t) a(3,d) is performed, unless there is a timeout and we do a(t). • δ means deadlock. Let say p must be done before some time and after it is forbidden to do it anymore: p + δ = δ. If we have a deadlock, we cannot reach anything after it: δ.p = δ. We can also use if if some actions must not happen and thus be blocked… 8

10. Algebraic Proc. Verification Timed µCRL Application to Erlang • With ac2 we say that a happens at time 2. Thus, a subsequent action cannot happen before 2! ac2.bc2 ac2.bc1 OK Rejected. Same than ac2.δc1 • For conditional, we use p←b→q. If b is true then p is done, otherwise q. It counts the number of times the action ‘a’ happen. If it happens more than 10 times, the action b is done and the counter is restarted. • Internal actions are denoted by τ. They are considered hidden. • Parallel processes are denoted by ||. Thus p || q = p.q + q.p • Communication between processes? Not that convenient to write… 9

11. Algebraic Proc. Verification Timed µCRL Application to Erlang A summary • A µCRL behaviour is described in two levels: ∙ Process (sequencing, composition, communication using synchronization). ∙ Data, kept by processors and exchanged in communications. Separated into types. • Timed µCRL is just one more level, saying when an action happens, and if an action happens after another. If you want to see more on it: Translating erlang to µCRL, Arts, Earle, Sanchez-Penas, in ‘Fourth International Conference on Application of Concurrency to System Design’ (June 2004) 10

12. Algebraic Proc. VerificationTimed µCRL Application to Erlang • Earle, Fredlund and Derrick have built the tool etomcrl that takes a client-server system in Erlang and gives the µCRL specification. • This specification (after converting) was used in CADP, Construction and Analysis of Distributed Processes, a wonderful french model checker. • The authors claimed that they succeeded to verify a software controlling Ericsson’s ATM switches, and the scheduler of a video-on-demand server. Thus, two industrial applications. ∙ As knowing about CADP might be useful for some of us, I will present some slides written by the authors of CADP. Yes, I steal slides too. 11

13. Algebraic Proc. VerificationTimed µCRL Application to Erlang • So, back to Earle, Fredlund and Derrick analysis of Erlang. What subset of Erlang did they consider to get the µCRL specification? • They consider only client-server systems. Furthermore, those systems are assumed to be built from two generic components: a generic server component and a supervisor component (system process, handles errors). • A generic server is given by the OTP library of Erlang, with functions: ∙ cast, synchronous communication (i.e. you just send the message and you keep doing your work, like if you send an e-mail) ∙ call, synchronous communication (you wait for an answer; asynchronous processes often use semaphores to synchronize) ∙ request/release, acquire a lock and release it • « The semantics […] is simpler than […] Erlang language. Thus by focusing on the higher-level components […] our task becomes easier. » 12

14. Algebraic Proc. VerificationTimed µCRL Application to Erlang • Earle, Fredlund and Derrick ‘analysis of Erlang’ just consists of checking how a server built with the OTP library behaves when a client crashes. It is a very specialized application... • Furthermore, they study a subset of the servers with some assumed characteristics: ∙ an exit message is always received when a client crashes (supervisor mode without errors) ∙ the server only monitors clients speaking in synchronous communication (using call) ∙ whatever happens, the server will not choose to stop monitoring a client (using unlink) • Why those assumptions? « They are indicative of a class of servers that safely implement a stateful protocol ». 13

15. Algebraic Proc. VerificationTimed µCRL Application to Erlang • So, what do we have so far? The server must be written with OTP and implement a stateful protocol. The authors are only interested about client/server. It is… a bit restricted. And not even trivial! Our goal is to find models suitable to Erlang. 14

16. Algebraic Proc. VerificationTimed µCRL Application to Erlang • How do we translate Erlang in µCRL? ∙ First step, pre-analysis of Erlang’s functions. Purely functionnal (no communication) → µCRL function. Communicating functions → µCRL process. How to find which ones are the Communicating functions? The system process will start processes on the system that it will supervise. Those processes start functions from modules We know in which module is the server→server process. ∙ Actualy, the paper begins by saying « first step », but it never goes further than the first one. So, what we can assume is that they consider everything that is not starting a function of the module for the server as being on the client side. List of processes to start on the system What they say however, is that each client has a non-deterministic choice between the action corresponding to its communication function, and sending a crash message. OTP Server System Process Modules 15

17. Algebraic Proc. VerificationTimed µCRL Application to Erlang What have we learnt about all those ideas about modeling? • µCRL has been used for model checking. However: ∙ It has strong assumptions such as considering that any processes willing to communicate go through a handshake protocol and thus the communication is reliable. ∙ Defining a bunch of data types is probably not a useful features for languages such as Erlang, relying on a small core with few types from which everything derives. ∙ Describing the communications between processes is awful. • The time is important and shouldn’t be hard to take in the model. • Every function has a non-deterministic choice between its regular communication and sending an error message. • Some functions are purely functions and other are communicating. Should they be considered differently? That’s not too sure… 16

18. Algebraic Proc. VerificationTimed µCRL Application to Erlang • Alright, that’s not the end of the world: that was one model (µCRL) and an attempt to do something with Erlang. Nothing is perfect, but there are always some interesting ideas that we can pick and work on! informations • It is fairly hard to do something on a whole language. OTP servers were a bit special, but it is common to consider only a subset of the language. Core Erlang is one such subset. A function produces a sequence of values. Can define local recursive functions (NOT in Erlang!) • It is still not that small: 27 pages of specification (Core Erlang 1.0.3) in 2004. The first specification is from 2000. 2 constructs for branching in the core vs 6 in Erlang. If no close match, it’s undefined. Apply a local function or call from a module (remote call), primop are for the compiler. Var1 is the tag (‘EXIT’), var2 the value. • BEAM compiler for Erlang uses Core Erlang as an intermediate representation. Thus, we are not loosing any details by this sub-language. 17

19. Algebraic Proc. VerificationTimed µCRL Application to Erlang Other things you might want to look at: • Small subsets of Erlang have been used in On the verification of open distributed systems (Dam&Fredlund), Verification of Erlang programs using abstract interpretation and model checking (Huch). They cannot represent all Erlang programs. • Feeley and Larose have built a translator from Erlang to Scheme, but the output is not suitable for program verification or process communication analysis. 18

20. Articles used for this presentation Algebraic Process Verification (Groote&Reniers), sections Introduction and Process algebra with data: µCRL. The Syntax and Semantics of timed µCRL (Groote&Reniers), sections Introduction and Process algebra with data: µCRL. Verifying Fault-Tolerant Erlang Programs (Earle&Fredlund&Derrick) An introduction to Core Erlang (Richard Carlsson) T H A N K Y O U