1. Model Checking of Multi-Process Applications Using SBUML and GDB
Yoshihito Nakagawa* (University of Tokyo)
Richard Potter (Japan Science and Technology Agency)
Mitsuharu Yamamoto (Chiba University)
Masami Hagiya** (University of Tokyo)
Kazuhiko Kato (Tsukuba University)
DSN-2005, Yokohama
Workshop 1: Dependable Software - Tools and Methods
2005/6/29 14: :00 (20 min.)
*NAMCO
**Speaker

2. Background Model checking Focus on verification of program code
Verification of concurrent systems
Systematic exploration of the state space
E.g., ensure no deadlock occurs
Focus on verification of program code
SLAM[Ball et al 01], Blast[Henzinger et al 03]
Verisoft[Godefroid 97], CMC[Musuvathi et al 02]

3. Our Goal Real-environmental model checking Issues:
Use of OS resources (e.g., file system)
Flexible control of the granularity of scheduling
Evaluation of practicality by sample applications
Issues:
Provide real execution environment
Control nondeterminism in execution order
Traverse all nondetermistic choices

4. Method SBUML + GDB Implementation of model checker by Ruby1.8.1
Real execution environment
Virtual machine technology
Control nondeterminism
Breakpoints in debugger
Traverse all nondeterminstic choices
Backtracking by saving/restoring execution states of virtual machine
Implementation of model checker by Ruby1.8.1
Internal/external monitor, GUI
Verification of concrete sample applications
Dining philosopher, Remote agent experiment

5. Virtual Machine and User-Mode Linux
Provide virtual (guest) OS on top of real (host) OS
Various implementations
VMWare, Virtual PC, Bochs, CoLinux, UML, Xen, LilyVM, …
Progress of CPU and growth of memory made them practicable
User-mode Linux (UML)
Extension to Linux kernel (by Jeff Dike)
Open source
Execute guest Linux on host Linux

6. ScrapBook for User-Mode Linux
Host OS
Virtual machine
Further extension to User-mode Linux
UML Scrapbook and Realization of Snapshot Programming Environment [Sato, Potter 03]
Script language support

7. ScrapBook for User-Mode Linux
Host OS
Virtual machine
Further extension to User-mode Linux
UML Scrapbook and Realization of Snapshot Programming Environment [Sato, Potter 03]
Script language support

8. Overview of Model Checker
SBUML
GDB
Process
External
Monitor
Internal
Monitor
GDB
Process
GDB
Process
save/restore
Target
Application

9. GDB Control process execution by breakpoints
SBUML
GDB
Process
External
Monitor
Internal
Monitor
GDB
Process
GDB
Process
save/restore
Target
Application
Control process execution by breakpoints
Where the execution of a process may block
Where the computation result depends on the execution sequence of processes

10. Internal Monitor Which process can be resumed without blocking
SBUML
GDB
Process
External
Monitor
Internal
Monitor
GDB
Process
GDB
Process
save/restore
Target
Application
Which process can be resumed without blocking
Blocking condition, inspection function (given by hand)
Execution states of virtual machines
Program counters, blocking condition, shared variables

11. External Monitor Determine process that should be restored next
SBUML
GDB
Process
External
Monitor
Internal
Monitor
GDB
Process
GDB
Process
save/restore
Target
Application
Determine process that should be restored next
Depth-first search of the execution state space
Backtracking by saving/restoring execution states of virtual machines

12. Toy Example: Dining Philosopher Problem
(a) Initial state
(b) Deadlock
N = 3
Each philosopher repeats to think and eat
Potential deadlock

13. Verification Code implemented by C
while (1) {
read(pipes[i%NUM].fd[0],&c,1);　　　　　　　// (A)
printf("%d takes his left fork...\n",i);
read(pipes[(i+1)%NUM].fd[0],&c,1); // (B)
printf("%d takes his right fork...\n",i);
printf("%d waiting...\n", da->id);
write(pipes[i%NUM].fd[1],&c,1);
printf("%d leaves his left fork...\n",i);
write(pipes[(i+1)%NUM].fd[1],&c,1);
printf("%d leaves his right fork...\n",i); }
int pipe_readable(int fd) {
fd_set rfds;
struct timeval timeout = {0, 0};
FD_ZERO (&rfds);
FD_SET (fd, &rfds);
return select(fd + 1, &rfds, NULL, NULL, &timeout); }
Inspection function:
User-defined (and added) function for verification
Target Code:
Task for each philosopher,
Variable i … Philosopher ID
Code implemented by C
Philosopher as process, fork as pipe

14. Result
8 states in total (1 deadlock)

15. Example: Remote agent experiment (RAX)
Software for spacecraft control
Developed by NASA Ames conjointly with JPL
Deadlock occurred during actual flight
Error identified from flight data
Challenge to formal method team
Verification with keeping the error cause secret
Error detection by Java Path Finder [Havelund, Lowry ’00]

