How does a historical debugger work?

Question

A historical debugger, or Historical Debugger, is able to collect key data from a debugging session, such as locals/autos (in the case of Intellitrace), exceptions and events of the session.

I imagine something like this is very complex, like debugging backwards. Correct me if I’m wrong.

How a history debugger works?

Answer 1

I do not know deeply but I know in general.

We have behaviors and states. That is, algorithms and data structures. Behaviors are inherent to the application and do not change. States exist during execution, and therefore they change.

What the history debugger needs to do is take a photo (snapshot) of the state whenever it changes. With the record of all state changes you can go back and forth.

Think about projector of slides (if you don’t know what this is, think about Powerpoint). The slides are these states, you can see the next one or you can go back to the previous ones. Obviously the next one may depend on a one-step execution of the algorithm to cause state changes, just as it already works in the Debugger normal.

Having all records just restore to the point you want. You can even give a replay of all.

So it doesn’t even seem that complicated. Although it’s also not as simple as describing it here.

Complicates it a little more with a state external to the memory. You cannot simply access the external state again, nothing will guarantee that the result will be the same. In fact you have a good chance of not being. Then you need to record these states as well. To restore them complicates why the code will attempt to access the external resource, only that if you "went back in history" you have to inject the recorded data in place of the actual request.

It can become impractical to record every state change. So this occurs selectively. Not every state and not every change is recorded.

You can even take the file generated by it on a machine and do the replay on another machine.

He helps, but he doesn’t perform miracles.