Looks very nifty. Is this being developed for Windows only?
Time Travel Debugging
11–20 of 52 posts
Re: Time Travel Debugging
#12There 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/
Re: Time Travel Debugging
#13We 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.
Re: Time Travel Debugging
#14Earlier quoted context omitted.
I think it has been in gdb before Swift.
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?
Re: Time Travel Debugging
#15Here is a recent CppCon video: https://www.youtube.com/watch?time_continue=3389&v=l1YJTg_A9...
I'm an escalation engineer at Microsoft, and we have been using this for many, many years to solve complex customer cases. Having it go public is a pretty big deal for us.
Re: Time Travel Debugging
#16Earlier quoted context omitted.
Strange, the impression I got from MS devs on Twitter is that this is something they have been working on for a while that they just finished and premiered at a CPP conference.
The core technology was born out of a group in MS research long ago. Moving from research code to production is highly non-trivial. I first heard how time travel debugging was implemented before i knew about Facebook. I suspect SSDs are part of what made this more practical as it used to simply saturate disk IO, even on specialized systems. With a pci express SSD this becomes much more pragmatic then when the initial…
Yes I believe TTT, or iDNA as it was known, was first released internally around 15 years ago. Or maybe that was just the Nirvana process instrumentation framework it is based on. Either way it's a long time.
A modified version of the tracer is used sometimes to help with support cases, but this is the first public release of the WinDbg replay bit as well.
Re: Time Travel Debugging
#17Reminds me of Qira. http://qira.me/
Re: Time Travel Debugging
#18There 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
There is also PinPlay / DrDebug
https://software.intel.com/en-us/articles/program-recordrepl... https://software.intel.com/en-us/articles/pintool-drdebug
Re: Time Travel Debugging
#19We 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.
Was it an open source project? If not do you know where it lives inside the company (I’m curious about how it works).
Re: Time Travel Debugging
#20I'm the dev lead for WinDbg and the windows debugging platform, and I'm a former dev working on time travel debugging (I wrote the cpu emulation for the project). Happy to answer any questions that anyone has.
Since I'm "posting too fast", let me put my answers here for now:
qod: Right now you can attach TTD to a process after initialization (or any point in time prior to the repro), but you can't trace starting from a breakpoint. We'd love to add that functionality though, so I'm sure you'll see it in a future version of the tool.
Glad you like the new WinDbg! It's been very polarizing (which you can see just reading the comments on this post!), so it's good to hear the positive feedback sometimes :)
We've got a ton of plans to make debugging even faster and more effective in WinDbg, so hopefully we'll win more people over as we make our tools easier to use and more powerful.