Earlier quoted context omitted.
There's languages that support time travel debugging, like RR for GDB, or smalltalk, but no open source system wide thing like Antithesis that I know of yet.
rr can record process trees; i.e. basically any part/descendant of a process you spawn will be recorded and can be replayed (userspace CPU & memory, that is); won't record the entire OS though.
Debugging in the Multiverse
31–40 of 62 posts
Re: Debugging in the Multiverse
#32Earlier quoted context omitted.
rr can record process trees; i.e. basically any part/descendant of a process you spawn will be recorded and can be replayed (userspace CPU & memory, that is); won't record the entire OS though.
My experience with RR is that the chance of it working without hitting a missing syscall or desync is only about 50%, which is why I want a different solution that doesn't rely on the fragile syscall recording approach.
Re: Debugging in the Multiverse
#33It is really interesting to me that this sort of thing didn’t come from programming language folks like I’d expect. You’d think PLs are in the absolute perfect spot to implement things, because they define the semantics and runtime. And there are a few PLs who have time-travel demos, but they’ve never really been seen as more than a cool tech demo. Perhaps the language is too small a vantage point to really get into…
Elm debugger did something like this, but it's much more limited in scope.
Re: Debugging in the Multiverse
#34It is really interesting to me that this sort of thing didn’t come from programming language folks like I’d expect. You’d think PLs are in the absolute perfect spot to implement things, because they define the semantics and runtime. And there are a few PLs who have time-travel demos, but they’ve never really been seen as more than a cool tech demo. Perhaps the language is too small a vantage point to really get into…
I don't know to what degree this is true for other language teams but one thing I've observed is that language designers, compiler people, VM people, and IDE/debugger people have more distinct cultures than you might expect. That can make it hard to ship features that cut across those domains. I think we've gotten a lot better at doing that kind of holistic design on the Dart team, but it took years of team-building to get there.
Re: Debugging in the Multiverse
#35Re: Debugging in the Multiverse
#36Antithesis employee here. Happy to jump in and answer any burning questions people might have about multiverse debugging.
Re: Debugging in the Multiverse
#37Re: Debugging in the Multiverse
#38I know I'm taking the wrong thing from this - but I really struggle to read this site. Something about the contrast and aggro gradients.
Re: Debugging in the Multiverse
#39Re: Debugging in the Multiverse
#40It is really interesting to me that this sort of thing didn’t come from programming language folks like I’d expect. You’d think PLs are in the absolute perfect spot to implement things, because they define the semantics and runtime. And there are a few PLs who have time-travel demos, but they’ve never really been seen as more than a cool tech demo. Perhaps the language is too small a vantage point to really get into…
No language will prevent you from misimplementing the specs, but languages can be designed in such a way that it easy to trace back why the button is green and not red.
It seems like those who are the most serious about debugging are from the video game industry. They get all the cool stuff with time travel, hot reload, etc... So much that I expected to see something about video games, and was surprised it wasn't.