The TLC Model Checker

Transkript

1 The TLC Model Checker Theorie Verteilter Systeme: Fehlertolerante Systeme Sommersemester 2006 : Features Fazit : Features Motivation Bisher (TVS2) u. a.: Reine Spezifikationen TLA+ Syntax Temporale Formeln Lebendigkeit Fairness Motivation Frage: Wann ist eine Spezifikation korrekt? Was ist korrekt? Syntax-Analyser TLC-Model-Checker : Features 1

2 TLA-Sany [2] Parsen/Überprüfung einer TLA+ Spezifikation auf Fehler Syntaktische Fehler Semantische Fehler Aufruf: Java tlasany.sany [-s -d] Spezifikationsdatei Optionen: -s: Nur auf syntaktische Fehler untersuchen -d: Debug-Modus D:\Programme\tla>java tlasany.sany hour.tla ****** SANY ( Created: Wed Jun 6 16:55: ) Parsing file hour.tla Parsing file D:\Programme\tla\tlasany\StandardModules\Naturals.tla Semantic processing of module Naturals Semantic processing of module hour D:\Programme\tla>java tlasany.sany hour.tla ****** SANY ( Created: Wed Jun 6 16:55: ) Parsing file hour.tla Parsing file D:\Programme\tla\tlasany\StandardModules\Naturals.tla Semantic processing of module Naturals Semantic processing of module hour Semantic errors: *** Errors: 1 line 6, col 19 to line 6, col 24 of module hour Could not find declaration or definition of symbol 'hffffr'. D:\Programme\tla>java tlasany.sany -s hour.tla ****** SANY ( Created: Wed Jun 6 16:55: ) Parsing file hour.tla Parsing file D:\Programme\tla\tlasany\StandardModules\Naturals.tla Semantischer Fehler Was bedeutet hffffr? Keine Deklaration Syntaktisch korrekt hfffr zulässiger Ausdruck Semantische Fehler: Decken nicht falsche Abbildung der Intention einer Spezifikation auf Syntaktische Fehler: Verletzung grammatikalischer Regeln Parsen gemäß zulässiger Spezifikation der TLA+ Sprache Vergl. Kapitel 15 The Syntax of TLA+ [1] Ł hffffr syntaktisch korrekt 2

3 Syntaktische Fehler: Beispiel(1): Syntaktische Fehler: Beispiel(2): Ł Syntaktisch korrekt (semantisch auch) Ł Syntaktisch nicht korrekt Entspricht: Entspricht: : Features TLC Model Checker: Features TLC zur Fehlerdetektierung temporaler Formeln [3] Übliche Beschreibung von Spezifikationen in TLA+: Init [Next] vars Temporal Init: Initialer Prädikat Next: Aktion vars: Variablentupel Temporal: Temporale Formel (Lebendigkeit der Spezifikation) Vielseitige Nutzung: TLC Model Checker: Features Beschränkung auf vorgegebene Eigenschaften (Constraints, Properties, dazu später mehr) Erkennen dummer Fehler Bsp.: 3 + <1,2> Bsp.: x[1], wobei x eine Sequenz ist Syntaktisch/Semantisch korrekt Erkennen von Deadlocks (Zustände ohne mögliche Nachfolgezustände) Evt. Deadlock erwünscht (Zielzustand) Detektierung abschaltbar 3

4 TLC Model Checker: Features Ablauf: Anwendung des Syntax Analyser, dann entweder Model Checking: Ausgehend von allen zulässigen Initialzuständen alle erreichbare Nachfolgezustände iterativ prüfen oder : Zufällige (seed-abhängige) unabhängiger (möglicher) Zustände überprüfen : Features Referenzbeispiel: Alternating Bit Ptotocol Versendung von Daten über eine verlustbehaftete FIFO-Leitung Referenzbeispiel: Alternating Bit Ptotocol Versendung von Daten über eine verlustbehaftete FIFO-Leitung Datum d senden: Nur falls sbit = sack sent = d sbit = 1 sbit (u. a.) Datum d empfangen: rcvd = d rbit = x (x in der Nachricht enthalten) Acknowledgment senden (beliebig oft) Acknowledgment empfangen Re-send möglich (da Nachrichten verloren gehen können) Referenzbeispiel: Alternating Bit Ptotocol Versendung von Daten über eine verlustbehaftete FIFO-Leitung LoseMsg, LoseAck bei der Spezifikation beachten!!! Spezifikation (AltenatingBit): 4

