Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Time Travel Debugging

docs.microsoft.com

Post reply on HN
Print view View original

21–30 of 52 posts

Re: Time Travel Debugging

#21

Post by timmisiak »

dmitrygr wrote: post #13

We at VMware had this working and released in 2008. We supported windows and Linux. We even supported things like network applications that had lots of outside state. It was called replay debugging and besides Mozilla, few used it. Sadly it was killed when workstation 8.0 came out.

That really was a cool feature of VMware (and I used to work on the vmware hypervisor briefly), although it used very different techniques and was limited to single core record/replay. Microsoft TTD is based on a different technology, and captures traces of individual processes. More useful for usermode folks, less useful for kernel mode folks compared to the vmware technology.

Re: Time Travel Debugging

#22

Post by mncharity »

For more than two decades now, I've been using the limited availability of reversible debugging as an example of just how dysfunctional software engineering is as a field. The shoemaker's family's tattered feet.

Reversible debugging been around for six decades (eg EXDAMS on Multics), been generally practical for two or three, been available in gdb for one, and now, finally, here we are. It's taken two bloody human generations to get this close to widely deploying TTD.

So yay. Maybe I can now retire TTD as an example of glacial progress. There's no shortage of others. Sigh.

Re: Time Travel Debugging

#23

Post by zokier »

jasonwelk wrote: post #14
userbinator wrote: post #5

Earlier quoted context omitted.

Yes: https://www.gnu.org/s/gdb/news/reversible.html This has approximately nothing to do with C++ or even "language communities".

I can't speak for Microsoft itself, but wouldn't the effort to implement a production-ready time-traveling debugging system (as explained here by SteveJS) be at least somewhat influenced by the growing popularity of time-travel debugging in other languages?

What other languages got timetravel first? The biggest I've heard is rr from 2014, which is for native code or basically C/C++.

Re: Time Travel Debugging

#24

Post by timmisiak »

userbinator wrote: post #4

TTD is efficient and works to add as little as possible overhead as it captures code execution in trace files. ...and then in the table below the screenshot... Large overhead at record time. May collect more data that is needed. Data files can become large. Based on past experiences with debugging using tracepoints etc., I'm more inclined to believe the latter. Also, as a side-note, the "more modern visuals" of "WinD…

The overhead varies depending on how cpu/IO bound the application is. IO isn't really affected, so IO bound applications tend to not see a big slowdown. In theory, you could see a very large slowdown in the worst case, but in the average case for a "medium sized" process the slowdown would be noticeable but not affect the usability. This technology isn't based on tracepoints, it's based on in-process cpu emulation. The emulation overhead is on the order of 10-20x in many cases, whereas tracepoint overhead would be on the order of 1000x I believe (maybe worse).

If there is something specific you dislike about the visuals of WinDbg Preview, let us know through the feedback hub or emailing windbgfb@microsoft.com. We realize that folks that have been using WinDbg for 20 years are likely to not be interested in a new UI, but we face 20 years of legacy code every time we want to add a new feature to the UI. As an example, the new WinDbg UI has a javascript window for writing scripts that extend and automate the debugger. It took us approximately 8x less time to implement in WinDbg Preview than what we estimated it would cost in the legacy UI (and a much more junior dev was able to do it as well). We want to innovate without disrupting folks that have effective workflows in WinDbg, so we really want to hear feedback on the new UI. If there are specific things that we can change to make you more efficient in the new UI, please let us know.

Re: Time Travel Debugging

#25

Post by csours »

mncharity wrote: post #22

For more than two decades now, I've been using the limited availability of reversible debugging as an example of just how dysfunctional software engineering is as a field. The shoemaker's family's tattered feet. Reversible debugging been around for six decades (eg EXDAMS on Multics), been generally practical for two or three, been available in gdb for one, and now, finally, here we are. It's taken two bloody human ge…

I'm curious to hear some. Are you thinking of stuff like Plan 9 files/services?

Re: Time Travel Debugging

#26

Post by [deleted] »

userbinator wrote: post #4

TTD is efficient and works to add as little as possible overhead as it captures code execution in trace files. ...and then in the table below the screenshot... Large overhead at record time. May collect more data that is needed. Data files can become large. Based on past experiences with debugging using tracepoints etc., I'm more inclined to believe the latter. Also, as a side-note, the "more modern visuals" of "WinD…

[deleted]

Re: Time Travel Debugging

#28

Post by timmisiak »

kuwze wrote: post #12

There is also undodb[0] and gdb supports reversing[1]. There is also the rr[2] project from Mozilla. All of those support Linux. I also recently discovered WDD[3] (which is for Windows) as well. [0]: https://undo.io/ [1]: https://www.gnu.org/software/gdb/news/reversible.html [2]: http://rr-project.org/ [3]: https://github.com/ipkn/wdd

I believe all of those projects are based on single-core debugging. Restricting the trace to a single core is one way of introducing determinism in the process as a way of allowing replay later. Microsoft time travel debugging is a multi-core technology, which allows you to capture interactions between threads in multi-threaded processes.

Edit: Since I'm still "posting too fast", let me respond here to clarify. Both rr and undodbg support multiple threads, but do not record them simultaneously. They restrict execution to a single core. That's what I mean by recording interactions between threads. For instance, if you have shared memory between processes, that won't work with rr/undodb generally (although I know at least rr can work around this by recording both processes).

I'm not saying one is intrinsically better than the other since there are tradeoffs with both approaches. There is a high constant overhead for recording all cores, but it does have the advantage of scaling well to large numbers of cores.

Re: Time Travel Debugging

#30

Post by jasonwelk »

zokier wrote: post #23
jasonwelk wrote: post #14

Earlier quoted context omitted.

I can't speak for Microsoft itself, but wouldn't the effort to implement a production-ready time-traveling debugging system (as explained here by SteveJS) be at least somewhat influenced by the growing popularity of time-travel debugging in other languages?

What other languages got timetravel first? The biggest I've heard is rr from 2014, which is for native code or basically C/C++.

One language that has popularized it in very recent years is Elm. It's mentioned everywhere.
Post reply on HN