[quotemstr]

Oh. When I read the section on instrumenting function returns, I thought they were going for something more general, since they talk about analyzing assembly. Now I see they're looking at individual Box and Rc instances and have special cases for stdlib data structures. Async support is also a to-do item.

I can't see this approach working for very long. Tracing at the binary level, whether you do it as RR does with performance counting or whether you do it via instrumentation like Undo and iDNA, works for the general case because it records execution at the lowest level available to a process and therefore captures everything, without special cases.

If these guys want to make a fancy time travel debugger data explorer, that's great. They could in principle make one on top of existing tracing technology without having to simultaneously reinvent both the debugger core and the GUI.

[khuey]

From https://firedbg.sea-ql.org/blog/2023-12-11-architecture-of-f... it seems more like lldb automation than what "time travel debugger" brings to mind.

[Veserv]

Wow. It is not even a proper time travel debugger. I just assumed they were ingesting a proper time travel debugger log and driving a proper replay engine and just wrote a bad integrated trace viewer on top. That would at least be excusable. This is just inane.

The "time travel debugger" solution they use automatically sets numerous breakpoints and then records a tiny, useless fraction of the information needed to actually recreate past state, but is almost certainly slower than any actual, fully-functional time travel debugger by multiple orders of magnitude. That was the same technique used by the built-in gdb "reverse debugging" which, at least historically, resulted in 1,000x-10,000x (yes, really) slowdown compared to modern techniques which are on the order of 2x-10x. And to at least give gdb some credit, gdb reverse debugging was at least a complete time travel debugger since it recorded everything; it was just unusably slow. That is more than can be said about whatever this is. They would be significantly better off in both functionality and performance wrapping literally any other actual time travel debugger solution.

Then we add on their awful, bespoke trace viewer. I originally just chalked it up to them being unaware of standard practices since most people are unfamiliar with time travel debugging and the associated tooling and they just wanted to show off what they did with some bluster. That is excusable, if somewhat unfortunate. But this is the metaphorical equivalent of claiming you have solved the problem of inserting screws because you invented the hammer which is much better at hammering in screws than a brick.

Their marketing statements are unacceptable misrepresentations of their capabilities with respect to commonly-accepted meanings.

It is utterly baffling that this is more popular than the recent UndoDB thread [1]. They have a real time travel debugger and have been doing it for like 15-20 years. They are actual veterans doing quality engineering.

[1] https://news.ycombinator.com/item?id=44076300

[quotemstr]

That's the culture that's emerged in tech over the past few years: a rejection of technical rigor and an abuse of language to ape, poorly, the cachet of past accomplishments. This thing is a "time travel debugger" (it isn't). A program to bundle typescript into an executable is called a "compiler". They use cool-sounding words without the substance.