5 TLC: Detektierung dummer Fehler und Deadlocks (WHL) Checken weiterer Eigenschaften: ŁKonfigurationsdatei SPECIFICATION ABSpec Alternativ, falls ohne Lebendigkeitsforderung: INIT Init NEXT Next Checken einer Eigenschaft: PROPERTY ABTypeInv Wird ABTypeInv initial erfüllt? Besser: PROPERTY ABTypeInv ŁEntweder Definieren Inv ABTypeInv ŁPROPERTY Inv oder INVARIANT ABTypeInv Beide Ausdrücke gleichwertig Zustand: Zuweisung von Werten zu Variablen TLC: Generierung von Zuständen ŁZuweisung von Werten Welche Werte können Variablen einnehmen? Welche Werte kann bspw. sent einnehmen? sent Data Ł Was ist Data? CONSTANT Data = {d1, d2} SPECIFICATION ABSpec INVARIANT ABTypeInv CONSTANT Data = {d1, d2} Aufruf TLC: Java tlc.tlc [Optionen] Spezifikationsdatei Ausgabe (Abbruch nach ca. 6 Minuten): D:\Programme\tla>java tlc.tlc AlternatingBit.tla TLC Version 2.0 of January 16, 2006 Model-checking Parsing file AlternatingBit.tla Parsing file D:\Programme\tla\tlasany\StandardModules\Naturals.tla Parsing file D:\Programme\tla\tlasany\StandardModules\Sequences.tla Semantic processing of module Naturals Semantic processing of module Sequences Semantic processing of module AlternatingBit Finished computing initial states: 8 distinct states generated. Progress(30): states generated, distinct states found, 4357 states left on queue. Progress(48): states generated, distinct states found, states left on queue. 5

6 Finished computing initial states: 8 distinct states generated. Bedeutung: Initiale Zustände geprüft 8 verschiedene Zustände möglich Zustand msgq ackq sbit = sack = rbit 01 sent rcvd <> <> d1 d2 d1 d2 ŁKomplexität exponential!!!! Finished computing initial states: 8 distinct states generated. Progress(30): states generated, distinct states found, 4357 states left on queue. Bedeutung: Zum gegenwärtigen Augenblick: Zustandsgraph der Tiefe 30 ermittelt (längster kürzester Pfad von einem Initialzustand) Zustände geprüft, davon Zustände verschieden In Warteschlange (zum gegenwärtigen Augenblick!!!) Zustände auf Folgezustände zu prüfen Analyse: msgq, ackq können unendlich groß werden Untersuchung endlos, da unendlich viele Zustände möglich (im Beispiel manueller Abbruch) Lösung: Spezifikation ändern: Länge der Nachrichtenschlangen beschränken (für TLC) Constraint bekannt geben CONSTRAINT SeqConstraint Auswertung der Zustände durch TLC: Alternative: Statt Spezifikation wegen TLC zu ändern besser: ŁNeues Test-Modul mit EXTENDS Hinzufügen: CONSTANT msgqlen = 2 CONSTANT ackqlen = 2 CONSTRAINT SeqConstraint Ausgabe (Laufzeit ca. 1 Sekunde): D:\Programme\tla>java tlc.tlc MCAlternatingBit.tla TLC Version 2.0 of January 16, 2006 Model-checking Parsing file MCAlternatingBit.tla... Semantic processing of module MCAlternatingBit Finished computing initial states: 8 distinct states generated. Model checking completed. No error has been found states generated, 240 distinct states found, 0 states left on queue. The depth of the complete state graph search is 10. 6

