System requirements¶
The system requirements for the Undo Engine are as follows:
64-bit Linux kernel
GNU C Library (
glibc
)GNU POSIX Threads library (
libpthread
)
The Undo Engine does not require any kernel patches or loaded kernel modules. Most Linux distributions therefore support the Undo Engine without modification. The supported kernel versions are those shipped with the supported distributions listed below.
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 process.
Architectures¶
The Undo Engine is supported for use with 32-bit and 64-bit processes running on a range of Intel and AMD x86-64 microprocessors.
Intel microarchitectures from Haswell through to Golden Cove are supported, which include the majority of Xeon processor models that are currently in use.
AMD processor models based on the Zen microarchitecture are supported.
Support for ARMv8 architectures is currently available only to selected customers. Contact Undo Support for more information.
Linux distributions¶
The Undo Engine is supported on the following Linux distributions:
Red Hat Enterprise Linux (and CentOS where applicable) 7.9, 8.6, 8.8, 8.9, 9.0, 9.2, 9.3.
Fedora 38, 39.
SUSE Linux Enterprise Server 12 SP5 (12.5), 15 SP4 (15.4), 15 SP5 (15.5).
Ubuntu 20.04 LTS, 22.04 LTS, 23.04, 23.10.
It will run on most other reasonably modern Linux distributions and versions.
When running the Engine on Fedora, Red Hat Enterprise Linux 9.0 and newer and Ubuntu 22.04 LTS and newer, please be aware of a limitation when attaching to running programs due to Restartable Sequences.
In environments where the ARM architecture is supported, the Undo Engine
requires glibc
2.28 or newer to be available on the host distribution. In
consequence, some older distributions such as RHEL / CentOS 7.x and SLES 12.x
are unsupported when running on an ARM system.
GDB¶
UDB depends on GDB (currently GDB 13.2) which is supplied as part of the release.
Other operating systems¶
At this time the Undo Engine does not support non-Linux operating systems such as Windows or macOS. Contact Undo Support if you’re interested in support for a non-Linux operating system.
RAM usage¶
The main memory requirements for the Undo Engine come from snapshots and the event log.
Regarding 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-execution commands such as
reverse-next
and reverse-continue
run 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 at startup using the
--max-event-log-size
command-line option,
or interactively using the set max-event-log-size command.
Disk usage¶
During normal operation of LiveRecorder, no information is written to disk: all information is stored in memory. When a recording is saved by LiveRecorder, the in-memory representation of the recorded process is synchronously written to disk as a recording file.
The size of this recording file is determined by various factors. Most notably, the amount of non-deterministic data generated by the process and the size of the process’ memory image. Recording files are compressed, so the size of the recording file is often less than the combined sizes of the memory image and non-deterministic event log.