LiveRecorder provides a one-click workflow from a test failure to a time-travel debugger placed exactly at the point of failure – skipping the tedious steps usually required to reproduce the problem and enabling developers to start debugging test failures instantly.
Developers working on complex C/C++/Go/Java software can now save a huge amount of time diagnosing the root causes of new regressions, legacy bugs, and flaky tests. Bugs that took days or weeks to fix can now be resolved in hours.
Built for heavily multithreaded applications, multiprocess programs, software using third-party components (e.g. open source), or single-threaded large legacy codebases.
Automatically record CI / System Test failures to capture the execution of failing test runs, including intermittent failures. Recordings capture all non-deterministic data (down to instruction level) and recreate your application’s entire memory and the register state – on demand and with minimal overhead.
No time needs to be spent reproducing the issue or any environmental conditions that contributed to it. Developers can start debugging test failures instantly.
Store the recordings in your CI or bug-tracking system for later analysis and cross-team collaboration.
LiveRecorder integrates with all popular CI automation tools, including Jenkins, Maven, Circle CI, and TeamCity. The core recording technology is language independent and compatible with most mainstream Linux distributions.
Launch a ready-to-go debug session in your browser with a one-click workflow: Jump from a test failure (or bug report) straight into a fully set up replay session of the recording that captured the bug. The in-browser debugger is based on Visual Studio Code (with Undo-specific additions/alterations), providing an easy-to-use UI to debug.
Debug locally or remotely: Recordings are portable, allowing developers to debug anytime and on any machine (out of the original environment).
Collaborate across teams and time zones: Recordings are shareable for effective asynchronous collaboration (share recordings, add comments, etc.).
Analyze execution history and get instant visibility into what your program did, and why.
Debug a failed CI or QA run from days, weeks, or months ago. The application behavior is 100% reproducible each time the recording is replayed.
LiveRecorder comes packed with enterprise features to handle even the most complex of applications – including heavily multithreaded or multiprocess applications, programs running on the cloud, virtual environments, etc.
LiveRecorder makes debugging predictable – unlike logging, core dumps, printf or standard debuggers. The recording will always behave in the same way anytime, anywhere, and for everyone; no more “works on my machine!”.
By allowing all developers to explore how the code is executed, developers new to the codebase can debug just as efficiently as more experienced team members.
With LiveRecorder, most problems become trivial to solve. I save a lot of time in not having to reproduce the issue.
Our software is running on distributed servers and interacts asynchronously; so when bugs occur, they are hard to catch. We use LiveRecorder to radically accelerate the fixing of intermittent or hard-to-reproduce bugs.
With LiveRecorder, we were able to dramatically cut down the analysis time that is required to understand the root cause of very complex software defects.
An intermittent stack overflow crash was left unresolved for over 6 months. We solved the issue in a week with LiveRecorder.
Here are some frequently asked questions and answers you may find helpful. Detailed technical documentation is also available in the Docs
We use binary instrumentation to capture only the bare minimum data required to record execution as efficiently as possible. To keep the overhead low, we don't translate instructions that don't require it.
The recording contains all information required to recreate the entire memory state of the recorded process at any machine instruction that was recorded. This includes:
LiveRecorder is capable of handling multi-threaded applications. Some of our customers record applications with 30-40 active threads and 100s of less active threads. For example it is used on SAP HANA - a heavily multithreaded application that uses custom memory allocators, custom threading libraries and that typically runs on a machine with 100s of cores and terabytes of RAM. Read case study