7 Weiterer Untersuchungsgegenstand: Wird ein bestimmtes Verhalten erreicht? Wird eine bestimmte Aktion ausgeführt? Wird die Aktion zum gewünschten Zeitpunkt aktiv (ENABLED)? Beispiel: Wenn eine Datum d gesendet wurde, wird auch irgendwann ein d empfangen? (Lebendigkeitseigenschaft) Festlegung einer Definition: Ändern der Next-Definition im AlternatingBit-Spezifikation: Ohne ReSndMsg Festlegung der Untersuchung durch Eigenschaft (PROPERTY): PROPERTY SentLeadsToRcvd Anmerkung: PROPERTY vs. CONSTRAINT PROPERTY P: Gilt Spec P? (ja/nein) CONSTRAINT C: Spec TLC = Init [Next] vars C Ändern der Next-Definition im AlternatingBit-Spezifikation: --Checking temporal properties for the complete state space... Error: Temporal properties were violated. The following behaviour constitutes a counter-example: STATE 1: <Initial predicate> /\ ackq = << >> /\ sent = d1 /\ sack = 0 /\ sbit = 0 /\ rbit = 0 /\ rcvd = d2 /\ msgq = << >> STATE 2: <Action line 29, col 3 to line 33, col 41 of module AlternatingBit> Anmerkung: SndNewValue(d1) /\ ackq = << >> /\ sent = d1 /\ sack = 0 /\ sbit = 1 /\ rbit = 0 /\ rcvd = d2 /\ msgq = << << 1, d1 >> >> STATE 3: <Action line 47, col 11 to line 48, col 61 of module AlternatingBit> Anmerkung: SndAck /\ ackq = << 0 >> /\ sent = d1 /\ sack = 0 /\ sbit = 1 /\ rbit = 0 /\ rcvd = d2 /\ msgq = << << 1, d1 >> >> STATE 4: <Action line 47, col 11 to line 48, col 61 of module AlternatingBit> Anmerkung: SndAck /\ ackq = << 0, 0 >> /\ sent = d1 /\ sack = 0 /\ sbit = 1 /\ rbit = 0 /\ rcvd = d2 /\ msgq = << << 1, d1 >> >> STATE 5: <Action line 62, col 12 to line 62, col 39 of module AlternatingBit> Anmerkung: LoseMsg /\ ackq = << 0, 0 >> /\ sent = d1 /\ sack = 0 /\ sbit = 1 /\ rbit = 0 /\ rcvd = d2 /\ msgq = << >> STATE 6: <Action line 50, col 11 to line 53, col 55 of module AlternatingBit> Anmerkung: RcvAck /\ ackq = << 0 >> /\ sent = d1 /\ sack = 0 /\ sbit = 1 /\ rbit = 0 /\ rcvd = d2 /\ msgq = << >> Betrachtung folgender Spezifikation: STATE 7: Back to state 5. Möglichkeiten Theoretisch wird kein neuer Wert gesendet, da nur gesendet werden darf, wenn gilt sbit = sack 7

8 Erkenntnisse: Keine FIFO-Warteschlangen Kein ReSndMsg Kein SndAck (nur CRcvAck) Kein LoseMsg/LoseAck Zugriff auf entfernte Variablen ŁVerhalten in ABCorrectness gewünschtes Verhalten in AlternatingBit (bis auf Zwischenzustände und Hilfsvariablen) Frage: Folgt aus AlternatingBit auch ABCorrectness? (Wenn ja, dann gute Spezifikation) PROPERTIES ABCSpec SentLeadsToRcvd : Features TLC kann folgende Arten von Werten analysieren (primitive TLC- Werte): Booleans TRUE, FALSE Integers 3, -1 Strings ab3 Model Values Über CONSTANTS eingeführte Werte d1, d2 in DATA = {d1, d2} TLC Values: Primitiver Wert (siehe letzte Folie) Endliche Menge vergleichbarer TLC-Werte Eine Funktion f, wobei gilt: x DOMAIN f : x ist TLC-Value und f[x] ist TLC-Value Beispiele: {{ a, b },{ b, c },{ c, d }} <1, a,2, b > [i (1..4) IF i=1 THEN 1 ELSE IF i=2 THEN a ELSE IF i=3 THEN 2 ELSE b ] TLC Values: Vergleichbarkeit gegeben, wenn TLC bestimmen kann ob zwei Werte gleich oder ungleich sind Beispiel: { 1,1} kein TLC-Wert, aber: {{ 1 },{1,2}} TLC-Wert Mengen sind vergleichbar, wenn Beide unterschiedliche Kardialität haben Beide selbe Kardialität haben und deren Elemente vergleichbar sind 8

