Presentation Transcript

1. The Spin Model Checker[Holzmann, 03]Chapter 3, 4, and 11

   Takumi Kida Mitsuharu Kurita Ayato Miki
2. Review Parallel and distributed systems Validation of systems are difficult “Model checking tools” Check models of them mechanically Assertion Initial state State transition
3. Chapter 3An Overview of Promela Mitsuharu Kurita
4. Spin model checkerand Promela Spin Model checker for parallel / distributed systems Validate the state transition of models Modeling language: Promela Promela Modeling language with C-like syntax Not intended to be used in implementation active proctype Sender(){ again: to_rcvr!msg; to_sndr?ack; goto again } ……………. System model Promela code
5. Model example 1 Primitive sender / receiver mtype = {msg, ack}; chanto_sndr = [2] of {mtype}; chanto_rcvr = [2] of {mtype}; active proctype Sender(){ again: to_rcvr!msg; to_sndr?ack; goto again } active proctype Receiver(){ again: to_rcvr?msg; to_sndr!ack; goto again } Sender Receiver msg ack msg ack
6. The structure of Promela code 3 main components in Promera mtype = {msg, ack}; chanto_sndr = [2] of {mtype}; chanto_rcvr = [2] of {mtype}; active proctype Sender(){ again: to_rcvr!msg; to_sndr?ack; goto again } active proctype Receiver(){ again: to_rcvr?msg; to_sndr!ack; goto again } Data objects Message channels Processes
7. Processes (1) Multiple processes which work in parallel Different from “native” processes Expressed as objects of “proctype” type Process details are written like functions in C Up to 255 processes can be exist at the same moment 2 processes are defined active [2] proctypeyou_run(){ printf("my pid is: %d\n", _pid) } Each of them is executed simultaneously my pid is: 0 my pid is : 1 2 processes created
8. Processes (2) Another expression to run processes Process definition without “active” proctypeyou_run(){ printf("my pid is: %d\n", _pid) } init{ run you_run(); run you_run(); } my pid is: 2 my pid is: 1 3 processes created
9. Data objects (1) Basic data types Basically they are derived from C All of them can be used as int Some do not exist in C chan Message channels mtype Message types pid Process id Scope of variables Global Process local No function exists in Promela User-defined types are available typedef Field{ short f = 3; byte g }
10. Data objects (2) mtype Variable type for labeling of kinds of messages Similar to “enum” in C mtype = {msg, ack};
11. Message channels (1) Message channels Interprocess communications which have buffer Message has some fields expressed as data types User-defined types can be included chanqname = [16] of {short, byte, bool} qname!10,50,true qname?var1,var2,var3 qname
12. Message channels (2) Restricted reception You can restrict receiving messages with constant value Messages whose value of the first field is 30 can be received qname?30,var2,var3 Restriction with contents of variable “var1” qname?eval(var1),var2,var3
13. Model example 1 (revisited) Primitive sender / receiver mtype = {msg, ack}; chanto_sndr = [2] of {mtype}; chanto_rcvr = [2] of {mtype}; active proctype Sender(){ again: to_rcvr!msg; to_sndr?ack; goto again } active proctype Receiver(){ again: to_rcvr?msg; to_sndr!ack; goto again } Sender Receiver msg ack msg ack
14. Control flow Selections Repetitions Atomic sequences Deterministic steps Escape sequences
15. Executability Each expression inPromela has “executability” Processes block at “inexecutable” expression Basically it is boolean values of expressions Example: a == b : blocks until a == b (same as while(a != b){} in C) chan!val1 / chan?var1 : blocks if chan is full / empty false : eternally blocks a = b, printf : always executable
16. Selections (1) Statements between “if” and “fi” Different from “if” block in C Each option is marked with “::” A statement whose first expression is executable is selected If more than 2 options are executable, one of them is chosen randomly if :: (a != b) -> option 1 :: (a == b) -> option 2 :: printf(“Hello, world.”) fi printf can be executed regardless of values of a or b
17. Selections (2) If all options are inexecutable, the process blocks until one or more options get executable Options can include “else”, which is executed only when all of the other options are inexcutable
18. Repetitions Statements between “do” and “od” It repeats selection same as “if” repeatedly There is no “while” or “for” in Promela Simple loops are denoted by “goto” do :: count++ :: count— od count randomly moves up and down
19. Atomic sequences and Deterministic steps Atomic sequences Statements in “atomic{}” Executed atomically as long as the statements are executable Deterministic steps Statements in “d_step{}” Each statement must be executable and deterministic Cannot get into / out of block with “goto” atomic{ tmp = b; b = a; a = tmp; } d_step{ tmp = b; b = a; a = tmp; }
20. Escape sequences 2 code blocks connected by “until” If the first statement in E is inexecutable, P is executed As soon as E gets exutable, E is executed and the control flow never backs to P If P is finished before E becomes executable, E is abandoned {P}until{E}
21. Model example 2 Simple model of telephone system
22. Summery Introduced Promela Model definition language for Spin Syntax and functions of Promela 3 main components Data objects Message channels Processes Control flow Executability Selection Repetition and so on

