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.
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.
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.
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.
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.
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.
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.
See any value in your program's memory or registers for any instruction in its execution history.
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
Learn how SAP is improving software quality in multi-threaded database, SAP HANA.Download case study
See how Live Recorder helps you fix even intermittent test failuresRead whitepaper
Everything you need to know about reversible debugging and why you should use it.Read whitepaper