The only difference between a process running on its own, and the process running under maze is the way in which it is scheduled relative to other processes and threads within the same application.
In the former case the schedule is affected by the number, as well as states and priorities of all processes currently running on the machine. This schedule cannot be controlled by a user, is not recordable, and is not possible to reproduce.
When the process is controlled by maze, however, the schedule is not affected by any processes unrelated to the application. The schedule is deterministic, and it can be reproduced on request. If the process creates a child process or a thread, maze automatically takes control over the new process as well. All processes and threads of the application run, wait, or sleep by following directives from maze.
Maze can run an application multiple times, each time generating a unique thread/process scheduling scenario. This allows users to stress-test the application, and catch hard-to-reproduce race-conditions, deadlocks, and segmentation faults as long as enough schedule permutations have been tested. This mode of operation is called “TEST mode”.
Another mode of operation is called “RECONSTRUCTION mode”. In this mode maze runs the application once, reproducing the scheduling scenario of any single run from the TEST mode session.
$ maze -r 1000 foo
starts the TEST mode session, running a program called foo repeatedly 1000 times. The subsequent command
$ maze -R 791
starts maze in the RECONSTRUCTION mode. Maze runs foo once, using the same thread scheduling scheme as it used during run #791 in the last TEST mode session, thus reproducing the program behavior, output and computation results obtained during this run.
Maze is easy to use. It requires no instrumentation of the binary. There are no source code requirements for the application, the binary may be optimized, and the debugging information in the binary is optional .