Incremental Model Checking for Distributed Programs
Svetoslav Ganov
Electrical and Computer Engineering
University of Texas at Austin
Austin
Texas, USA
svetoslavganov@mail.utexas.edu
ABSTRACT
In distributed programs computation is dispersed in several
processes (threads). These processes communicate and often
share common resources, while working cooperatively towards
performing a common task. The use of shared resources implies
risk of concurrency and deadlocks. Checking a distributed
program for such properties is problematic because of the large
number of possible thread interleavings. Manual testing is tedious
and not feasible in terms of time and completeness. Model
checking is an automated approach for testing of distributed
programs that systematically explores the entire state space of
thread interleavings while monitoring for certain property
violations. While this approach addresses the main weakness of
manual testing, it suffers from the combinatorial explosion
problem caused by the exponentially growing state space with
respect to the number of processes in the distributed program.
This paper proposes a novel approach for testing distributed
programs written in Java using Java PathFinder model checker
that address the combinatorial explosion problem by reducing the
state space to be explored. We introduce the idea of incremental
model checking. We iteratively use smaller scope
counterexamples as partial trace for subsequent searches in
increased scope until the scope of the original program is
reached.
Categories and Subject Descriptors
Testing and Debugging – Model Checking, Testing tools
General Terms
Verification
Keywords
Incremental Model Checking, Java PathFinder, Dining
Philosophers, Lamport Mutex, Leader Election
1. INTRODUCTION
A distributed program consists of two or more separate
computations collaborating in fulfillment of a common task. Such
a program may run on a single machine or on multiple machines
in a network setting where each of the computations is a separate
thread or process. Distributed programs exploit contemporary
advancements in networking and provide a scalable approach for
solving complex problems and allow building of fault tolerant
software systems.
Venkat Balachandran
Electrical and Computer Engineering
University of Texas at Austin
Austin
Texas, USA
bvenkat@mail.utexas.edu
The distribution of computation implies use of shared resources
thus introducing a whole new raft of specific issues such as
concurrency and deadlocks. Further, the behavior of some
distributed algorithms may depend on the communication
sequence between the processes (threads). Hence, checking for
properties of distributed programs implies exploring of all
possible interleaving between the consisting entities (processes,
threads) since it is possible that certain fault is detected only in a
specific sequence of interactions.
Manual execution of all such sequences is tedious and not feasible
because of the large state space to be explored and the difficulty
to systematically enumerate all the possible states. This is further
compounded by the fact that the behavior of a process (thread)
could be altered by interaction with other processes.
Model checking is an automated approach for thorough testing of
the behavior of a system by exploring its entire state space and
monitoring for certain property violations. This systematic
exploration of the entire state space of the model makes model
checking suitable for testing the correctness of distributed
programs. While this approach addresses the main weakness of
manual testing, it suffers from the combinatorial explosion
problem caused by the exponentially growing state space with
respect to the number of processes in the distributed program.
This exponential increase of the state space increases the time
needed by the model checker to complete its search.
We propose a novel approach for testing distributed programs
with a model checker that attempts to address the combinatorial
explosion problem by reducing the state space to be explored. The
reduction of the state space leads to decrease in the time needed
for completing the search. We introduce the idea of incremental
model checking. We iteratively use smaller scope
counterexamples as partial trace for subsequent searches in
increased scope until the scope of the original program is reached.
Our approach starts by decreasing the scope of the original
program by reducing the number of processes and runs it into the
model checker. Since the smaller scope corresponds to smaller
state space we find a counterexample (if any) faster and use it to
guide the search for the next iteration with increased scope, thus
pruning regions of the state space. Note that the existence of
counterexample in smaller scope does not guarantee that such one
exists for the bigger scope. During the scope reduction a mutation
could be introduced causing the state space of the reduced
problem to not be a subset of the state space of initial problem.
Moreover, it is possible that a counter example does not exist for
a scope less than a definite threshold. For the purpose of this
research we use JPF (Java PathFinder) [1] model checker
developed by NASA AMES Research Center. JPF checks the
properties of Java programs.
The rest of the paper is organized as follows: We first define
model checking and introduce the Java PathFinder model checker.
We then describe the subject algorithms and our methodology.
Finally, we present our results, discuss some related work and
provide our conclusions.
2. MODEL CHECKING AND JPF
Model checking means checking if a model satisfies a given
logical formula (also called assertion). A model is given as a
source code and logical formula is verified at each state of the
program. Transitions enable change of the state of the program.
The source code corresponds to a graph with nodes representing
the states of the system and transitions being the edges through
which one can move across the states. Model checkers face the
problem of state space explosion and there are some partial
solutions to this problem:
(a) Creating a Binary decision diagram instead of a graph
(b) Partial order reduction could be applied to reduce the number
of interleavings of concurrent processes
(c) Abstractions are used to simplify a system and then proving
the properties on the simplified system is done [13].
2.1 JPF Model Checker
Java PathFinder is a model checking tool that has been developed
by the NASA and is a software model checker for java bytecode.
Technically JPF is a JVM written in Java that runs on top of a
host VM. It executes the Java code not once but theoretically in
all possible ways, checking for property violations like deadlocks
and unhandled exceptions (by default) along all potential
execution paths. JPF also detects invariants in the program. An
invariant is specified as a java code that evaluates the program
states and returns a Boolean value. If it finds an error, JPF reports
the whole path that lead to the error. The kind of defects that are
found by JPF include deadlock and unhandled exceptions but the
user can also specify her own invariants (in the form of
assertions). Race Conditions are also detected by JPF [3].
The basic structure of JPF is shown in Figure 1. JPF is itself
written in Java and it consists of its own Virtual Machine. The
virtual machine does efficient memory management but does not
have high processing speed. The way JPF works is that the Java
program that needs to be model checked is converted to bytecode
and fed as input to the JPF. The JPF itself consists of two parts: (i)
the JVM that executes the bytecode; (ii) the depth first search
algorithm that traverses the state graph of the program; The depth
first search algorithm tells the JVM to either move forward one
step or move backward one step and evaluate the current
invariant. JVM also keeps track of the states that it has already
visited by storing them in a hashtable. Whenever it encounters a
state that it has already seen earlier, it backtracks and explores
new choices. The output of JPF is whether or not the invariant
holds and if the invariant does not hold, it produces a
counterexample along with the trace of the path that led to the
creation of this counterexample [12]. We next describe some of
the salient features of JPF:
a) Canonical Heap Representation: In any execution that has
interleaving of statements, dynamic and static memory is
allocated at the same memory location as it was in the previous
interleaving execution.
b) Garbage Collection: The JPF-JVM has its own garbage
collector to increase the state space of the execution.
c) Atomicity: The level of atomicity can be set to one bytecode
execution or a block of java code that are independent with
respect to any code that is running concurrently with it. JPF
supports POR (Partial Order Reduction) that automatically
encapsulates in atomic blocks sequences of Java code that are not
relevant to the multithreaded interactions.
d) Structured State: Each state of the program stored with the
JPF-JVM is highly structured and it contains a number of
different java classes.
e) Nondeterminism: In order to simulate nondeterminism, JPF
provides two methods Verify.Random(i) and
Verify.Randombool() that return a non deterministic integer
between 0 and i or a non deterministic TRUE and FALSE values
respectively.
JPF can simulate non-determinism by using two methods:
a) Backtracking: What this means is that when JPF reaches a
program end state, it can walk backwards to the previous states to
check if there are any unexplored choices left and proceeds along
that path.
b) State Matching: Whenever JPF sees a new state, it first checks
if it has already explored this state using its snapshots. If it finds
that it has already seen this state, it backtracks to the previous
state and checks if there are any unexplored states.
Figure 1. JPF architecture
Due to the fact that JPF explores all possible choices in a
program, it does not scale well for programs that have more than
10,000 lines of code. Heuristic choice generators in JPF which
explores just enough states to ensure that the program is bug free
rather than exploring all the states is one method to reduce this
state space explosion. For example, if we have an integer then
instead of exploring all possible values of an integer, heuristic
choice generators enable JPF to just explore the three values a)
Greater than threshold b)Equal to Threshold and c)Less than
threshold [12].
Because JPF does check the bytecode, errors at the bytecode level
can also be caught. JPF can also perform symbolic execution of a
code that uses complex data structures such as linked list and
trees.
The programs that could be checked by JPF are Java programs
that do not include any native methods. This means that graphics,
applets, swings etc are not supported by JPF. Any GUI
application cannot be model checked using JPF. However, a work
around for such GUI applications could be simulating the
different user interactions such as click of a button etc.
Furthermore, JPF cannot handle certain language features such as
floating point numbers. However, JPF is especially useful for
verifying concurrent Java programs because it systematically
explores all the scheduling sequences.
2.2 Logic of JPF
JPF finds counterexamples by navigating through the state space.
The way it does so is described with the help of a diagram below
(Figure 2).
State 1
State 2
State 3 State 4
Figure 2. State space example
When JPF makes a choice it leads to a state. JPF starts at State 1,
if it finds a counterexample at State 1, it reports the
counterexample and exits. Else, it goes to State 2 and does the
same. If it does not find the counterexample at State 2, it then uses
heuristics for making the next choice and explores one of the
paths. Without loss of generality, let it goes to State 3. If JPF
does not find a counterexample at State 3, it observes that there
are no further paths to explore and it marks the choice generator
in State 3 as done. It then backtracks to State 2. JPF ascertains
that there is one more available path that is not explored yet and
goes to State 4. If it does not find a counterexample at State 4, it
marks the choice generator in State 4 as done and backtracks to
State 2. JPF now observes that there are no further unexplored
paths from State 2 and marks the choice generator of State 2 as
done. JPF then backtracks to State 1 and observes that there are
no further unexplored paths. So, it marks choice generator of
State 1 as done. Once it has marked all the states as done and no
property violation is detected, it prints No errors found and exits.
JPF provides an option for replaying the trace from previous
search that has detected property violation. This file contains the
list of choices that JPF has made during the state space
exploration. In case of replaying of a trace JPF makes only the
choices specified in the file and when making a choice, it marks
the choice generator as done precluding the opportunity of
backtracking to it and exploration of other states.
For example, let the file specify that JPF must go from State 1 to
State 2 and then to State 4. Once JPF visits State 4 it marks the
choice generator of state 4 as done and then once it backtracks to
State 2, it marks the choice generator for State 2 as done even
though it has not visited State 3 because the file did not have a
choice that corresponds to visiting State 3.
For better understanding, below are a few sample lines from the
trace file of Java Path finder:
[0] gov.nasa.jpf.jvm.choice.ThreadChoiceFromSet 1
[1] gov.nasa.jpf.jvm.choice.ThreadChoiceFromSet 1
[2] gov.nasa.jpf.jvm.choice.ThreadChoiceFromSet 1
The integer in the last column indicates the choices the JPF needs
to make.
3. Applications
There were three major applications that were chosen for this
study. They are (i) Dining Philosophers, (ii) Leader Election and
(iii) Lamport Mutex algorithms. The reason these algorithms were
chosen is that they (i) Are typical examples of an algorithm in a
distributed systems applications , (ii) Can cause deadlocks and
mutual exclusion violations if not implemented properly and
We know describe each algorithm in a little detail.
3.1 Dining Philosophers
A pictorial representation of Dining Philosophers problem is
given in Figure 3. “The dining philosophers problem is an
abstraction of the resource allocation problem in a network. The
dining problem consists of multiple philosophers who spend their
time thinking and eating spaghetti. However, a philosopher
requires shared resources, such as forks, to eat spaghetti. The aim
of the protocol is to coordinate access to the shared resources to
the shared resources i.e. philosophers. There are two requirements
on the solution of the dining philosophers problem. First, we
require mutually exclusive use of shared resources, that is, a
shared resource should not be used by more than one process at a
time. Second, we want freedom from starvation. Every
philosopher (process) should be able to eat (perform its operation)
infinitely often. The crucial problem in resource allocation is that
of resolving conflicts. If a set of processes require a resource and
only one of them can use it at a time, then there is a conflict that
must be resolved in favor of one of these processes. It is clear that
if the processes are indistinguishable and the conflict resolution
method is completely deterministic, then a conflict resolution is
not possible. Hence we insist that in every conflicting set of
processes, there is at least one distinguishing process.
To solve this problem, it is modeled as a conflict graph problem
in which each node represents a process and an edge between two
processes denotes that one or more resources are shared between
the two processes. If a process needs all the shared resources for
performing its operation, then only one of the two adjacent nodes
can perform its operation in any step.
An orientation of an undirected graph consists of providing
direction to all edges. The edge between two process P1 and P2
points from P1 to P2 if P1 has precedence over P2. A node in this
conflict graph is called a source if it does not incoming edges. To
maintain orientation of an edge, we use the notion of an auxiliary
resource, a fork, associated with each edge. Process P1 is
considered to have the fork associated with the edge P1-P2 if it
has precedence over P2 in any conflict resolution” [4]. The
algorithm for dining philosophers is shown in Figure 4 and is var
based on following two rules hungry, eating, thinking: boolean
(a) “A process can eat only if it has all the forks for the fork(f), request(f), dirty(f): Boolean
edges incident to it i.e. a process can eat only when it is initially
a source.
1. All forks are dirty
(b) When a philosopher is hungry, it requests the fork and
2. Every fork and request token are held by different
we associate a request token with every fork”[4].
Philosophers
There are two finer points to this algorithm
3. H is acyclic.
(a) “The state of a philosopher is determined by the
To request a fork:
following Boolean variables {thinking, hungry, eating}.
The transition from thinking to hungry is determined by if hungry and request(f) and ¬fork(f)
the philosopher and the philosopher may stay in the send request token for fork f;
thinking state for an arbitrary amount of time. Once a
request(f): = false;
philosopher is in hungry state, it is the responsibility of
the algorithm to ensure the transition from the hungry to Releasing a fork
the eating state. Once the process is in eating state, it if request(f) and ¬eating and dirty(f) then
should return to thinking state in a finite amount of send fork f;
time.
dirty(f):=false;
(b) There is a Boolean variable called ‘dirty’ with each fork(f):=false;
fork. This is just to distinguish the scenario when a
philosopher has the fork but has not used it from the
case when the philosopher has a fork and has used it for Upon receiving a request token for fork :
eating. Before the fork is sent to a neighbor it is Request(f):=true;
cleaned”[4].