9 Auswertung von Ausdrücken Zunächst ist eine Auswertung der Ausdrücke einer Spezifikation erforderlich Von Links nach Rechts Beispiele: P Q : Erst P, dann falls P TRUE auch Q P Q : Erst P, dann falls P FALSE auch Q IF P THEN E1 ELSE E2 : Erst P dann entweder E1 oder E2 Auswertung von Ausdrücken Warum spielt das eine Rolle? Sei x eine Sequenz. Betrachte: x[1]=0 Was passiert wenn x=<>? Sequenz: S [i (1..Len(S)) ] (x[1]=0) (x <>) (x <>) (x[1]=0) 1. Ausdruck möglicherweise fehlerhaft Bedenkt das beim Spezifieren!!!! Auch beim programmieren gibt es Analogien. Auswertung von Ausdrücken Weitere Auswertungsbeispiele: x S: p Erst s 1,..,s n in S, dann p wobei s i in p substituiert wird Falls S unendlich: Fehlermeldung!!!!!!! TLC kann nicht mit unendlichen Mengen umgehen {i (0..5): i < 4} OK {i Nat: i<4} Fehler x S: p analog CHOOSE x S: p analog Sonderfall: Falls kein x S existiert, sodass p gilt Fehlermeldung (TLA: undefinierter Wert) IF n > 5 THEN CHOOSE i 1..n:i>5 ELSE 42 OK IF n 5 THEN CHOOSE i 1..n:i>5 ELSE 42 Fehler Zuweisungen / Ersetzungen Für jede Konstante muss eine Zuweisung erfolgen Zuweisung von TLC-Values Beispiel: CONSTANT Data = {d1, d2} Auch Ersetzungen möglich Zuweisung zu definierten Symbolen Beispiel: TLA+: TLC: Problematisch (siehe letzte Folie) Ł NotAnS = NS (Overloading) Ł Ersetzt Definition Weitere Gründe: Performance beim checken (Sort, ebenfalls Overloading) Invariante: Auswertung der Werte (TRUE/FALSE) Init: Menge aller mögliche Init- Zustände Siehe Folie 31 Next: Ausgehend vom aktuell betrachteten Zustand Menge aller möglichen Nachfolgezustände Beispiel: Möglicher Nachfolgezustand 1 x 1 y <3,1> Aktueller Zustand x 1 y <2,3> Möglicher Nachfolgezustand 2 x 2 y <3,2> Möglicher Nachfolgezustand 3 x 2 y <2,3,2> 9