23. Chapter 4

    Takumi Kida
24. Outline of Chapter 4 About SPIN verification process Basic Types of Claims Basic Assertions End State Labels Progress State Labels Accept State Labels Never Claims Trace Assertions Built-in Variables and Functions Logical Formulations of Correctness LTL (Linear Temporal Logic) The Link between LTL and Never Claims
25. About SPIN verification process User can define some correctness requirement in PROMELA Some types of properties , such as system deadlock states, need not be stated explicitly. They are checked by default. SPIN does not care about META labels, assertion claims { … … } Verifier PROMALA Code
26. Basic Assertions Basic assertions are always executable The implied correctness property is that it is never possible for the expression to evaluate to false (or zero) Examples Init{ assert ( expression ) /* assert that expression is true */ } Init{ assert (false) /* error */ }
27. End State Labels In PROMELA, by default, the only valid end states are those in which every process has reached the end of its code The end state labels define additional valid end states Every labels name that starts with the prefix ‘end’ means end state label …(){ end: … … } Additional end state defined by user End of code is default end state
28. Progress State labels Progress state labels is signifying that the executing process is making effective progress, rather than Every potentially infinite execution cycle passes through at least one progress labels. If cycles that do not have this property, it will be error of the existence of non-progress cycle Variation with a prefix ‘progress’ is available
29. Examples Dijkstra’s Semaphore (Model) Semaphore Count V operation Count ++ P operation If(count !=0) Count -- User Processes User1 User2 User3 …
30. Examples Dijkstra’s Semaphore (Code) mtype {p,v}; chan sema = [0] of {mtype}; active proctype Dijkstra(){ /* Semaphore Process */ byte count=1; end: do /* this line is also valid end state ! */ :: (count == 1) -> progress: sema!p; count =0; :: (count == 0) -> sema?v; count =1; od } active[3] proctype user(){ do :: sema?p; /* Enter */ critical: skip; /* Critical Section */ sema!v; /* Leave */ od }
31. An example of non-progress cycle byte x =2; /* global */ active proctype A(){ do :: x = 3 - x; od } active proctype B(){ do :: x = 3 - x; od } /* x changes between 2 and 1 infiitely */ If there is no progerss labels, these cycles is guaranteed to be a non-progress cycle.
32. Accept State labels The implicit correctness expressed by accept labels is that there should not be any infinite loops that pass through an accept state label. Accept state labels is normally used in never claims (next section) Variations with the prefix ‘accept’ is also available Examples never{ accept: do :: !q /* q must not be false infinitely (eventually becomes true ) */ od; }
33. Never Claims Never claim is normally used to specify either finite or infinite system behavior that should never occur Never claim checks system properties just before and just after each statement execution Example never{ /* p must remain true */ do :: !p -> break /* break from never claim means error */ :: else od }
34. Never Claims Another Expression never{ do :: assert (p) od } active proctype monitor() { atomic{ !p -> assert ( false)} }
35. Never Claim as a State Machine true never{ S0: do :: (p || !q ) -> break :: ture od S1: do accept :: !q :: ! (p || q) -> break od } S0 (p || !q) !q S1 !( p || q) ERROR
36. Trace Assertions Trace assertion expresses a correctness requirement on the properties of message channels Trace assertion formalizes statements about valid or invalid sequences of operations that processes can perform on message channels A trace assertion monitors only a subset of the events in a system that are mentioned in the trace clause Examples trace{ do :: q1!a; q2?b od }
37. Predefined Variables and Functions Predefined Variables _ _ refers to a global, predefined, write-only, integer variable that can be used to store scratch values. _pid read-only variable of type pid that stores the instantiation number of the executing process. np_ read-only variable of type boolean that becomes true when system states are marked as non-progress states _last _last is a predefined global variable that holds the instantiation number of the process that performed the last step in the current execution sequence.
38. Predefined Variables and Functions Predefined Functions pc_value(pid) enabled(pid) proctype[pid]@label proctype[pid]: var (Remote Refernce, only SPIN 4.0 or later)
39. Logical Formulation using LTL LTL is a modal temporal logic with modalities referring to time. One can formulate logical condition and its temporal changes
40. Formulation by LTL true S0 (p || !q) ￢[ ] ( p → (p U q) ) !q S1 !( p || q) ERROR
41. The Link between LTL and Never Claims In SPIN, there is an automatic generation tool of never claims using LTL ![ ] (p -> (p U q)) spin – f ‘ ) ’ never { T0_init: if :: ( ( !(q) ) && (p)) -> goto accept_S4 :: ( true ) -> goto T0_init fi; accept_S4: if :: ( ! (q)) -> goto accept_S4 :: ( !(p) && !(q) ) -> goto accept_all fi; accept_all: skip }
42. Chapter 11using spin Ayato Miki
43. Spin structure Syntax checker Promelaで記述したモデルの文法をチェックする Simulator ランダムまたは指定のシーケンスで実行を行う Verifier generator 検証器のコードを生成する 検証器は状態空間探索によってモデルの正当性を検証する
44. Roadmap Syntax check $ spin -A model Random simulation $ spin model Verification $ spin -a model $ gcc -o pan pan.c $ ./pan Inspecting error traces $ spin -t -p model
45. Syntax check モデルの文法をチェックする $ spin -A model
46. Random simulation (1) ランダムシミュレーション $ spin model -nN乱数の種をNに指定 いろいろと情報を出力する $ spin -p -l -g model -p 全ての文の実行履歴を出力 -l 状態変化したプロセスのローカル変数を出力 -g グローバル変数の変化を出力 範囲を指定 $ spin -jN -uM model Nステップから出力し、Mステップまでで打ち切る
47. Random simulation (2) チャネルによるメッセージの通信イベントを出力 $ spin -s -r model -s 送信イベント -r 受信イベント $ spin -c model 送受信イベントをプロセスごとにカラム表示
48. Interactive simulation 実行するシーケンスを手動で選択 $ spin -i -p model
49. Guided simulation 検証の後で、エラーになったシーケンスを再現する
50. Generating a verifier 検証器のコードを生成 $ spin -a model pan.bpan.cpan.hpan.mpan.lができる メッセージが失われるモデル $ spin -a -m model -m チャネルキューが一杯のときメッセージを破棄
51. Compiling the verifier 検証器をコンパイル $ gcc -o pan pan.c 物理メモリの限度をMB単位で指定 $ gcc -DMEMLIM=512 -o pan pan.c 使用メモリを節約するオプション群 $ gcc -DCOLLAPSE -o pan pan.c $ gcc -DHC4 -o pan pan.c $ gcc -DBITSTATE -o pan pan.c
52. Bitstate verification 普通は1状態の表現に数十～数百バイト必要 大きな探索空間ではメモリがあふれる 状態空間をビットで表現 メモリ消費量を格段に削減する ただし探索の完全性は保証されない 状態数の100倍以上のメモリがあれば99％以上のカバー率
53. Tuning a verification run 普通に検証を実行 $ ./pan ハッシュテーブルサイズを調整 $ ./pan -wN 2^N個の状態を扱える 小さすぎると探索時間大。大きすぎるとメモリ消費大。 どちらでも探索の結果に影響はない ただし、ビット状態空間のときは、小さいとカバー率低下 サイズを増やしながら繰り返すのが効率的
54. Search depth (1) 探索の深さを調整 $ ./pan -mN デフォルトはN=10,000 大きな状態空間を全探索したいときは深く 浅いステップのエラーを見つけるときは浅く 探索スタックをディスクにスワップ $ gcc -DSC -o pan pan.c $ ./pan -mN Nステップまではメモリ、それ以降はディスク
55. Search depth (2) 深さN以内で最短のエラーシーケンスを見つけたい $ gcc -DREACH -o pan pan.c $ ./pan -i -mN ビット状態空間は完全性を欠くため使えない 幅優先探索 $ gcc -DBFS -o pan pan.c 無限ループではなく、デッドロックやassert違反など、一瞬のエラー状態のみを見つけるとき
56. Error そもそもエラーとは Safety property デッドロック(invalid end states) assert違反 Liveness property Acceptance cycle 特定の状態を通過する無限ループ Non-progress cycle 特定の状態を通過しない無限ループ
57. Safety property 普通はこちらだけを検出 Assert違反を検出しない $ ./pan -A Invalid end statesを検出しない $ ./pan -E
58. Liveness property Acceptance cyclesを検出 $ ./pan -a Non-progress cyclesを検出 $ gcc -DNP -o pan pan.c $ ./pan -l
59. Inspecting error traces Guided simulation エラーを起こすシーケンスを再現する $ spin -t -p model N個目のエラーだけを検出 $ ./pan -cN N=0だとエラーが出ても探索を継続する
60. Xspin SPINのGUI