Debugging backwards

Question

Hello, I have two questions :

1. While doing source level debugging (using any debugger) does any debugger save state of some iteration/for-loop/any code executed and allow the user to go back to that previously executed code/data state at a later point of time during debugging? The need for this is some variable/pointer is corrupted somewhere earlier in time during execution but is accessed after some time / later in the execution of code and thats when it crashes/hangs the code, so i would like to go back and see which function/at what time the variable was corrupted/wrong value computed and written to it ? Is it possible in any debugger (gcc, MSVC6.0 ...)

2. Does any debugger/IDE have provision that when a memory address/variable is marked for "analysis", it should display which function in which file, and which code changed that memory(write), every time it is changed/written?

-AD

Answer 1

I believe the latest version of OCaml has this. This seems like quite a new fad, but IIRC this is on the wishlist of the future version of Visual Studio.

A feature in VS I have not used, can track objects (make object id or something).

Answer 2

I am not aware of any debugger that lets you save state in order to go back to it later. The debugger would have no way of knowing what state was relevant. The closest you could get would be to create a dump file at some point, which would let you inspect the entire program state later.

Visual Studio does support data breakpoints which will break into the debugger whenever a given memory location is written too.

These can be very useful for finding out what is treading on a piece of memory that is being corrupted. There are, however, limitations on the number of data breakpoints you can set, since they are implemented using hardware register support from the processor.

Answer 3

For #2, you may want to read about watchpoints, which are available in gdb, among other debuggers.

Watchpoints are similar to breakpoints. However, watchpoints are not set for functions or lines of code. Watchpoints are set on variables. When those variables are read or written, the watchpoint is triggered and program execution stops.

Answer 4

For the first point, you could try conditional breakpoints. Most debuggers I've used seem to have this feature, though a lot of people don't know about it. You can set the breakpoint to only stop when some condition is satisfied, like your iterator variable is some number, or some other variable is null. For example:

for (i = 0; i < list.size(); i++) {
  foo = list[i];
}

You could set up a conditional breakpoint to stop when i == 17, or when foo == null.

Answer 5

Such debuggers are in the making. You can check out the following Google Talk

Answer 6

For the first issue: ddd/gdb has a backtrace which shows you exactly how it get to that point. Also a coredump might help.

An interesting article about a possible side-effects is this one

Answer 7

It sounds an awful lot like you will want to grab a copy of Visual Studio 2010.

They are implementing almost exactly what you're describing in #1 - there is a screencast about the new "The Historical Debugger" in Visual Studio Team System 2010 on Channel 9.

There's a bit more about it in this entry located here (this one is for the April 2008 CTP of codename 'Rosario')

I've found this definition of the new Historical Debugger from a blog entry by Maor David (here):

"Visual Studio Historical Debugger captures and records what the application does while it is running. When an error occurs, you can quickly find the root cause by investigating the information that was recorded by the Historical Debugger. At any time during debugging, you can go backward and forward in time to determine where an error occurred."

Here's another video walkthrough also!

Edit: I starting evaluating the most (1) recent CTP drop (31/10 - October 08) of Visual Studio 2010 and they seem to have an early version of the historical debugger implemented. It might be worth checking out.

(1) [http://www.microsoft.com/downloads/details.aspx?FamilyId=922B4655-93D0-4476-BDA4-94CF5F8D4814&displaylang=en]

Answer 8

I think you are trying to get to an Omniscient Debugger or Tangible Program Histories (from 1999!!).

Of course these are more research papers/implementations but it does appear that these concepts are finally getting into mainstream compilers.

Answer 9

You may want to look at Replay Debugging from VMware.

From the link:

What we did was integrating Visual Studio plugin for Workstation with Record/Replay technology. You can now develop your application with Visual Studio, and then with a few mouse clicks launch it in a VM in recording mode. You can then replay recording as many times as you want, using all the debugging facilities Visual Studio provides.

But we did not stop at that. We also implemented unique "reverse execution" feature. Say, if you are debugging a memory corruption, you can put watchpoint on corrupted memory and then hit "Reverse Continue" in Visual Studio plugin menu - and we'll navigate the recording right to the place where memory was last written to.

Answer 10

While current debuggers don't save the state, they do let you go back, to some degree. You can use the "move execution point to here" feature (actual name will depend on your debugger, of course) to set the line being executed.

This only really works well for jumping around within a single function, but it can be useful for "trying again" with a different value - you break after a loop, use the debugger to change the variable values, and then jump back to the top of the loop. Alternatively, if you know that a function call is going to fail but you want to see what happens afterwards (for example... something timed out because you were stopped in the debugger, but you want to carry on executing as if it hadn't timed out), you can use the "move execution point to here" feature to skip over that code.

I know it's not what you asked for, but for the moment, it's all we have... I believe such technology will probably be available fairly soon, but for the moment I think it is in the "research" phase.