Yes, although your debug experience will be the same as using regular debuggers on optimised code.
Yes, you can ship or deploy a Live Recorder enabled application without debug information. Load the recording and point at a version of the binary with the debug information to get full source-level debugging.
Live Recorder typically causes programs to experience a 2-3x slowdown. This can be more or less, depending on the individual situation.
Spatial requirements vary hugely depending on the program, but typically a few megabytes per second of recording.
Yes. Live Recorder uses a circular event log so old history is discarded. Due to the performance overheads however, most of our customers do not run their programs with Live Recorder always on, but have a way to enable or disable recording as required.
Yes. As long as both the record and replay machines are running Linux and use the same CPU architecture, it's fine. However, you can't replay ARM recordings on x86. Live Recorder is not a simulator, so your replay machine CPU must support all of the instructions used on the recording machine. E.g. if your program uses AVX instructions when the recording is made then you must replay on a machine with a CPU that has AVX support.
Live Recorder is enabled simply by calling the undodb_recording_start() function.
Yes. Just by calling the undodb_recording_stop() function.
The recording is saved to a file on the local filesystem. The recording is generated when you call the undodb_save() function, or, if so-configured, when the program terminates.
The recording contains the program starting state, all non-determinstic inputs, any debug information files and all libraries used by the program are all contained in the recording. It is completely self-contained.
We exploit the natural determinism of computers. Computers are completely deterministic; except when they’re not. So these classes of non-determinism (for example: IO, scheduling, signals, shared memory and others) are captured. When you step back in time, what’s happening under the hood is we’re going back to a snapshot and playing that forward to exactly where it needs to be. We’re capturing the minimum that we need to be able to take you back to any point in time but you have full visibility, all your globals, all your locals, everything rolls back to what it was at that time.
Distributed systems are inherently very non-deterministic. With Undo today, you have to record each of the nodes in your distributed system and manage the replay of that. So it’s a manual process, but we are working towards a point where you can follow the data through the distributed system and be able to click ‘next’, going from one node to another.
It works beautifully. The generated code is what the program is doing, there’s nothing special in that sense as it’s just the data it’s writing. We have lots of customers who have lots of generated code because those are really nasty cases to debug. We don’t give you magic, it’s still like using GDB, you’re still stepping through and looking at the hex and all the disassembly of the code that’s been generated. The difference of course is with the time travel debugging it’s much more tractable to figure out, especially when the generated code causes memory corruption.