Although they don’t enjoy the celebrity of compilers, debuggers are one of the most critical tools that affect programmer productivity. There’s a good deal of anecdotal evidence that debugging code, not writing it, is the most time-consuming phase of software development. In “The Elements of Programming Style,” Brian Kernighan wrote: “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?” And unlike code development, there is no formal methodology to debugging — it’s essentially a trial and error activity. Developers run blindly through the program, setting breakpoints and watching for bad things to happen.

The problem, as Kernighan and Rob Pike describe in “The Practice of Programming,” is that “[d]ebugging involves backwards reasoning, like solving murder mysteries. Something impossible occurred, and the only solid information is that it really did occur. So we must think backwards from the result to discover the reasons.”

TotalView Technologies’ ReplayEngine is aimed squarely at this cognitive challenge. It allows the developer to execute the application in reverse. So instead of trying to sneak up on the bad behavior, it allows the program to fail, at which point the developer can take control and start backing up through the execution, examining the program state to see where the code went wrong.

“We’re very happy to be bring this to market,” said TotalView Technologies President and CEO Rich Collier. “We believe it’s going to be breakthrough technology not only in terms of how to do debugging, but also possibly how you go about doing development.”

They currently have a number of beta customers for ReplayEngine and, according to Collier, it’s already showing its worth in the field. The early users have reported finding a lot of bugs in a very short period of time. The common theme is that ReplayEngine eliminates the most repetitive parts of debugging — restarting the application, examining the breakpoints, waiting for the error to occur, and then setting new breakpoints and repeating the process.

“This is particularly useful in scalable, multicore environments in which errors can be hard to track down or reproduce,” said Addison Snell, vice president and general manager of Tabor Research. “TotalView is helping to enable more people to effectively develop scalable applications. Our research shows this is a prime area of concern for the industry.”

One of the most difficult scenarios for debugging is a program crash, where the developer is left with an incoherent program state. Since the crash has stomped on memory, the stack trace is destroyed or at least can’t be trusted. In this case, ReplayEngine can be used to reverse the crash and help the developer figure out what led up to it. A replay can also be used to track down race conditions, bad pointers, array bounds overwrites, memory leaks, and non-robust I/O handling.

The way ReplayEngine works is by recording program context at critical points during execution. The libraries are instrumented to capture all function and system calls, recording the program state at each point. When the user chooses to back up to a specific location in the code, the recorded execution is rerun in a simulated replay environment, starting at the closest point to where the user wants to return, and executing forward to that instruction. At that point, the user can continue to back up or go forward again.

Since ReplayEngine controls I/O, it is able to rerun these external events as they originally occurred. For example, when the program makes a read() call during program execution, the input actually happens and ReplayEngine captures the data. During replay mode, the program may be asked to run through that execution again one or more times. In those cases, the read() call will be intercepted by ReplayEngine and the recorded input data will be used. This ensures deterministic behavior during backward debugging.

ReplayEngine buttons allow you step backward over or into functions. You can also back up out of the current function to the point before the call. Another button lets you move back to a specified source line. The normal breakpoints, watchpoints, and some conditional breakpoints can be used when running forward in replay mode. A live button allows you to jump back into normal debugging mode.

The initial ReplayEngine add-on works on standard Linux distributions on x86 (32-bit and 64-bit) targets, so if you’re looking for BlueGene or Itanium support, you’re out of luck. MPI is supported, specifically MPICH 2.0. According to Collier, at this point the engine can handle an application spread across tens of MPI processes, so if your software is using thousands of compute nodes, the application will have to be scaled down to use the replay feature. Future versions may support larger jobs and expand target coverage, but the initial version is aimed at the heart of TotalView’s market.

But backing up through an MPI application of any size is quite an achievement. Since each MPI process is recorded by ReplayEngine, the developer is able to examine the execution history of each one. For example, a crash on process 20 due to an invalid numeric value (say a divide-by-zero operation) might be traced to a variable that got its value from an incoming message via process 8. The developer could then switch the debug focus to process 8, running on a completely different node. The developer could then locate the point in the execution history where that message was sent. Then the developer could work their way backwards in the execution history of this new process to discover how the invalid data came to be.

The ReplayEngine add-on starts at $1,295 for a single token. Buying in quantity reduces the price significantly: $545/token for 10 tokens and $150/token for 100. There’s also TotalView’s 75 percent off discount for educational use, an area where the company expects a lot of interest. “It is ideally suited for a variety of instructional purposes in the classroom,” said Paul Gray, Supercomputing Conference Education Program Chair in a prepared statement for the press release. “From a software engineering perspective, being able to record and replay program execution will go a long way in improving the effectiveness and efficiency of the troubleshooting phase of software development, which is a crucial component of high-performance computing education.”

There are a handful of other efforts out there aimed at replay debugging, including an open source version of gdb, currently under development. A debugger called UNDOdb, which is written on top of gdb, is available today, but only supports 32-bit x86 and in not thread-aware, much less MPI-aware. Some replay engines are available for Java, but that’s outside of TotalView’s purview. To date, the difficulty of implementing general-purpose replay debugging has prevented most tool makers from bringing this technology to market. “It took a debugger company to come up with something like this,” said Collier. “We live it and breathe it every day.”

But it was no snap for the TotalView engineers either. Not only did they have to implement the session record and simulation replay features, but it all had to be integrated seamlessly into their live debugger foundation. TotalView has been working on the new technology for at least a few years, demonstrating a prototype at SC07 in Reno last November. Collier admitted some engineers expressed doubts it could even be done. He said it actually helped that they were able to use some of the initial versions of ReplayEngine to debug the technology itself.

“It took baseball 108 years to come up with the replay,” he laughed, “so I guess we’re not so bad.”