Debugging a memory corruption and logic errors

We used Undo to locate the root cause of the memory corruption and the logical errors. Without Undo, it would have taken significantly longer to get the right set of data to solve such issues, which typically could be upwards of a week.

Ajit Kumar Rajak, Senior Software Engineer at HPE

During system integration testing of an application, we hit a test failure.

It uncovered a memory corruption, and logical errors. We used Undo to locate the root cause of the memory corruption and the logical errors. One of the recordings, was used to ascertain the correctness of the logical workflow. While doing that, we found logical errors. In other words, we managed to find the exact point in the recording where the execution diverged from what was expected out of the program.

Typically, a crash/core can give a lot of information about the fault in the program. But, because this was a logical problem, it took a couple of days to identify the area in the program, that was faulty. Without Undo, it would have taken significantly longer to get the right set of data to solve such issues, which typically could be upwards of a week.

With Undo, we get the necessary data we need in one swoop. We can reduce the repeated handoffs across the different teams involved (eg: dev & test). We reproduce the issue once, and everything we need to debug the issue is contained in the recording, eliminating the need of executing the same flow repeatedly. We also eliminate, to an extent, the requirement of correlating the available information with other debug tools (like logs).

I see Undo as an innovative tool, which eases the debugging process and elevates productivity.

Learn more about Undo