A Practical approach on Model checking with Modex and Spin

Transcription

1 International Journal of Electrical & Computer Sciences IJECS-IJENS Vol: 11 No: 05 1 A Practical approach on Model checking with Modex and Spin Muhammad Iqbal Hossain #1, Nahida Sultana Chowdhury *2 # Computer Science and Engineering, Kyungpook National University Daegu, South Korea 1 milon_mi7@yahoo.com * Computer Science and Engineering, Kyungpook National University Daegu, South Korea 2 nahida_uap@yahoo.com Abstract Software verication methods are used widely in commercial and industrial development. To formally very a large software application we can extract a model from the source code and very that model with any verication mechanism or human contribution. So there are two things extraction and verication. There are two main problems in this approach. The first problem is verication process by human is no longer reliable because in manual verication the error rate can be higher and that can decrease the functionalities of the whole process. The second problem is the effort to extract or very the model can take a considerable investment of time and expertise. For a large system manual verication can take a great effort and the performance of humans. In this paper we have tried to represent the whole process in an automatic way. And also we have tried to ignore the manual contribution of human to make the whole procedure faster and reliable. For this purpose we choose an automated model extractor method: Modex and an automated verier to extrac model: Spin. Firstly we have applied MODEX to automated the model extractor method and then we used SPIN to automatically very the extracted model. mere guiding mental image in the mind of a de-signer. The purpose of a model is to facilitate analysis, either explicitly or implicitly. Models are abstractions of real world artacts. A designer only takes the trouble to build a model when it is easier, cheaper, or faster to analyse the model than it is to analyse the real world artact itself. A model that is more complex than the artact that it describes would be comparable to the summary of a book that is longer than the book. The effective use of abstraction is the key to the successful construction of models. The construction of an abstract model, in turn, is the key to successful analysis. A model should not only be simpler than the artact being modeled, it should also be simpler to construct than that artact. If the construction of a model is perceived to be too complex, it will be all too tempting to forgo the construction of the model, and make do with more basic types of analysis [2]. Index Term MODEX, SPIN, Model Extraction, Model Verication I. INTRODUCTION There are many techniques for evaluating code quality and for reducing the expected number of residual bugs, manual code walkthrough, and peer review and of course plain old unit and integration testing. There is no question that these methods work, they catch bugs but they are not perfect. Conventional verication technique has some restriction that limit the number of bugs that can be caught in this way. This is sometimes called the ceiling that is imposed by standard verying technique. To very a piece of code either in isolation or in a given context, a verier usually creates a test harness, special instrument that is used to efficiently and reproducibly administer a series of tests and evaluate the result[1]. In this paper we divide the whole procedure in two steps: model extractor and model verication. Models are widely used in most engineering disciplines. A model can be a mathematical theory, a physical entity an image or shape, a Fig. 1. The verication process II. MODEL EXTRACTION: MODEX Modex is a tool that can be used to mechanically extract high-level verication models from implementation level C code. Modex itself is written in ANSI-C, and its application domain is also restricted to ANSI-C code (i.e., it does not handle C++). Model extraction and abstraction are also very much still in the domain of research, not of push-button application. So, as a minor disclaimer, you plan to use these tools, be prepared to spend some time to learn how

