Using Sneaky Programmable State Based Debugger

After setting a consistent global breakpoint using Ariadne, we reexecute the program under a deterministic replay system, halt the computation at the breakpoint and examine the state space of the processes. In pC++, we use the Sneaky programmable state based debugger which acts as a debugging client of the Sneezy program control infrastructure. Sneezy provides the debugging API which Sneaky (a light weight client) uses to examine the state space. Sneaky itself is a programmable debugger and uses Scheme to build higher levels of debugging abstractions from primitive ones. To illustrate how its use, we get back to the binary image compression example.

To run Sneaky, we use three xterm windows, in the first we run the program

geos [~/ts/newbic]% snzrpl-mpi -SNZCNT 8

In the second we run the sneaky debugger:

geos [~/ts/newbic]% ls -l .stkrc
-rw-rw-rw-    1 sameer   grads       1267 Jun 24 10:22 .stkrc
geos [~/ts/newbic]% stk
Welcome to the STk interpreter version 2.1.7 [IRIX64-6.1-IP21]
Copyright (C) 1993,1994,1995 Erick Gallesio - I3S - CNRS / ESSI 
STk> (load "sneaky.sch")
Loading Tk and callback
Loading threads and synchronization
Loading Sneezy Client API
Loading Sneaky:  inspect collection ct-tbl sneaky-basic cmd-display commands sneaky-utils state-display stepping tau-interface done.

Type (sneaky [host-name] [port-number]) to start debugging.
#[undefined]
STk> (sneaky "localhost" 5666)

Note: The file .stkrc should be present in the directory in which stk is run. If its not present in the application directory one can link it to the file in the SAGEROOT/TAU/sneaky directory. In the third window we can (optionally run) tau tools

geos [~/ts/newbic]% tau &

We get sneaky control panel where we click on "User Event" and hit "Continue all". The program continues till it reaches the consistent global breakpoint. After the breakpoint is reached, we can examine the state of the collection. Help is available in the sneaky shell and the figure below shows how the elements in the collection are examined.

Looking at the second element of the collection, we saw an inconsistency: myColor was set at 1 indicating that this node represents a single, compressed, black tree but myStatus was set to 2 indicating that the merge had failed. Since it is the color of the node that determines its candidacy for merging at the next level, the color should have been set to a third value indicating ``black and white, no merge.'' This failure to set myColor after an unsuccessful merge attempt was the error we were looking for.

Sameer Shende <sameer@cs.uoregon.edu>