Hacker News Reader

Comment by bcherny | Hacker News Reader

Could someone help explain how this is different from a regular debugger that lets you step back in the call stack? Does Chrome dev tools debugger (that lets you step back in the call stack, even for asynchronous calls) come close to TTD?

View on HN

when you hit a break point in Chrome, you are suspending a live thread with current memory and stack state. This tool is more like a profiler, that instead of studying a current snapshot of the state, it will show you how the state changed over time. (also, this is for native apps)

I see. So for example, with a regular debugger you can see what the value of a function's argument was at a point in the current call stack; with TTD you can see what that argument was in previous call stacks too, and jump to those other call stacks?

TDD allows you to recreate a full memory snapshot at an arbitrary point during the recorded execution. A regular debugger cannot tell you what was in a register or memory location previous to what is currently there now. TTD does allow that.

So:

- Without TTD, I can inspect values in the call stack where I set a breakpoint

- With TTD, I can inspect values in my whole program, and can jump back/forward in time to see how those values changed

Is that right?

Yup, you got it. Not just jumping back and forward, but seeking to points in time when memory changed. For instance... have some memory that got corrupted? With normal debugging you're probably out of luck unless you get some hints as to where it got corrupted. With TTD, you just set a memory access breakpoint and "run in reverse" until the memory is modified. It pinpoints the exact point in time where the memory got corrupted.

Reply on news.ycombinator.com