Verification Techniques, Spring 2008

Related Courses:
Programming Theory (Parosh Abdulla):

Verification Technology

principles for verifying and analyzing sequential programs

Formal Program Development (Lars-Henrik Eriksson):

Spring 2008

Software Engineering (Roland Bol):

lecture 1

Operating Systems, Real Time Systems, Computer Networks

Systematic Development of correct programs

Organizing the development of software systems
Principles and algorithms for coordinating parallel and distributed
systems

Bengt Jonsson

Logic, Automata theory

We will use some of the theory from these courses.

Lecture 1

Verification Techniques, Spring 2008

Administrative

Goal:
Modeling, Specifying, and Analyzing concurrent, parallel,
and distributed algorithms, systems, and programs.
Contents:
Modeling parallel systems (as transition systems)
Specifying requirements and correctness properties
Algorithms for automatically checking that a model
satisfies a property

Instructors:
Bengt Jonsson, room 1435 bengt(at)it.uu.se
Mayank Saksena, room 1137 mayanks(at)it.uu.se
Course page
http://www.it.uu.se/edu/course/homepage/verteknik/vt08/
Examination:
5 homework exercises (solved in pairs)
Final exam on the topics covered in lectures.
SPIN
You must use SPIN for the exercises.

Model checking / state space exploration

You are encouraged to install SPIN on your own computer.

Application to algorithms encountered in operating

systems/computer networks courses
Analysis of concurrent software.
Use of Software tool for all the above: SPIN
Lecture 1

Installed at /stud/docs/kurs/ReactiveSystems/bin/spin
XSPIN at /stud/docs/kurs/ReactiveSystems/bin/xspin
Further material at http://spinroot.com/spin/

Lecture 1

Course Material

Structure of the Material

You will need

Lecture Handouts (slides)
A few papers (will be distributed)
SPIN documentation (on the WWW, and distributed)
Reference texts: You can choose one/several from
SPIN MODEL CHECKER Primer and Reference Manual by
Gerard Holzmann, good textbook for the course.
Design and Validation of Computer Protocols, G.J.
Holzmann, Prentice Hall 1991, older book, can be
downloaded from the net.
Old notes prepared by me some years ago.

The course is a close interplay between

Concepts and techniques for modeling,
specification, and verification
Implementation in the tool SPIN

Lecture 1

almost an exact realization of the theory

Application to examples

Lecture 1

Examination
Homeworks, to be solved in pairs. mandatory
Final exam
Each counts for half of your final grade.
HOW TO DO WELL:

Do the homework seriously

Make sure that you master the material so that you are able to solve
all exercises with moderate effort
Ask when things are not clear

Lecture 1

Verification

Lecture 1

Verification

Verification = building the system right

System
description

COURSE OVERVIEW:
What problems can be solved?

|=
conforms

Web server
implementation
Protocol standard
Functional spec.
..

Testing consumes ~half of software

development effort
Several expensive accidents caused by bugs

Correctness
properties

Absence of
Run-time errors
deadlocks
Memory leaks
Protocol service
..

Lecture 1

Ariane 5 crash 1996

Pentium division bug
Mars pathfinder ceased to work 1997
Viruses, .

Some of the Improvements needed

Lecture 1

10

Motivation: Idealized Design process

Better Development tools

Requirements

Programming languages
Development environments/Libraries
Software architectures

High level design

Better Skilled People

Better designers
better programmers
Better testers and verifiers

Detailed design

Better Processes

coding

Better Collaboration between developers / with customers

Better Documentation

testing

Better Verification Techniques

Testing and verification: This (and other) courses

deployment

Lecture 1

11

Lecture 1

12

Motivation: Idealized Design process

Introducing, Detecting and Correcting errors: cost

Errors detected: the later the more expensive

Requirements
Where most design
errors are made

High level design

Detailed design
coding

Where most
design errors are
found

testing
deployment

13

Lecture 1

Lecture 1

Verification Techniques: short overview

Verification Techniques: short overview

Testing: By far the most used technique

+ The most practical technique
+ Can verify a wide range of properties
- Can only be used on implementation
- Difficult to make exhaustive
- Hard to make reproducible for concurrent/distributed programs
- Manual selection of test cases and input needs work.

Static Program Analysis: Analyzing the source code by tools

+ Completely automatic
- Can verify a limited set of properties (type-correctness, absence of
some run-time errors)
- Tools available only for some languages and properties
Model Checking: Analyzing a prototype/model by tools
+ Can be done early in the design cycle, e.g., on design level.
+ Automated (provided tools available)
+ Can check many kinds of properties
- A model must be constructed (at a suitable level of abstraction)
- Model must be maintained when system evolves.
- Does not scale to very large models

Prototyping and Simulation:

+ Can be used on design level
- Difficult to make exhaustive
- Manual selection of test cases and input needs work
Code and Design Reviews:
+ Good at finding (some classes of) problems
- Needs organization and people
15