2 International Journal of Electrical & Computer Sciences IJECS-IJENS Vol: 11 No: 05 2 everything is meant to work. The documentation gives a good head-start. Experience with the application of the tools, building test harnesses, and verying applications, will do the rest. Experience with the effective use of these tools comes slowly but surely, so be patient! After these somewhat discouraging notes, it is also good to add that the reward for finally mastering the use of these tools can be very substantial. Our own experience to date indicates that these tools, used right, allow us to very software applications, or portions thereof, with a thoroughness that cannot be achieved by any other testing or verication method [3, 5]. The procedure to run modex has shown below: Spin is written in C and is distributed as a single executable fi le for Windows and Linux. One way that Spin achieves efficiency is that it does not perform the model checking itself; instead, it generates a highly optimized model checking program in C for each model and each correctness claim to be veried. The user need not look at this C code, although to use Spin you need to have a C compiler installed. A verication in Spin can be run with a three-line script (generate the verier, compile it and run it); alternatively, a development environment can be used. We can generate dferent kind of model to better understand the flow of datas, procedures, error Spin can be run in four modes [6]: 1. Random simulation mode uses a random number generator to resolve the non-determinism inherent in a concurrent program as well as the possible non-determinism in the guarded commands of a single process. 2. Interactive simulation mode enables the user to choose the next instruction to be executed. Interactive simulation is also supported in concurrency simulators and is essential for demonstrating scenarios (such as those for starvation or fairness) that are very unlikely to occur randomly. 3. In verication mode, Spin systematically searches the entire state space looking for a counter example, a computation that violates a correctness specication. 4. If a counterexample is found, a trail of the incorrect computation can be used in guided simulation mode to recreate the computation to the user to examine. The verication process with SPIN has shown below Fig. 2. Run MODEX III. MODEL VERIFICATION: SPIN Spin is a model checker [2] that has been developed at Bell Labs in the original UNIX group of the computer Science research centre. It is originally designed for verying communications protocols and later it become most widely used verication tools. Spin is particularly suited for modeling concurrent and distributed systems that are based upon interleaving of atomic instruction. Models, written in simple language called Promela, can be simulated randomly or interactively [6]. Spin can generate efficient veriers that search for a counter example to correctness specication applied to a model. Unlike many modelcheckers, SPIN does not actually perform model-checking itself, but instead generates C sources for a problem-specic model checker [4]. This technique saves memory and improves performance, while also allowing the direct insertion of chunks of C code into the model. SPIN also offers a large number of options to further speed up the model-checking process and save memory, such as: Partial order reduction; State compression; Bitstate hashing (instead of storing whole states, only their hash code is remembered in a bitfield; this saves a lot of memory but voids completeness); Weak fairness enforcement Fig. 3. Verication of the model with SPIN IV. IMPLEMENTATION AND RESULT To implement our procedure, we have to write a C code and that will be veried through modex and spin. At the first step we have to extract a model from the existing or newly created C code. The basic idea of model extraction is converting ANSI C code to promela code. The branching