10 Vorsicht: Beispiel: Aktueller Zustand x y 1 <> Auswertung von Links nach Rechts x unbekannt Vorsicht: Möglicher Nachfolgezustand 1 x 2 y <2> Sequenz kann leer sein Tail(<>) =??? Aufbau zweier Datenstrukturen beim checken Graph G=(V,E), Sequenz U(V) v V: möglicher (erreichbarer) Zustand (v 1, v 2 ) E: Zustandswechsel v 1 v 2 i 1..Len(U): v u1, v u2 U[i]: v u1,v u2 sind ermittelte noch nicht betrachtete Zustände u1 u2 v u1 v u2 Erinnerung: v V v = Next Constraint Sei v 0 initialer Zustand, v n erreichbarer Zustand Es ex. Ein Pfad P=(v 0,,v n ) Algorithmus (vereinfacht): G = ({},{}), U = <> Checken, ob jede Zuweisung zu Konstanten erfolgen kann Finde alle möglichen Initialzustände Für jeden Initialzustand s: erfüllt es die Invariante? NeinŁFehlermeldung, Abbruch Füge s in U und V ein, füge Kante s s in E ein Solange U <> Entferne ersten Zustand s aus U Ermittle Menge T von möglichen Nachfolgezuständen ausgehend von s Falls T={} und Option Deadlock nicht aktiv Ł Fehlermeldung, Abbruch Für jeden Zustand t T: erfüllt t die Invariante? NeinŁ Fehlermeldung, Abbruch Falls t V:Füge t in V und U ein, Füge t t in E ein Füge s t in V ein Falls Anzahl der erreichbaren Zustände unendlich keine Terminierung!!! Simulations Mode Generierung von zufälligen (seedabhängigen) erreichbaren Zuständen. Wähle einen Zustand t aus T (nicht alle) Default: Checken von 100 Zuständen 10

11 : Features Aufruf von TLC Aufruf: Java tlc.tlc [-Optionen] Spezifikationsdatei Nicht wie im Buch angegeben tlatk.tlc!!! Einige Optionen: -deadlock (Standart mit Deadlockdetektierung) -simulate (Standart Model-Checking Mode) -seed num -coverage num (Listet alle num Minuten Anzahl der aufgerufenen Aktionen auf) : Features Fazit und Ausblick Probleme mit TLC Integers abgeleitet aus JAVA Begrenzung auf Intervall (2 31-1) TLC kann möglicherweise nicht alle möglichen Verhalten einer Spezifikation generieren Es kann aber Garantieren, dass alle erzeugten Verhalten eine Spezifikation erfüllt werden (oder nicht) TLC kann nicht mit dem hidding operator $ umgehen Checke Spezifikationen mit versteckten Variablen, also die innere Spezifikation Fazit und Ausblick Ratschläge bei der Anwendung von TLC: Füge Constraints ein um Komplexität klein zu halten (exponential) Erst einfache Fehler filtern Bei komplexen Spezifikationen: Simulation Mode Kein Fehler nicht immer gleich kein Fehler Gibt es überhaupt eine Next-Aktion, die ausgeführt wird? AltenateBit Protocol: Wird jemals gesendet? Verwende coverage Option Trickreiches vorgehen: Überprüfe falsche Eigenschaften: d Data: (sent = d) (sent = d) Nicht Sinn des Protokolls Evt. Initialzustand ändern Fazit und Ausblick Ratschläge bei der Anwendung von TLC: Statt INVARIANT Inv wobei Inv = A B C besser: INVARIANT A INVARIANT B INVARIANT C Eingrenzung möglicher Fehler Bei langer Laufzeit: Falls Fehler detektiert Beseitige Fehler, baue Initiales Prädikat mit den Zustand direkt vor dem Fehler Zeitersparnis Finde möglichst viele Invarianten für die Spezifikation Bessere Fehlerdetektierung Bsp (AltenateBit Protocol): Alle Nachrichten in msgq gleich 11

12 Fazit und Ausblick Ratschläge bei der Anwendung von TLC: Da wo es nicht anders geht, sei Trickreich n Nat:A(n) TLC kann nicht mit unendlichen Mengen umgehen Lösung: Überschreibe Nat in der Konfigurationsdatei durch (0..n) (Overloading) TLC nicht nur zum Zwecke einer Fehlerdetektierung Auch zum Verständnis/Übung in Umgang mit TLA+ empfehlenswert Literaturverzeichnis [1] Leslie Lamport, Specifying Systems, The TLA+ Language and Tools for Hardware and Software Engineers, Addison-Wesley, 2003 [2] Microsoft Research, The TLA+ Syntactic Analyzer, ( ) [3] Microsoft Research, The TLA+ Syntactic Analyzer, ( ) Steganographie ENDE DANKE FÜR DIE AUFMERKSAMKEIT Ende Anhang 12