Lecture 1

Motivation: Purpose of Model Verification

Build model of the design.

Analyze it thoroughly

Detailed design
coding
testing
deployment

Lecture 1

Lecture 1

16

Problems that can be addresed by Model Checking

Requirements
High level design

14

Implement your
model, and spend
effort to check
conformance to the
model

17

Checking correctness of
Communication protocols
Distributed Algorithms
Controllers
Hardware circuits
Embedded and real-time systems and software
e.g.,
Absence of race conditions, deadlocks, livelocks, priority inversions,
proper synchronization, .
Model checking is the appropriate technique
when there are many many different
scenarios of interaction between components
in a system
Lecture 1

18

Merits of this simpler approach

CONTRAST: Assertional verification for data-centric programs

Checking simple properties (e.g. deadlock freeness) is already extremely

useful!

The goal is no longer seen as proving that a system is completely correct

(bug-free)

The objective is to have tools that can help a developer find errors and gain
confidence in her/his design. That is achievable

Now widely used in hardware design, protocol design, embedded systems,

...

What does this program do?

[Floyd 1967, Hoare 1969]

start
y1;y2:=x1,x2

y1==y2

print(y1)

stop

N
y1>y2

Y
y1:=y1-y2

y2:=y2-y1

19

Lecture 1

20

Lecture 1

WY3

How can a program check this fact?

CONTRAST: Assertional verification for data-centric programs

What does this program do?

start

[Floyd 1967, Hoare 1969]

start

y1,y2:=x1,x2

It computes the Greatest Common

Divisor (gcd) of x1 and x2

y1;y2:=x1,x2

y1==y2
Y

y1==y2

print(y1)

stop

N
N

Y
y1:=y1-y2

y1>y2

y1>y2

Y
print(y1)

stop

y1:=y1-y2

N
y2:=y2-y1

y2:=y2-y1
21

Lecture 1

WY4

22

Lecture 1

WY5

How can a program check this fact?

start

How can a program check this fact?

start

x1>0, x2>0

y1,y2:=x1,x2

x1>0, x2>0

y1,y2:=x1,x2

y1>0, y2>0, gcd(y1,y2)=gcd(x1,x2)

y1==y2

Y
print(y1)

y1>0, y2>0, gcd(y1,y2)=gcd(x1,x2)

stop

y1==y2

N
Y
y1:=y1-y2

y1>y2

Y
print(y1)

stop

N
N

y2:=y2-y1

Lecture 1

y1:=y1-y2

y1=gcd(x1,x2)

23

y1>y2

N
y2:=y2-y1

Can this be checked by a Lecture

computer?
1

y1=gcd(x1,x2)

24

Slide 22
WY3

Wang Yi, 29/03/2006

Slide 23
WY4

Wang Yi, 29/03/2006

Slide 24
WY5

Wang Yi, 29/03/2006

Static Analysis: Example (input)

Static Analysis: Example (output)

{n0>=0}
n := n0;
{n0=n , n0>=0}
i := n;
{n0=i , n0=n , n0>=0}
while (i <> 0 ) do
{n0=n , i>=1 , n0>=i}
j := 0;
{n0=n , j=0 , i>=1 , n0>=i}
while (j <> i) do
{n0=n , j>=0 , i>=j+1 , n0>=i}
j := j + 1
{n0=n , j>=1 , i>=j , n0>=i}
od;
{n0=n , i=j , i>=1 , n0>=i}
i := i - 1
{i+1=j , n0=n , i>=0 , n0>=i+1}
od
{n0=n , i=0 , n0>=0}

n := n0;
i := n;
while (i <> 0 ) do
j := 0;
while (j <> i) do
j := j + 1
od;
i := i - 1
od

25

Lecture 1

Static Analysis: Example (output)

{n0>=0}
n := n0;
{n0=n , n0>=0}
i := n;
{n0=i , n0=n , n0>=0}
while (i <> 0 ) do
{n0=n , i>=1 , n0>=i}
j := 0;
{n0=n , j=0 , i>=1 , n0>=i}
while (j <> i) do
{n0=n , j>=0 , i>=j+1 , n0>=i}
j := j + 1
{n0=n , j>=1 , i>=j , n0>=i}
od;
{n0=n , i=j , i>=1 , n0>=i}
i := i - 1
{i+1=j , n0=n , i>=0 , n0>=i+1}
od
{n0=n , i=0 , n0>=0}

26

Lecture 1

Overview of Model Checking

Model: M

Yes!

Model
Checker
implies that j does not overflow

Property:

No!
Error trace

implies that i does not underflow

27

Lecture 1

Overview of Model Checking

Lecture 1

28

Unveiling bad mutual exclusion algorithm

/* Bad Mutex Algorithm */

Promela

int x, y, z;

