Debugging

 

There is a stub application called Stublet that you can use to test and debug the Drone installation on your system. See the documentation in the examples/stublet directory for details.

Drone has several debugging parameters that you can set. First, you can set stackTrace to 1. This causes Tcl to print out a full stack trace if an error occurs. Otherwise, only the error message is printed. This option is useful to figure out exactly where in the Drone script an error occurred.

Next, you can set outputLog to 1. This causes everything that would normally be printed to stdout or stderr to also be stored in a log file. This happens whether or not Drone is running in the background. Note that the log file may become very large. It is also helpful to simply set the parameter background to 0 and watch the script run -- this gives you the same information. Neither of these will give you much information if you are running the experiment on a single computer.

Running Drone in dry-run mode using

drone -d controlFile

is a good way to see what the target program is expected to accept on the command line and in the input file, without actually running the target program. The case log files contain the actual commands that would have been used to invoke the target program, and the input file, if any, is the one that would have been used in an actual experiment.

Finally, you can set debugInternal to 1. This causes Expect to print information on certain internal operations, especially pattern matching. This is especially useful if you are trying to find out why Expect is timing out during an expect command, but a lot of extraneous output is produced. Again, this won't be useful when running the experiment on a single computer.

If all else fails, you can use the Tcl debugger or the Expect commands interpreter and interact. The use of these is beyond the scope of this User's Guide; see Exploring Expect [4].

If you look at the output of an experiment running on remote hosts, you will likely see many lines consisting of output from the Unix file command, saying something like

path: cannot open

This is not necessarily a problem; this is Drone's way of finding out whether a file or directory exists or not. Also, due to the way Expect operates, the prompt of the line on which a command appears may give misleading information about which host the command was executed on. In general, the first command executed after switching between telnet processes will appear on a line with a prompt from the previous host.