Total visibility into your program’s execution

You think you know what your software did but then it unexpectedly fails. Where do you go from here?

Finding out exactly what your program did before it misbehaved or failed is difficult, making diagnosis of the root cause a challenge.

Traditional debuggers are of limited use

If your program crashes, you can run the program under the control of a debugger, probably multiple times so that different breakpoints and watchpoints can be tried. However, if a developer steps through the code without discovering the root cause, they must go back to the start of their program and repeat the process, which is time-consuming and a drain on productivity.

Reproducing failures is hard

To figure out the source of the failure, a developer generally needs access to the machine on which the failure occurred or at a minimum, a reliable account of the circumstances which caused a test to fail or production outage to happen. Even then, it can be hard to reproduce the exact set of circumstances that brought the failure about, making it difficult to find the root cause.

Intermittent failures are hard to fix

Irreproducible failures or bugs which appear intermittently are much more difficult to locate. If core dumps, regular debuggers and using printf do not resolve the problem, it can be easier to ignore these types of failures and hope that they don’t appear again, causing a backlog of ‘known’ failures to accumulate in your test suite.

Code comprehension

The result

Drain on productivity

A study by the University of Cambridge found that debugging is eating up 50% of development time. This is 50% of time that developers could spend writing new code.

Slipped development schedules

Bugs found by QA late in the development cycle means that product launch dates are put in jeopardy, and developers are under pressure to commit to delivering a fix by a certain date when they have insufficient information to make such a promise.

Production failures waiting to happen

A failing test demonstrates a risk that your product will fail in production - which can be catastrophic if the failure causes an outage or, worse, a security breach. Without diagnosing each and every test failure, you don’t know which failure is the dangerous one, so you must fix all of them to be certain, wasting time and resource.

We've got the solution

Undo’s suite of innovative products are designed for developers working in QA/Test and on production software. Record all or part of your program’s execution, and use our interactive reversible debugger to home in on the point of interest.

  • Improve quality

    Understand exactly what your software did by capturing each and every failure in a recording, and step backwards as well as forwards in the code to diagnose the root cause.

  • Complete visibility into execution history

    See any value in your program's memory or registers for any instruction in its execution history.

  • Debug faster

    Undo’s technology increases development productivity by at least 26%. Find and fix errors quickly and free up resource to work on more productive things, such as writing new code

Undo products

Useful related resources

Fuzz testing of SAP HANA using LRT

Learn how SAP is improving software quality in multi-threaded database, SAP HANA.

Download case study

Getting the most out of QA

See how Live Recorder helps you fix even intermittent test failures

Read whitepaper

What is reversible debugging?

Everything you need to know about reversible debugging and why you should use it.

Read whitepaper