Live data from Hacker News

Time Travel Debugging

docs.microsoft.com

31–40 of 52 posts

Re: Time Travel Debugging

#31

I'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…

First I would just like to say how impressed I am with the new WinDbg and TTD, this is fantastic work and a huge improvement on the existing debugging tools.

My question is: if I want to start taking a TTD trace after hitting a particular breakpoint in WinDbg, can this be done with the current tooling? Use case would be if there is a large amount of initialization code that doesn't need to be traced because the bug or crash is known to occur at a later stage in the program.

Re: Time Travel Debugging

#32
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 does support multithreading[0].

"rr doesn't record shared-memory multithreading, so it forces your application's threads to execute serially. Your application can see an additional slowdown if it takes advantage of multicore parallelism."

[0]: https://github.com/mozilla/rr/wiki/Usage#recording-an-execut...

Re: Time Travel Debugging

#33

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. T…

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.

You can rewrite the UI code so it's easier for you to work on internally, but to the user it looks and acts like it was before --- but proceed cautiously[1]. I'm not against adding features and TTD sounds extremely useful, but having in the overview page some slight contradictions and a screenshot of a dumbed-down UI with obvious WTFs like the two duplicate lines really soured the first impression for me. (Looking at it again, I now see the path in the titlebar has been cut off, despite plenty of empty space after it...)

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: Time Travel Debugging

#34

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.

"Sadly it was killed when workstation 8.0 came out."

What ever happened to the intellctual property for that? Any chance it could be open sourced?

Re: Time Travel Debugging

#35
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…

UndoDB supports threading [0]:

"Handles concurrency

Record and replay multi-threaded programs, and those that use shared memory and asynchronous I/O."

[0] - https://undo.io/technology/features/

Re: Time Travel Debugging

#37
Oh my god they redesigned WinDbg with a Microsoft Office UI lookalike starter kit including ribbons. And at least one of the screenshots showed JavaScript.

So many fingers crossed hoping they don't ruin this indispensable basic tool. Every platform needs to have a no-nonsense debugger that doesn't fall over immediately when it has no symbols and source. WinDbg (was?) that.

Re: Time Travel Debugging

#39
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…

Yes, there is definitely a significant tradeoff here. If you're recording something like Exchange Server having true multi-core execution is a big deal. If you're recording a web browser it's not as important, because most things are still gated on the UI thread. Hopefully y'all can get the constant factor overhead for recording down further over time.

With rr and Firefox we found that with sufficiently pathological scheduling we can eventually tease out many races and other bad thread interactions. This became rr's "chaos mode". I think the biggest drawback of not having true multi-core support in rr today is simply the performance hit that a parallel program will take during recording.

Re: Time Travel Debugging

#40

Oh my god they redesigned WinDbg with a Microsoft Office UI lookalike starter kit including ribbons. And at least one of the screenshots showed JavaScript. So many fingers crossed hoping they don't ruin this indispensable basic tool. Every platform needs to have a no-nonsense debugger that doesn't fall over immediately when it has no symbols and source. WinDbg (was?) that.

The underlying engine is the same, so all of the functionality is fundamentally the same.
Post reply on HN