How do Time Travel Debuggers Work? - Design and Implementation of a Time Travel Debugger - Greg Law

[@lightlegion_]

You’re producing some amazing work!

[@greglaw9145]

thank you! 😍

[@phovos]

Very interesting presentation, thanks!

[@greglaw9145]

thank you! I had a lot of fun giving it

[@JohnDlugosz]

Years ago, in the early or mid '00's, I eagerly upgraded VMWare because of a new feature: recording/replay. You know the step-over should have been step-into deal, especially when trying to find the location initially -- I realized that the VM recording feature would abolish that. Furthermore, if the debugger attached to the process is _also in that VM being recorded_ , then it works seemlessly. At its most basic, the issue of starting over repeatedly to figure out the step-over vs step-into pattern to get to your bug is no longer a problem; one can just revert after the step-over that passed the bug. Why did it take 15 years for that to become mainstream, integrated into the debugger itself?

[@greglaw9145]

You ask a good question! TBF we at Undo have been doing this for many years, it's just that until recently not many knew about it. (Customers and budget for marketing chicken and egg problem which thankfully is now solving itself, albeit slowly!). My take is that VMware discovered what we also discovered the hard way: to some of us this is just so obviously useful everyone will want it, right? In reality it turns out to be _really_ hard to persuade 99% of programmers that they should try it!

[@pollathajeeva23]

In the Distributed systems world we have a very niche space for time travel debugging considering Raft consensus can't make it for DST because of the non-deterministic leader election of nodes in the cluster. How can we resolve it with TTD?

[@greglaw9145]

Beautifully! :) You can record all (or a subset) of processes in the network, and then stitch together all the recordings using something we call Multi-Process Correlation. e.g. you're at a recvmsg() and you want to know where it came from? Simply reverse step through to the corresponding sendmsg() call in another process. If you'll excuse the hubris, it's super cool! :)

[@valshaped]

One gripe: "gen" in the "Gen AI" buzzword doesn't stand for general, it stands for *generative.* It's intentionally misleading, to make people think it's more capable than it is. Grift, all the way down.

[@greglaw9145]

TBH I don't remember where in the talk this was discussed, but I was aware, promise! If I implied anything else then I, as they say, "misspoke"!

[@GeorgeTsiros]

I disagree with the "debugging is harder than programming". I can accept the similar but _different_ : the effort and time spent debugging a program is inversely proportional to the effort and time spent designing and implementing the program

[@greglaw9145]

You make an interesting point! But perhaps a little theoretical -- the reality is that most programmers deal with a codebase that they themselves wrote a tiny proportion of. I also claim that for most of us at least, no matter how much care is taken when designing and writing the program, there is still an awful lot of debugging to be done.

[@douggale5962]

Reverse debugging doesn't work, at all. What magical distro has a build where it works? Some bleeding edge daily build distro? No thanks. If you are wondering why nobody uses it, it is because it doesn't work. The authors always think their stuff works, unfortunately. Maybe it does, in the daily. Distros are making it look bad.

[@destiny_02]

spotted the debian user

[@greglaw9145]

You may be right that what is provided in most distros doesn't work "out of the box". You're totally wrong to claim that it doesn't work though. Thousands of engineers are using Undo routinely to debug some of the biggest and most complex code bases in the world. And that's just Undo, I know people are similarly using rr, and Microsoft's TTD is used a lot by Microsoft themselves as well as their customers. I mean, it must work to some degree otherwise Undo wouldn't have a business, right? :)