By default UndoDB will immediately start recording once it starts (or attaches to) the debuggee process. Recording is necessary for reversible debugging, and hence this is usually desirable behaviour.
However recording adds runtime overhead (due to tracking and capturing non-deterministic events); deferred recording therefore provides a mechanism to start the debuggee with recording disabled and subsequently enable it at a point chosen by the user.
When to use¶
In most cases users are recommended to use UndoDB’s default behaviour of starting with recording enabled, which ensures that users are able to go backwards at any point during the debuggee’s execution (note that a circular event log can be used to avoid hitting system memory limits).
Deferred recording can be a good choice if an initial period of time in the debuggee’s execution is known to be good. It can therefore be useful to skip over that period of time before enabling recording.
How to use¶
Starting UndoDB with recording disabled¶
UndoDB has an option
--undodb-defer-recording, which specifies that UndoDB
should start with recording disabled.
The effect of this option is that all reverse commands are disabled, and hence the functionality is very similar to a normal GDB session.
Once the user has skipped over the known good initial period of time in their
program’s execution, they can enable recording with the
urecord command. For
udb --undodb-defer-recording /path/to/debuggee ...UndoDB starts... (udb) break main (udb) run Breakpoint 1 in main () (udb) urecord udb: Have switched to record mode. (udb) continue udb: The program has exited, but is still being debugged. udb: (You may use undodb commands to go backwards.) (udb) reverse-continue Breakpoint 1 in main () udb: Have reached start of recorded history.