Upon receiving a fork f:

Fork(f):=true;
Figure 4. Dining Philosophers algorithm [4]

(v) A process determines that it can access the critical section if

and only if

(a) It has a request in the queue with timestamp t, and

(b) t is less than all other requests in the queue

(c) It has received a message from every other process with

Figure 3. Dining Philosophers diagram
timestamp greater than t”[4].

3.2 Lamport Mutex

Lamport’s algorithm is an algorithm for mutual exclusion. The
algorithm ensures that processes enter the critical section in the
order of timestamp of their requests. The algorithm is shown in
figure 5. The basic steps of the algorithm are

(i) “To request the critical section, a process sends a timestamped

message to all other processes and adds a timestamped request to
the queue.

(ii) On receiving a request message, the request and its timestamp

are stored in the queue and an acknowledgement is sent back.

(iii) To release the critical section, a process sends a release

message to all other processes.

(iv) On receiving a release message, the corresponding request is

deleted from the queue.
Pi:
var
v: depclock; //direct dependency clock
q:array[1….N] of integer initially (∞, ∞,∞,…..,∞);
request:
q[i]:=v[i];
send (q[i]) to all processes; //request messages
release:
q[i]:=∞
send q[i] to all processes //release messages
receive (u)
q[u.p] = u.q[u.p]
if event(u) = request then
send ack to process u.p; ;// acknowledge “request”
Figure 6. Lamport Mutex Algorithm [4]
Figure 5. Leader Election diagram
3.3 Leader Election
A pictorial representation of leader election algorithm is shown in
Figure 6. As the name suggests, the leader election algorithm is
used to elect the leader from a set of process which are arranged
in the form of a ring. The algorithm that we consider in this paper
is the Chang-Roberts algorithm. “The algorithm ensures that the
process with the maximum identifier gets elected as the leader.
Every process sends messages only to its left neighbor and
receives messages from the right neighbors. A process can send
election message along with its identifier to its left, if it has not
seen any message with a higher identifier than its own identifier.
It also forwards any message that has an identifier than its own
identifier. It also forwards any message that has an identifier
greater than its own; otherwise, it swallows that message. If a
process receives its own message, then it declares itself as the
leader by sending a leader message.
In this algorithm, one or more processes may spontaneously wake
up and initiate the election. When a process wakes up, either
spontaneously or on receiving a message, it first executes the
wake up procedure before receiving the message. A process
knows that the election is done when the leaderid is not null” [4].
The algorithm is shown the Figure 7.
Pi::
var
myid: integer
awake: boolean initially false;
leaderid: integer initially null
To initiate election
Send (election, myid) to Pi-1
Awake:=true;
Upon receiving a message (election, j):
if (j > myid) then
send (election, j) to Pi-1
else if (j==myid) then
send (leader, myid) to Pi-1
else if ((j<myid) ∧ ¬awake) then
send (election, myid) to Pi-1
awake:=true;
Upon receiving a message (leader, j)
leaderid:=j;
if(j≠myid) then send(leader, j) to Pi-1
Figure 7. Leader Election algorithm [4]
4. Implementation Details
To enable model checking, we forcefully introduced bugs in each
of the algorithms and then tested the algorithms using JPF to
detect deadlocks and assertion violations. We describe briefly the
methodology by which the bugs were introduced into the
algorithms.
4.1 Dining Philosophers
We modified the algorithm in way that a deadlock of the system
is possible. We implemented this as follows: We did not use the
concept of dirty or clean fork and request token. Instead,
whenever a philosopher becomes active, she goes to hungry state
and tries to grab first the left and then the right fork. She then
goes to eating state. Eating is simulated by sleeping for one-
hundred milliseconds. After that, the philosopher goes into
thinking state modeled by sleeping for one-hundred milliseconds.
The philosopher then tries to eat again. This sequence is repeated
in a cycle. Such implementation of the algorithm induces the
possibility of a potential deadlock when there are two or more
philosophers. The invariant in this case is “There is no deadlock
in the system”. If the invariant is violated a counterexample is
provided by JPF.
We tried to introduce different kinds of bugs in the algorithm and
explored the applicability of our approach. For example, one of
the modifications we tried was, each odd philosopher takes the
left fork first and then the right fork, while each even philosopher
takes the right fork first and then the left. Another example is to
change the behavior of one philosopher to be different from the 5.1 Dining Philosophers
behavior of the rest. When we ran the algorithm using the defective logic described in
section 4.1, the following are the results that we have obtained.
4.2 Lamport Mutex
We introduced a defect in Lamport Mutex in three ways (i) Every From To Without With Improvement
odd or even numbered process could enter the critical section Threads Threads trace Trace (%)
without explicitly requesting for it and checking if entering the 2 4 402 207 50%
critical section is allowed. (ii) Processes could enter the critical
section when its request timestamp is the lowest in the request 2 6 3650 3248 12%
queue OR when its request timestamp is the lowest in the direct 3 6 3650 1677 54%
dependency clock queue but NOT both and (iii) process with id
2 5 1186 1131 5%
equal to two could enter the critical section without explicitly
requesting for it and checking if entering the critical section is Table 1. Results for Dining Philosophers
allowed. We clearly see that the effect of using a trace of the previous run
The logic behind inducing such defects in the code was to make helps us in finding assertion violation after visiting lesser number
possible more than one process to enter the critical section at the of states for a bigger number of threads/process. The percent
same time. The assertion that we stated in the program was improvement is also shown. We find that in some cases (for
“Number of processes in the critical section is no more than one”. example scaling from 2 to 5 and from 2 to 6) the improvement is
If this assertion is violated in the above scenario, we would get a not very great. The improvement basically depends on how
counterexample. symmetric the old and the new problems are. More the symmetry,
more will be the improvement.
4.3 Leader Election
For the leader election part, we altered the code in a way that each 5.2 Leader Election
process declares itself as a leader once it gets a leader message. In the Leader Election algorithm, we noticed an even better
The assertion that we have is “There is only one leader in the improvement than in the Dining Philosopher’s problem. The
system”. following are the results of the Leader Election algorithm when
Other modifications of the algorithm that we tried include: the we run it with a defective code as described in Section 4.3
process with id equal to two announces itself as a leader without From To Without With Improvement
election; when a process receives a message with id greater than Threads Threads trace Trace (%)
or equal to its id minus one; If this assertion is violated, in the
3 6 238 209 13
above scenario, JPF would detect an assertion violation.
6 9 490 293 40
4.4 Testing Methodology
9 12 832 302 64
Once the above three algorithms are made defective using the
modifications described above, we proceed to test the code using 12 14 1109 371 66.5
JPF. The flow of the testing is as follows: (i)We test the programs 14 17 1602 441 73
for large number of process (N) without using a partial trace and
Table 2. Results for Leader Election
note down the number of explored states (A) to get a
counterexample; (ii)We enable trace capturing and run JPF for a As we can there is a substantial improvement in the results once
small number of processes (n << N) and note down the number of we guide the JPF and it finds assertion violations much more
explored states (B) to get a counterexample; (iii)We run the easily than if we let it run normally.
program for N processes using the trace from the previous step to
guide the search and note down the number of explored states (C) 5.3 Lamport Mutex
to get a counterexample; We determine the improvement due to For the Lamport Mutex algorithm we noticed no improvement in
using the partial trace using the formula: the number of explored states even after replaying the trace of
smaller runs. Even in most of the cases replaying the trace was
R = (A – (B + C) / A) * 100 not possible. After some brainstorming we concluded that the
We explored different values for n and N, thus experimenting reason for these results is the fact that the state space of the
with various scaling factors between two consecutive steps. program mutates with changing the number of processes. This
During this iterative process we observe the improvement in explains why we can not replay a trace for smaller scope or in the
terms of number of states explored by the model checker. few cases when this was feasible the results were unsatisfactory.
However, how could we recognize that an algorithm would have
5. Results such a property? A logical explanation is that the behavior of a
In this section we present the empirical results obtained during process depends on its interaction with all the other processes in
our research and provide some interpretations of the results. For the system (i.e. the behavior depends on the number of processes
each of the modified algorithm we report the results in separate in the system). For this algorithm a process needs acks from all
sections. the other (N – 1) processes to enter the critical section. For
example, if we have a stored trace for four processes, every time
before one of them enters the critical section it needs three
acknowledgements. Now, if we try to use this trace for eight
processes during the replay no process will be able to enter the
critical section (because it needs seven acks), even though for the
scope of four it was able to do that. This means that the state of
the system for the first four processes will not replicate the one
from the previous run (smaller scope), which makes the
consecutive choices in the trace irrelevant.
5.4 Bug Fix in Java PathFinder
Initially, when we tried to scale a counterexample by replaying a
trace file, we found out that we were getting ‘No error found’
every time we increased the scope. We then tried to create our
own code for replaying the choices from the trace file. JPF
provides the opportunity of creating listener classes and
registering objects of these classes in the search and JVM. This
allows us to execute particular event handlers when a specific
event occurs. During our implementation we added several
control prints, in particular in the event just before a new choice is
to be made. This printing showed that while replaying the trace
JPF starts to backtrack until it reaches the initial state. Note that
when trace is used JPF marks the choice generators as done and
no backtracking on them is possible. Then, while replaying a trace
if JPF reaches an already explored state, it would backtrack until
the initial state and report that no error is detected. To understand
the cause of this problem we started to compare the choices from
the trace file and the ones printed during the replay phase. We
noticed that choices start to repeat in a loop once JPF reaches the
end of the file. What JPF should do is once it is done with
execution of the trace file it should start searching from that point.
After manual inspection of the source code of JPF we localized
and fixed the problem. We also sent a patch to Peter Mehlitz of
NASA. Note that to solve this problem we had to study the
architecture of JPF and understand the way JPF works.
6. Related Work
An earlier work related to model checking was done by Tatsuhiro
Tsuchiya and Andre Schiper [9]. Their job was to verify
asynchronous ‘heard of’ (HO) model based algorithms for solving
consensus problems in Distributed Systems. Their idea was to fix
the total number of processes but explore every possible state
with these fixed processes. They use symbolic model checking
wherein Boolean functions represented by Binary Decision
Diagrams (BDDs) are used to represent the state space. The
model checker they used was called NuSMV. Their methodology
took about 30 minutes to explore 108 states. Another work in this
area was done by Garg and Tomlinson [10] wherein a user can
specify an unwanted behavior of a distributed process as a
sequence of relevant events. A computation verifies all this by
checking if a causal path of the computation matches one of the
sequences created above. A similar concept of replaying the
messages from the trace was used by Garg and Tarafdar [5]
wherein the execution of a distributed process was traced and then
a synchronization strategy was developed to prevent this failure in
future that is during the rexecution after a failure, information
from the previous trace was used to prevent this failure from
occurring in future. Chakraborty and Garg [6] used another
approach to prevent the state space explosion. They used the
distributive lattice properties of global state graph to reduce the
number of state spaces. They concluded that using a monitor
process which formed the global state lattice, the number of state
spaces was indeed reduced.
The approach taken by Mittal and Garg [7] used a debugger to
reexecute a traced computation. They use predicate control to
debug a distributed systems program. They developed an
algorithm to maintain predicate by adding synchronizations and
showed that the concept of ‘admissible sequence of events’ helps
transform synchronization problem to finding a path in the graph.
Godefroid and Khurshid [11] used genetic algorithms to guide
state search to error states. The tool they used was verisoft. They
concluded that genetic algorithms did outperform traditional
systematic and random state space searches.
We found that there was no work that had been done in testing
algorithms using model checking by storing the traces and then
replaying it. Our work shows that it is indeed possible to do so.
7. Conclusion
We presented a novel approach for testing distributed programs
using Java PathFinder that addresses the combinatorial explosion
problem by reducing the state space to be explored by the model
checker. We introduced the idea of incremental model checking.
Our approach uses counterexamples for smaller scope (number of
threads) as partial trace to guide subsequent searches on an
increased scope (increased number of threads). This could be
repeated iteratively until the scope of the original program is
reached.
We evaluated our approach on three distributed algorithms—
Dinning Philosophers, Lamport Mutual Exclusion and Robert-
Chang Leader Election. Our results show that this technique leads
to decrease in the total number of states that need to be explored if
the given distributed program has certain properties. Namely, the
behavior of all threads must be deterministic and identical.
Further, the behavior of each thread must not depend on the
number of threads in the system. We plan to explore the
applicability of our approach to other distributed algorithms and
also explore how its effectiveness is affected by different heuristic
search algorithms (such as A*, Iterative Deepening etc).
8. References
[1] GuillaumeBrat, Klaus Havelund, SeungJoon Park and
Willem Visser ‘Java PathFinder, Second Generation of a
Java Model Checker’, Research Institute for Advanced
Computer Science, 2000.
[2] Tatsuhiro Tsuchiya, Shin’ichi Nagano, Rohayu Bt Paidi
and Tohru Kikuno ‘Symbolic Model Checking for Self
Stabilizing Algorithms’, Vol. 12, No.1, IEEE, Jan 2001.
[3] Willem Visser, Corina S. Pasareanu and Sarfraz Khurshid
‘Test Input Generation with Java PathFinder’, ISSTA’04,
July, 2004.
[4] Vijay K. Garg ‘Elements of Distributed Computing’,
Wiley and Sons, IEEE press, 2002.
[5] Ashis Tarafdar and Vijay Garg ‘Software Fault Tolerance
of Concurrent Programs using Controlled Re-execution’,
DISC’99, Slovakia, pp210-224.
[6] Arindam Chakraborty and Vijay Garg ‘On Reducing the
Global State Graph for Verification of Distributed
Computations’ 7th International Workshop on
Microprocessor Test and Verification (MTV'06) Common
 Challenges and Solutions, December 2006, Austin, Texas,
USA.
[7] Neeraj Mittal and Vijay Garg ‘Debugging Distributed
Programs Using Controlled Re-execution’ ACM
Symposium on Principles of Distributed Computing
(PODC'00), Portland, Oregon, July 2000, pp. 239 – 248.
[8] W. Visser, K. Havelund, G. Brat, S. Park and F. Lerda
‘Model Checking Programs’, Automated Software
Engineering Journal.Volume 10, Number 2, April 2003.
[9] Tatsuhiro Tsuchiya and Andre Schiper “Model Checking
of consensus algorithms”, Technical Report, Osaka
University
[10] Eddy Fromentin, Michael Raynal, Vijay Garg and Alex
Tomlinson.’ On The Fly Testing of Regular Patterns in
distributed computations’
[11] Patrice Godefroid and Safraz Khurshid ‘Exploring Very
Large State Spaces using Genetic Algorithms’, TACAS
2002, pp 266-280, 2002.
[12] http://javapathfinder.sourceforge.net. Date Accessed: April
23rd, 2007.
[13] http://en.wikipedia.org/wiki. Date Accessed: April 23rd,
2007.