A .dbx file is a shell script that can be used to start an individual debugging session
for each stateless program. The .ini and .dbx files must exist in the same directory as
the binary to be debugged. And, the binary should be compiled with a -g option.
The .end file is a shell script that removes all object agents and all auxilary files.
Thus, except for the .dbx and .end files, all other intermediate files are transparent to
the user.
Debugging Procedure
Debugging stateless programs is essentially a series of dependent/independent test
pairs as specified in an application configuration (CSL). Each passive object is the basis
for a test pair if the accessing programs use blocking operations. Note
that except for real-time applications, the use of non-blocking operations is strongly
discouraged for they are hard to program, debug and maintain.
The starting point is any independent program module and its immediate dependent
module(s) via either a tuple space or pipe object.
For each module X, we enter the debugger using X.dbx. This shell script establishes the
connection between X and its IPC patterns. X.dbx can be customized to use commercial or
experimental debuggers.
We need to block the dependent modules on their respective object operations. This can
be done via local debugger commands on a different window or simply submitting the program
in the background (by removing the use of debugger in the .dbx file).
We can then inspect, manually, each independent program's logic by stepping through its
instructions until immediately before the first object operation (excluding the open
statements).
The release of data item(s) from the independent program should un-block the dependent
programs (we should see messages on the screen). Otherwise, we have a communication
problem which may be related to both independent and dependent program modules. A common
problem is the wrong tuple names for tuple space objects or inconsistent message lengths
for both tuple space and pipe objects.
A successful transmission leads to the next test pair. The next independent module
should be under the debugger's control. This procedure may be repeated until all object
interfaces are tested.
The above procedure only reveals problems related to communication and basic
synchronization operations. An integration test can catch synchronization problems
involving multiple parallel programs. The integration test should be performed on an
incremental basis starting from a two processor configuration.
Note that since the POFP programs are stateless, debugging can be carried out on any
single processor or any set of multiple computers.