16. Remote agent experiment (RAX)
sleep !
sleep
Proc. 1
sleep
sleep
Proc. 2
Interaction between two processes
Each process repeats <wake up>, <sleep>
If a process in action get notification <wake up>, then skip the next <sleep>

17. Target Code Fragments Possible deadlock (A)  (C)  (B)
void *first_task(void *ev) {
struct event *e1 = (struct event *)ev;
struct event *e2 = e1+1;
int count = 0;
while (1) {
if (count == e1->count) /* (A) */
sleep(e1); /* (B) */
count = e1->count;
wake_up(e2); }
void *second_task(void *ev) {
struct event *e1 = (struct event *)ev;
struct event *e2 = e1+1;
int count = 0;
while (1) {
wake_up(e1); /* (C) */
if (count == e2->count)
sleep(e2);
count = e2->count; }
Possible deadlock (A)  (C)  (B)
Proc. 1 may overlook the <wake up> call by Proc. 2 1
sleep ! 2

18. User-defined (and added) function for verification
void cond_wait(struct event *e) {
static struct sembuf sop_dec_both[]
= {{SEM_MUTEX, -1, 0},
{SEM_COND, -1, 0}};
static union semun {int val;} arg = {0};
e->waiting = 1; mutex_unlock(e);　
semop(e->semid, sop_dec_both, /* (i) */
sizeofarray(sop_dec_both));
e->waiting = 0;
semctl(e->semid, SEM_COND, SETVAL, arg); }
void mutex_lock(struct event *e) {
static struct sembuf sop_dec_mutex[]
= {{SEM_MUTEX, -1, 0}};
semop(e->semid, sop_dec_mutex, /* (ii) */
sizeofarray(sop_dec_mutex)); }
int can_lock(struct event *e) {
return semctl(e->semid, SEM_MUTEX, GETVAL); }
int can_resume(struct event *e)
return semctl(e->semid, SEM_MUTEX, GETVAL)
&& semctl(e->semid, SEM_COND, GETVAL);
Where process may block
IPC semaphore operations
(i), (ii)
Blocking condition
(i) can_lock(e) == 0
(ii) can_resume(e) == 0
Inspection function:
User-defined (and added) function for verification

19. Verification (2) Where the result depends on the execution order
void *first_task(void *ev) {
struct event *e1 = (struct event *)ev;
struct event *e2 = e1+1;
int count = 0;
while (1) {
if (count == e1->count) /* (1) */
sleep(e1, count);
count = e1->count; /* (2) */
wake_up(e2); }
void *second_task(void *ev) {
struct event *e1 = (struct event *)ev;
struct event *e2 = e1+1;
int count = 0;
while (1) {
wake_up(e1);
if (count == e2->count) /* (3) */
sleep(e2, count);
count = e2->count; /* (4) */ }
Where the result depends on the execution order
Access to shared variables {e1, e2}
(1)～(4)
Blocking condition always returns “false”
Never blocks here

20. Experimentation Result
Total time
15min 13sec
Number of states
116(4 Deadlocks)
Save count 66
Restore count
Save time
Total: 160sec Average:2.42sec
Restore time
Total: 59.3sec Average:0.90sec
Snapshot size
Total 2.4Gb Average:37Mb
Result
CPU
Dual 2.8GHz Pentium Xeon
RAM
2GB OS
Red Hat Linux 8.0
Specs

21. Possible Application: “Mbox Locking Problem”
Several programs make access to a single mail spool
MDAs, POP/IMAP servers, MUAs
Different lock mechanisms
fcntl, flock, “dot-locking”
Some programs support them only partially
Danger of deadlock/livelock
Real environmental example
Shared resource in a file system

22. Related Works Use of modified SBUML scheduler [Sato, Potter 03]
Lack of flexibility
Granularity in scheduling … per system call
Ad-hoc way to extract information about execution states
CMC [Musuvathi 02]
Verification by execution of event-driven program
Backtracking by saving/restoring global variables and heap
Verisoft [Godefroid 97]
Backtracking by re-execution from the initial state

23. Discussion Search strategy depends of the relation between:2 B 1 C 1
: State ID
: Process ID A
Restore C => Resume 2 and Resume 1
Search strategy depends of the relation between:
restore time
execution time till the next breakpoint

24. Conclusion Framework for real-environmental model checking
Verification of sample applications in “practicable” time
Flexible framework
Arbitrary granularity in scheduling

25. Current Limitations User must specify some items
Breakpoints, blocking condition
Inspection function
Define execution states (hash values)
No multi-thread applications support
GDB cannot handle selective execution of threads reliably

26. Future Work Automatic generation of items for verification
Static analysis of target program
Much more speed-up
Combination with re-execution
Execution on cluster machines
More complicated examples
Mbox locking problem