Model: M

void lock(int Pid)

{
busywait:
x = Pid;
if (y != 0 && y != Pid)
goto busywait;

Yes!

Model
Checker
Property:

z = Pid;
if (x != Pid)
goto busywait;

No!
Error trace

y = Pid;
if (z != Pid)
goto busywait;
}

Promela/
Temporal Logic

SPIN

Lecture 1

void unlock()
{
x = 0;
y = 0;
z = 0;
}

29

Lecture 1

30

Example with Concurrency

Model the example for the SPIN tool

int main(void) int main(void)

{
thread_t thread_id, main_id;
main_id = thr_self();
thr_setconcurrency(2);
thr_create(NULL, 0 , thread_sub, (void *)main_id, THR_SUSPENDED, &thread_id);

bool Suspend_main, Suspend_thread, arg;

active proctype main() provided (!Suspend_main) {
L_0:
do
:: c_code { Printf("MAIN: continuing subroutine thread\n"); };
c_code { fflush(stdout); };
Suspend_thread = 0;
c_code { Printf("MAIN: suspending self\n"); };
c_code { fflush(stdout); };
Suspend_main = 1;
od;
goto Return;
Return: skip
}

while(1) {
printf("MAIN: cointuing subroutine thread\n"); fflush(stdout);
thr_continue(thread_id);
printf("MAIN: suspending self\n"); fflush(stdout);
thr_suspend(main_id);
}
return(0);
}
void *tread_sub(void *arg)
{
thread_t thread_id;
thread_t main_id = (thread_t) arg;

active proctype thread() provided (!Suspend_thread) {

L_1:
do
:: c_code { Printf("THREAD: continuing main thread\n"); };
c_code { fflush(stdout); };
Suspend_main = 0;
c_code { Printf("THREAD: suspending self\n"); };
c_code { fflush(stdout); };
Suspend_thread = 1;
od;
goto Return;
Return: skip;
}

thread_id = thr_self();
while(1) {
printf("THREAD: cointuing main thread\n"); fflush(stdout);
thr_continue(main_id);
printf("THREAD: suspending self\n"); fflush(stdout);
thr_suspend(thread_id);
}
return((void *)0);
}

Lecture 1

31

Output from analysis by SPIN

Lecture 1

32

Hippies problem

THREAD: continuing main thread

THREAD: suspending self
MAIN: continuing subroutine thread
THREAD: continuing main thread
THREAD: suspending self
MAIN: suspending self

18: main(0):[Suspend_main = 1]
spin: trail ends after 18 steps
#processes 2:
18:
proc 0 (main) line
5 (state 7) (invalid end state)
Printf("MAIN: continuing subroutine thread\n");
18:
proc 1 (thread) line 20 (state 7) (invalid end state)
Printf("THREAD: continuing main thread\n");
global vars:
bit
Suspend_main:
1
bit
Suspend_thread:
1
bit
arg: 0

10

20

25

Hippies must get across bridge.

Crossing needs torch. There is only one torch.
At most two people can cross together.
Can all cross in at most 60 minutes?

...
Lecture 1

33

Lecture 1

Desiderata for good a model

How to make models

Captures essentials of behavior of system/program/algorithm

Should be simple to understand, and well-structured

Can be thoroughly analyzed (e.g., by SPIN)

By hand from a description of algorithm/system

As specification during system design
When analyzing existing programs
By hand from code
By automated extraction tools from program code

To validate that you model the correct thing

Avoid unnecessary complications
Try to abstract/simplify necessary complicated aspects
Not too big

ModEx adapts ANSI-C code to SPIN

Hard problem: automated simplification

Lecture 1

34

35

Automatically from test suites

Lecture 1

36

Reachable?
(bug?)

Example of Model

Remaining Problems
Constructing a Model
not so easy, this course will make you experts

An abstract version of a field bus protocol

Making absolutely sure that the actual system/software conforms to the

model
hard problem: there are several techniques:

Conformance testing
Static program analysis
Automated code generation

37

Lecture 1

Small Idealized Example from Reality

38

Lecture 1

Idealized model of processes

Small Example: Mars Pathfinder 1997

Typical properties of synchronization in real-time systems
Mutual exclusion

High priority process

A process cannot access the data-bus unless it owns a mutex-lock

idle

Scheduling priority
Saving data to memory has higher priority than processing data
Low priority process cannot execute when high priority process is ready
to execute or executes

run
wait

39

Lecture 1

Idealized model of processes

40

Lecture 1

Idealized model of processes

Variables: l: integer
Initially
l=1

High priority process

Low priority process

idle

High priority process

idle

idle

run

l := 1

High@idle -> l := 1

run

run
wait

Low priority process

wait

l = 1 -> l := 0

run
wait

wait

High@idle /\ l = 1

Lecture 1

41

idle

Lecture 1

->

l := 0

42