Browse Prior Art Database

Time Freeze

IP.com Disclosure Number: IPCOM000247762D
Publication Date: 2016-Oct-06
Document File: 4 page(s) / 23K

Publishing Venue

The IP.com Prior Art Database

Abstract

There are lot of time sensitive applications in the field which includes banking transactions, share market transactions etc., If there are any issues in these, developer needs a methodology to debug them without impacting the control flow of the application that depends on time. If timer keeps running , the control flow of the application might change which will make it tougher to debug and find the root cause of the issues.

This article provides an approach to enable the developers to debug time sensitive applications by freezing the time while the application is attached to debuggers.

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

Page 01 of 4

Time Freeze

Today time sensitive applications are more commonly seen in real time data processing workloads. Time sensitive applications are always based on current system time. Timeout factor plays a major role here. In the development environment, debugging of such time sensitive applications are challenging as the process need to be suspended/stopped often at breakpoints which will impact the time sensitive nature of the application.

Scenario:

Lets take a time sensitive real time application:

Banking transactions


- Transaction should rollback if not able to complete within specific period of time

To debug such an application, it needs to be attached to a debugger program.

Breakpoints can be set at various points based on the problem. On hitting the breakpoint, application is suspended and debugger will attach itself to the application's address space providing full access of the application's process data to the developer. (Example: Variables, memory, threads)

Even though the application is in suspended state for a reason(ex:debugging) , timeout factor still follows the Wall Clock Time(System time). The problem will surface when this application resumes from the debugger. The application code now flows in different path than expected due to the time factors. So now we can never debug the expected code path.

The main cause for this problem is timeout factor which takes into account, even the time used for debugging, which leads the application to always timeout thus results in a different code flow than expected.

Core idea is to provide a method to control the timer for any process under special conditions like debugging.

This has three parts:


1) Suspend of a process should consider the special conditions where the timer for the application should be freezed .


2) Resuming the process should restore the timer value to already stored frozen time .


3) Timer APIs should return data considering the frozen time fact


1) Suspend


A) Introduce a new signal called SIG_TIME_FREEZE which can be passed to a

1


Page 02 of 4

process under special conditions like debugging .

    B) Once this signal is received, Current timer state(monotonic time) will be saved in the process metatdata along with "suspend status" (FROZEN) to indicate the process is suspended/stopped for a special reason


2) Resume

    A) Look for the status of the process and obtain the timer data from the process metadata if the "suspend state" is FROZEN

    B) Once the process is resumed, take the delta of current time and frozen time and store in process metadata(TIME_FACTOR). Following is the calculation

Delta time += current time - frozen time

     (note: frozen time: Time when the process was suspended when the SIG_TIME_FREEZE signal was received)

    c) To address the above requirement, 2 new members should be added to the process table (suspend state, time_factor).


3) API handling

    A) Time APIs should be enhanced to provide new time value using the factor (Current system time - TIME_FACTOR) tak...