Live data from Hacker News

Thoughts on Microsoft's Time-Travel Debugger

robert.ocallahan.org

61–70 of 77 posts

Re: Thoughts on Microsoft's Time-Travel Debugger

#61

Earlier quoted context omitted.

Thanks for sharing that. Interesting what constitutes a military breakthrough these days. A real nation-state with a military-industrial complex would just shoot that thing down.

It's might become harder than you think. Especially modern stuff. I've been talking with a lot of hobbyist drone owners lately and several folks are working on fascinating projects using a fleet of semi-autonomous lightweight fixed wing and quad drones along with modern autonomous aircraft techniques. These things are small (you could hold them one handed on a crowded bus), fast (even the quads break 140mph), can be…

I'm surprised we don't see a lot more of this, but I assume it 10 years it will be extremely pervasive.

Drones which can zoom into an area at 100 mph plus and establish a complete surveillance perimeter. They could dock on telephone poles throughout a city. I imagine "calling 911" could dispatch these monitors to your location in under 60 seconds on average.

Drones were a lot more prominent in the recent hurricane response, I think it's the tip of the iceberg.

Re: Thoughts on Microsoft's Time-Travel Debugger

#62
post #52

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?

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?

Re: Thoughts on Microsoft's Time-Travel Debugger

#63
post #34

Tools like this have always been how Microsoft segments the highest-price "Ultimate" version of Visual Studio (or whatever MS marketing has renamed things this month). As best I can tell there is no mention in this article of how this feature will be priced, which winds up limiting how often it will be useful simply because of availability. Let me know when this shows up in the free SKUs ("Express") or perhaps even t…

> even the drug-pusher-like "Community" (first hit is free, unless/until you're making money) edition. I mean, yeah it's not free-for-all, but "first hit is free" is kind of unfair. A company is not allowed to use it if they have more than "(a) more than 250 PCs or users or (b) one million U.S. dollars... in annual revenues" [1], and if it doesn't meet that criteria, it's usage is limited to 5 concurrent instances. M…

In case there's any confusion whether or not I agree with you, here's the very next thing I wrote:

> It is perfectly reasonable​ on their part as a company selling dev tools to do this

The Community edition licensing terms are, at best, awkward. I personally would have the hardest time with the 250 user limit - can I publish a free mobile app without fear this restriction might kick in?

It is not as blatant as the BizSpark / Imagine (DreamSpark) programs, so I guess that's a plus. The end result looks close enough to be considered the same to me.

Re: Thoughts on Microsoft's Time-Travel Debugger

#64
post #43
post #34

Tools like this have always been how Microsoft segments the highest-price "Ultimate" version of Visual Studio (or whatever MS marketing has renamed things this month). As best I can tell there is no mention in this article of how this feature will be priced, which winds up limiting how often it will be useful simply because of availability. Let me know when this shows up in the free SKUs ("Express") or perhaps even t…

>Also, let me know if this ever comes to managed code. For managed code, VS2010 (Ultimate) introduced Intellitrace for C# .NET code. It let you step "backwards" which is a form of "time travel". Since 2010, people have wondered if Microsoft was going to introduce a similar debugging capability for C++. It looks like they did -- but instead of reusing the previous "Intellitrace" brand and calling it "Intellitrace for…

Intellitrace and TTD take different approaches and have very different trade offs. Intellitrace allows imposing logging on a system posthoc. TTD records everything the system does. They are not merely labeled differently they are different in kind. The consequences of those trade offs make the pragmatic use cases very different. Intellitrace was always intended to head toward logging in production systems, which i believe it has achieved now. It’s unlikely you would TTD a server in production without a very good reason. It is possible for a Intellitrace log to not have enough information to debug a problem. A TTD trace has fundamentally captured everything, its bigger, a bit more unwieldy... but in a deeper sense it is complete.

Re: Thoughts on Microsoft's Time-Travel Debugger

#65
post #62

Earlier quoted context omitted.

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.

Re: Thoughts on Microsoft's Time-Travel Debugger

#66
post #39

The idea of traveling forward and back in time in a debugger has been around for a long time, even before the era of modern programming the idea was explored and implemented. I recall conversations with people working on this in the 1970's, but I never saw one working in action. I've never had much use for debuggers. Of course I've had bugs that could have been found faster with debuggers, but I usually find myself u…

The idea has been around a long time. Making it practical has been a much more recent development. Ideas are cheap.

If you're using logs, you're using a debugger, just a very limited one.

Reasoning about a program statically is great, but once it gets above a certain size you can't keep it all in your head and you must collect data to narrow down the problem. That's where a debugger comes in. Then there are the cases where you're debugging someone else's code and you don't have it in your head in the first place.

Re: Thoughts on Microsoft's Time-Travel Debugger

#67
post #66
post #39

The idea of traveling forward and back in time in a debugger has been around for a long time, even before the era of modern programming the idea was explored and implemented. I recall conversations with people working on this in the 1970's, but I never saw one working in action. I've never had much use for debuggers. Of course I've had bugs that could have been found faster with debuggers, but I usually find myself u…

The idea has been around a long time. Making it practical has been a much more recent development. Ideas are cheap. If you're using logs, you're using a debugger, just a very limited one. Reasoning about a program statically is great, but once it gets above a certain size you can't keep it all in your head and you must collect data to narrow down the problem. That's where a debugger comes in. Then there are the cases…

Oh yeah, and then there are the times when you reason about the program in your head and your reasoning is wrong. That happens a lot. Sometimes it's because of false but reasonable assumptions like "the compiler compiled my code correctly" or "the CPU executed my program correctly".

Re: Thoughts on Microsoft's Time-Travel Debugger

#68
post #65
post #62

Earlier quoted context omitted.

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?

Re: Thoughts on Microsoft's Time-Travel Debugger

#69

Awesome, I hadn't heard of TTD. It's great to see reverse-debugging get serious attention rr sounds fantastic... unfortunately, I can't use it because AMD CPUs aren't supported (they simply don't have adequate performance counters; it's not rr's fault). With the exception of Ryzen, but even there, the performance counters apparently aren't entirely reliable (meaning sometimes the debugger will go haywire)

FYI, Microsoft TTD is supported on AMD CPUs.

Re: Thoughts on Microsoft's Time-Travel Debugger

#70
post #34

Tools like this have always been how Microsoft segments the highest-price "Ultimate" version of Visual Studio (or whatever MS marketing has renamed things this month). As best I can tell there is no mention in this article of how this feature will be priced, which winds up limiting how often it will be useful simply because of availability. Let me know when this shows up in the free SKUs ("Express") or perhaps even t…

[deleted]
Post reply on HN