Record Replay, the technology that allows you to reproduce what’s going on in a virtual machine with machine-level instructions, has been shown off at VMworlds past, but is just now coming into its own. You could experiment with it a bit in Workstation 6.0, but it is now available in a useful way in VMware Workstation 6.5, (in beta but has a new Release Candidate). Let’s let E Lewis introduce it in his new blog. Link: Better Software Development with Replay Debugging: VMware Workstation 6.5: Reverse and Replay Debugging is Here!.
I’m
proud to announce that VMware Workstation 6.5 includes new experimental
features that provide replay debugging for C/C++ developers using
Microsoft Visual Studio. Replay debugging allows developers to debug
recordings of programs running in virtual machines, and it is valuable
for finding, diagnosing, and fixing bugs that are not easily
reproduced, a particularly challenging class of bugs. Once the
manifestation of a bug has been recorded, it can be replayed (and
debugged) over and over again, and it is guaranteed to have
instruction-by-instruction identical behavior each time. In addition,
Workstation includes a feature that simulates reverse execution of the
program, making it easier to pin point the origin of a bug.
Aside from being insanely cool and perhaps the end of the heisenbug, I think this shows how VMware’s 10 years of experience manifests itself in innovation. Virtualization is about more than server consolidation, and once you are virtualized, the really interesting things can start to happen.
Here’s E demonstrating how this works. I think the UI has changed a bit since we filmed this. We’re running Visual Studio on the host, outside the VM, and attaching to a process inside the VM and putting in triggers and whatnot in the debugger as it replays until we track down the bug we’re looking for. If we go too far, we can always hit rewind.
Oh, and there’s a Lenovo laptop to be won: VMware Record and Replay Challenge
Wow. For years I’ve thought the people that invent this functionality will be heroes in the software development world.
This is the path toward not ever reproducing bugs. With the right logging, synchronized time across all systems, and aggregated Replay views of all systems this could usher in a revolution.
I was a Director of Quality Assurance for over 7 years. The software test/fix cycle is by far the most inefficient aspect of software development. It is painful, repetitive, contentious, and extremely time consuming. The fantasy functionality is a system that aggregates everything that is happening on all servers and workstations. Then warnings and errors reported in logs can be more easily investigated. Errors that propagate to the user interface could prompt the user for a comment about what they were trying to do and the severity of the error. All errors would have a unique identifier so the person who encountered the error would not need to enter a bug.
A fantasy for now but you are brining this a leap further within reach.
Thanks
Just for people (like me) that doesn’t know the meaning of an heisenbug, here a list of bugs classifications:
heisenbug:
[from Heisenberg’s Uncertainty Principle in quantum physics] A bug that disappears or alters its behavior when one attempts to probe or isolate it. (This usage is not even particularly fanciful; the use of a debugger sometimes alters a program’s operating environment significantly enough that buggy code, such as that which relies on the values of uninitialized memory, behaves quite differently.) Antonym of Bohr bug; see also mandelbug, schroedinbug. In C, nine out of ten heisenbugs result from uninitialized auto variables, fandango on core phenomena (esp. lossage related to corruption of the malloc arena) or errors that smash the stack.
Bohrbug:
[from quantum physics] A repeatable bug; one that manifests reliably under a possibly unknown but well-defined set of conditions. Antonym of heisenbug; see also mandelbug, schroedinbug.
Mandelbug:
[from the Mandelbrot set] A bug whose underlying causes are so complex and obscure as to make its behavior appear chaotic or even non-deterministic. This term implies that the speaker thinks it is a Bohr bug, rather than a heisenbug. See also schroedinbug.
schroedinbug:
[MIT: from the Schroedinger’s Cat thought-experiment in quantum physics] A design or implementation bug in a program that doesn’t manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed. Though (like bit rot) this sounds impossible, it happens; some programs have harbored latent schroedinbugs for years. Compare heisenbug, Bohr bug, mandelbug.