Browse Prior Art Database

System and method for improving time-sensitive issue debugging

IP.com Disclosure Number: IPCOM000242185D
Publication Date: 2015-Jun-24

Publishing Venue

The IP.com Prior Art Database

Abstract

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

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 25% of the total text.

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.

1


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)

2


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.

3


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.

One...