> if the debugger keeps recording the full sequence of states and actions, It's worth noting that the main time travel debugging technologies don't keep the st

> if the debugger keeps recording the full sequence of states and actions, It's worth noting that the main time travel debugging technologies don't keep the state of every operation performed, only the non-deterministic ones (i.e. where new information flows into the recorded program). A compute-intensive simulation can run a few days and generate little-to-no state that needs recording. Your point stands, though, that a malicious attacker could do many non-deterministic operations (e.g. read data in from a socket). This can be solved - relatively easily - with a circular logging approach is workable to address this. i.e. discard chunks of older history to free up space as you go. (Whether individual time travel debuggers support that is, as far as I'm aware, more a case of balancing demand for the feature against engineering effort.) > Such debugger would not be able to sustain a DoS attack if debugging in production (it would spam the debugger with lots of different states generated by the attacker); in fact, it would likely make it easier for an attacker to DoS a service as it would consume computational resources. In-production use could potentially be very useful if that's where some weird flaky issue occurs, so this is worth worrying about. It's definitely true that you've got to have the resources / settings to not overwhelm your machine. The other thing is that adding a complex layer of additional software risks adding additional exploits into the mix. If your production issue is at a customer site or in a semi-trusted context (corporate network service) - which for some software is the norm - then I think that makes the threat model a bit less scary. Otherwise, I guess it's a case of sandboxing the software within other measures and maybe spawning a separate instance that's recorded so you've still got "normal" instances running in parallel?