Deferred Recording

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.

Enabling recording

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 example:

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.