The system requirements for the Undo Engine are as follows:
- Linux kernel 2.6.18+
- C standard library (
- Pthread (
- Python 2.4+
The Undo Engine does not require any kernel patches or loaded kernel modules. Most Linux distributions therefore support the Undo Engine without modification. The Undo Engine also supports Android.
Furthermore, there is no need to re-build applications; any binary executable
can be debugged with the Undo Engine. It is recommended to build executables
with debug information, typically by passing the
-g option to the compiler,
since this allows the debugger to extract more information about the state of
The Undo Engine is tested on the following Linux distributions:
- Fedora Core (from 20 onwards)
- Red Hat Enterprise Linux and CentOS (from 5.1 onwards)
- SUSE Linux Enterprise Server (from 11 onwards)
- Ubuntu (from 12.04 onwards)
Other distributions may also be suitable, but support for these cannot be guaranteed.
The following architectures are supported for the Undo Engine:
When used through the udb frontend, UndoDB depends on GDB 7.0+.
By default UndoDB ships with a build of GDB that is known to work well with UndoDB. This build of GDB supports cross-architecture debugging (e.g. an x64 desktop debugging a program running on an ARM board) and is itself built for all of UndoDB’s supported architectures. Hence most users do not need to build their own version of GDB.
You can see which GDB is being by UndoDB when it runs:
udb: Starting <path-to-undodb>/package-gdb/install/x64/bin/gdb GNU gdb (GDB) 7.7
In this case, the path indicates the packaged build of GDB is being used.
You can specify a custom GDB build using the
--undodb-gdb-exe argument to
udb. For example:
$ udb --undodb-gdb-exe gdb [...] udb: Starting gdb GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Other Operating Systems¶
At this time the Undo Engine does not support non-Linux operating systems such as Windows or Mac OS X. Contact Undo Support if you’re interested in support for a non-Linux OS.
The main memory requirements for the Undo Engine come from process snapshots and the event log.
Regarding process snapshots, the Undo Engine normally stores about 30 of these by default, but they’re forked from the original process using copy-on-write so they’re created efficiently. In a short run of the program, these snapshots will be spaced closely together, while in a longer run, they will be spaced further apart. So, the memory consumption for snapshots remains fairly independent of the run time, but reverse operations such as reverse-next and reverse-continue can be executed much faster when there is a snapshot available more recently in the program history. In other words, longer runs affect replay performance rather than snapshot memory utilization.
Regarding the event log, its available space is consumed at a rate that corresponds to the volume of non-deterministic event behaviour. In programs that spend most of their time waiting for something to happen, the memory usage will be low. It’s true that in more non-deterministic applications (for example, those that perform lots of I/O operations) the memory that was allocated to store the event log will sometimes fill up. The size of this memory region is configurable, both in advance, and at the time of the event log filling up (should that happen). In addition, the event log can be configured as a circular buffer, in which case earlier events are discarded to make space for newly-created events. The most useful events are usually the ones from immediately before the program crash, so this is usually a reasonable compromise.
This is determined by various factors, including the amount of non-deterministic data read by the process.