3 International Journal of Electrical & Computer Sciences IJECS-IJENS Vol: 11 No: 05 3 instructions are somewhat equivalent to promela. In this extraction procedures are not really supported. We can use inlining or link to external procedure, by the conversion table we can generate the basic statements. A test harness [7] is created associated with the C code. Test harness is used to specy the details of system verication. All the test harness specications are stored in a single file, with the suffix.prx, grouped into dferent commands, each dealing with dferent aspect to the verication setup. Figure 4 represents the c code of the program. This is a simple mutual exclusion code. We attempt to extract a model from this code by the help of modex cat mutex.c /* Bad Mutex Algorithm */ int x, y, z; void lock(int Pid) { busywait: x = Pid; (y!= 0 && y!= Pid) z = Pid; (x!= Pid) y = Pid; (z!= Pid) void unlock() { x = 0; y = 0; z = 0; Fig. 4. C code of mutual exclusion Figure 5 represented the extracted model from the C code using modex. The test harness file also executed automatically during the model extraction. We will not discuss about the test harness file (.prx) to generate the model there are some specic command: modex mutex.c cpp E P _modex_.run > model cat model $ cat model int x; int y; int z; int w64; int builtin_va_list; byte cnt; proctype lock(int Pid; chan q) { busywait: c_code { now.x=plock->pid; ; :: c_expr { ((now.y!=0)&&(now.y!=plock->pid)) ; c_code { now.z=plock->pid; ; :: c_expr { (now.x!=plock->pid) ; c_code { now.y=plock->pid; ; :: c_expr { (now.z!=plock->pid) ; ; q!0 active [2] proctype user() { chan q = [0] of { byte ; run lock(_pid, q); q?0; cnt++; assert(cnt == 1); cnt--; c_code { now.x=0; ; c_code { now.y=0; ; c_code { now.z=0; ; ; Fig. 5. Extracted model from source code The c_code primitive supports the use of embed-ded C code fragments inside PROMELA models. The code must be syntactically valid C, and must be terminated by a semicolon (a required statement terminator in C). If an expression is specied, its value will be evaluated as a general C expression before the C code fragment inside the curly braces is executed. If the result of the evaluation is non-zero, the c_code fragment is executed. If the result of the evaluation is zero, the code between the curly braces is ignored, and the statement is treated as an assertion violation. The typical use of the expression clause is to add checks for nil-pointers or for bounds in array indices. A c_expr can be used to express guard conditions that are not necessarily expressible in PROMELA with its more restrictive data types and language constructs. There are two forms of the c_expr primitive: with or without an additional assertion expression in square brackets. A missing assertion expression is equivalent to [1]. If an assertion expression is specied, its value is evaluated as a general C expression before the code inside the curly braces is evaluated. The normal (expected) case is that the assertion expression evaluates to a non-zero value. If so, the C code between the curly braces is evaluated next to determine the executability of the c_expr as a whole. If the evaluation value of the assertion expression is zero (equivalent to false), the code between the curly braces is ignored and the statement is treated as an assertion violation [1]. Now we will use spin for the verication of the model extracted by mutex. Figure 6, 7 and 8 show dferent type of

4 International Journal of Electrical & Computer Sciences IJECS-IJENS Vol: 11 No: 05 4 verication model generated by Spin. When a PROMELA model contains embedded C code, SPIN cannot simulate its execution in the normal way because it cannot directly interpret the embedded code fragments. If we try to run a simulation anyway, SPIN will make a best effort to comply, but it will only print the text of the c_expr and c_code fragments that it encounters, without actually executing them. To faithfully execute all embedded C code fragments, we must first generate the pan files and compile them. We now rely on the standard C compiler to interpret the contents of all embedded code as part of the normal compilation process. $ spin -a model $ cc -o pan pan.c $./pan hint: this search is more efficient pan.c is compiled - DSAFETY pan:1: assertion violated (cnt==1) (at depth 23) pan: wrote model.trail (Spin Version May 2011) Warning: Search not completed + Partial Order Reduction Full statespace search for: never claim - (none specied) assertion violations + acceptance cycles - (not selected) invalid end states + State-vector 64 byte, depth reached 34, errors: 1 58 states, stored 19 states, matched 77 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) Stats on memory usage (in Megabytes): equivalent memory usage for states (stored*(state-vector + overhead)) actual memory usage for states (unsuccessful compression: %) state-vector as stored = 5208 byte + 16 byte overhead memory used for hash table (-w19) memory used for DFS stack (-m10000) total actual memory usage pan: elapsed time 0 seconds Fig. 6. Creating pan through spin $./pan -r 1: proc 1 (user) model:34 (state 1) [(run 2: proc 0 (user) model:34 (state 1) [(run 3: proc 3 (lock) model:11 (state 1) [now.x=plock- 4: proc 3 (lock) model:13 (state 5) [else] 5: proc 3 (lock) model:17 (state 7) [now.z=plock- 6: proc 3 (lock) model:19 (state 11) [else] 7: proc 3 (lock) model:23 (state 13) [now.y=plock- 8: proc 3 (lock) model:25 (state 17) [else] 9: proc 3 (lock) model:30 (state 19) [q!0] 10: proc 0 (user) model:34 (state 2) [q?0] 11: proc 3 (lock) -:0 (state 0) [-end-] 12: proc 2 (lock) model:11 (state 1) [now.x=plock- 13: proc 2 (lock) model:13 (state 5) [else] 14: proc 2 (lock) model:17 (state 7) [now.z=plock- 15: proc 2 (lock) model:19 (state 11) [else] 16: proc 2 (lock) model:23 (state 13) [now.y=plock- 17: proc 2 (lock) model:25 (state 17) [else] 18: proc 2 (lock) model:30 (state 19) [q!0] 19: proc 1 (user) model:34 (state 2) [q?0] 20: proc 2 (lock) -:0 (state 0) [-end-] 21: proc 1 (user) model:35 (state 3) [cnt = (cnt+1)] 22: proc 1 (user) model:36 (state 4) 23: proc 0 (user) model:35 (state 3) [cnt = (cnt+1)] pan:1: assertion violated (cnt==1) (at depth 24) spin: trail ends after 24 steps #processes 2: 24: proc 0 (user) model:36 (state 4) (invalid end state) assert((cnt==1)) 24: proc 1 (user) model:37 (state 5) (invalid end state) cnt = (cnt-1) global vars: int x: 1 int y: 1 int z: 1 int w64: 0 int builtin_va_list: 0 byte cnt: 2 local vars proc 0 (user): chan q (=1): len 0: local vars proc 1 (user): chan q (=2): len 0:. Fig. 7. output generated by./pan r $ spin -t -p model Starting lock with pid 2 1: proc 1 (user) model:34 (state 1) [(run Starting lock with pid 3 2: proc 0 (user) model:34 (state 1) [(run c_code1: { now.x=plock->pid; 3: proc 3 (lock) model:11 (state 1) [{c_code1] 4: proc 3 (lock) model:15 (state 4) [else] c_code3: { now.z=plock->pid; 5: proc 3 (lock) model:17 (state 7) [{c_code3] 6: proc 3 (lock) model:21 (state 10) [else] c_code5: { now.y=plock->pid; 7: proc 3 (lock) model:23 (state 13) [{c_code5] 8: proc 3 (lock) model:27 (state 16) [else] 9: proc 3 (lock) model:30 (state 19) [q!0]

5 International Journal of Electrical & Computer Sciences IJECS-IJENS Vol: 11 No: : proc 0 (user) model:34 (state 2) [q?0] 11: proc 3 terminates c_code1: { now.x=plock->pid; 12: proc 2 (lock) model:11 (state 1) [{c_code1] 13: proc 2 (lock) model:15 (state 4) [else] c_code3: { now.z=plock->pid; 14: proc 2 (lock) model:17 (state 7) [{c_code3] 15: proc 2 (lock) model:21 (state 10) [else] c_code5: { now.y=plock->pid; 16: proc 2 (lock) model:23 (state 13) [{c_code5] 17: proc 2 (lock) model:27 (state 16) [else] 18: proc 2 (lock) model:30 (state 19) [q!0] 19: proc 1 (user) model:34 (state 2) [q?0] 20: proc 2 terminates 21: proc 1 (user) model:35 (state 3) [cnt = (cnt+1)] 22: proc 1 (user) model:36 (state 4) 23: proc 0 (user) model:35 (state 3) [cnt = (cnt+1)] spin: model:36, Error: assertion violated spin: text of failed assertion: assert((cnt==1)) 24: proc 0 (user) model:36 (state 4) spin: trail ends after 24 steps #processes: 2 x = 0 y = 0 z = 0 w64 = 0 builtin_va_list = 0 cnt = 2 24: proc 1 (user) model:37 (state 5) 24: proc 0 (user) model:37 (state 5) 4 processes created. Fig. 8. The verier produced the above information with./pan t t model Model checking is a formal method that can facilitate learning important CS concepts like concurrency, verication, and nodeterminism. Just as importantly, model checking can motivate the study of discrete mathematics and theoretical computer science by showing how they are used in a real-world application: automata theory, logic, graph theory, hashing functions, and data compression. Although Spin is a professional software tool widely used in industry, the simple and clean syntax and semantics of Promela, and the ease of running simulations and verications make it ideal as a teaching tool, and there are some other tools such as ispin, jspin and Erigone to simply the use of model checking even further. In MODEX, still there have some limitations present in the translation process from C to Promela code. So, we need to consider this issue more carefully to make it more reliable and efficient for SPIN model checker. REFERENCES [1] Holzmann, G.J, From code to models, Application of Concurrency to System Design, Proceedings.2001 International Conference on Digital Object.Publication Year: 2001,Page(s): [2] G.J. Holzmann, The model checker Spin, IEEE Trans. On Software Engineering, Vol. 23, No. 5, May 1997, pp [3] GERARD J. HOLZMANN and MARGARET H. SMITH Software Model Checking Invited paper to the FORTE/PSTV Conference, October 1999, Beijing, China. [4] Spin home page: [5] modex home page: [6] Mordechai (Moti) Ben-Ari A primer on model checking. ACM Inroads 1(1), 2010, [7] An automated verication method for distributed systems software based of model extraction by Gerard J. Holzmann and Margaret H. Smith, IEEE transaction on software Engineering Vol. 28, No. 4 April 2002 [8] S. Burckhardt. Memory Model Sensitive Analysis of Concurrent Data Types. PhD thesis, Univ. of Pennsylvania, In figure 8, the assertion is violated at the end, but this is merely because it was hardwired to fail. None of the C data objects referenced were ever created during this run, and thus none of them had any values that were effectively assigned to them at the end. Note also that the text of the c_code fragment that is numbered c_code5 here is printed out, but that the print statement that it contains is not itself executed, or else the values printed would have shown up in the output near this line. V. CONCLUSIONS The method we have pronounced for verying reactive software applications combines data abstraction with implementation level verication. The user provides a test harness, written in the language of the model checker, that non-deterministically selects inputs for the application that can drive it through all its relevant states. Correctness properties can be veried in the usual way: by making logical statements about reachable and unreachable states, or about feasible or infeasible executions. The state tracking capability allows us to perform full temporal logic verication on implementation level code.