System and method for improving time-sensitive issue debugging
Publication Date: 2015-Jun-24
The IP.com Prior Art Database
Debug trace output based problem determination is commonly used in software support and maintenance, but the trigger of timing sensitive problem might not happen when heavy debug trace is enabled. The article provides a system and method which supports enabling of heavy debug trace output, and at the mean time such time-sensitive issue could still be reproduced
Page 01 of 15
System and method for improving time
System and method for improving time- --sensitive issue debugging
sensitive issue debugging
Debug trace output based problem determination is commonly used in software support and maintenance. Some kind of software problem are timing sensitive. E.g. multi-thread race condition. On one hand, we depend on more debug/trace output to analyze such complex issue. On the other hand, the trigger of such issue could be impacted by heavy trace output so that it might not happen at all when tracing is enabled.
As above diagrams illustrate, debug trace output adding significant execution time to ordinary execution, which changes the "relative velocity" between Thread-A and Thread-B. Therefore when debug trace is enabled, the issue itself might not happen at all or the situation is different from the original status which we want to analyze.
Page 02 of 15
The aim of the current invention is to provide a system and method which support enabling of heavy debug trace output, and at the mean time such time-sensitive issue could still be reproduced.
To reproduce such time-sensitive issue, we need to ensure the "relative velocity" between multiple threads still as the same as (or approximate to) before debug trace is enabled.
Therefore the rate of execution time between writing debug trace and ordinary execution is the key. The lower the rate is, the less impact to entire execution time.
Execution time (ordinary) = execution time of ordinary task Execution time (debug) = execution time of writing debug trace output Execution time (with trace) = entire execution time when debug trace is enabled
Execution time (with trace) = (1 + Rate) * Execution time (ordinary)
Page 03 of 15
The core idea is to find a way to keep the rate as lower as possible. In the current invention we provide two solutions to achieve it.
Solution 1: For the execution of generating and writing debug trace, delay time-consuming operations to after ordinary execution finished. In this way the execution time of ordinary task won't be impacted very much, and heavy debug trace could be enabled.
Solution 2: Make the whole process running slower in purpose, but only keep debug trace output running as fast as possible. In this way all threads in the same process will be slow down, which keeps "relative velocity" between multiple threads as the same as before. Also the rate between debug trace execution time and ordinary execution time must be lower.
Page 04 of 15
Advantage of current invention
On one hand, the current invention speeds up debug trace output during ordinary execution time . On the other hand, it ensures generating plenty of debug trace has no impact to time sensitive issue, therefore the issue could be reproduced.
Solution 1: Delayed Debug Trace Generation
This solution discloses the method to delay generation of debug trace, until after ordinary execution finished, to ensure no significant impact on ordinary execution time.