Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

A Mechanism to display and navigate service trace

IP.com Disclosure Number: IPCOM000238171D
Publication Date: 2014-Aug-06
Document File: 4 page(s) / 72K

Publishing Venue

The IP.com Prior Art Database


A mechainsm to display and navigate service trace using a visual tool similar to a graphical code debugger is disclosed. A combination of trace output and interpretation of the source code is used to imply the path the code that execution takes through the source code. A graphical viewer is used to display the location in the source code as the trace is processed.

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

Page 01 of 4

A Mechanism to display and navigate service trace

A mechanism is disclosed that addresses the interpretation and understanding of service trace. Service trace tends to be far harder to follow and step through than using a visual debugger that is attached to a process and is being used to step through the code as things happen. Often a lot of switching between service trace and source files has to be made by the user. This can get very difficult to manage when the source is complex and the service trace is very large.

    The concept of collecting service trace is already a well known idea and there are also tools that allow the instrumentation of code so it can later be replayed. This mechanism tries to solve the problem where there are existing products that have service trace but that do not have in-depth instrumentation of the code. Its main strength is it requires no changes to an existing product as long as it already produces service trace.

    A mechanism herein consists of a tool, similar to a normal visual debugger, that will allow the source code to be stepped through by analysing the service trace line by line. It would display each source file that is required for each trace entry as it was stepped through, and mark the line that the trace entry maps to. As well as stepping straight to lines that appear in the trace it could also infer the lines to be processed in between each trace statement based on the entries not seen in the trace and also the syntax of the programming language. It would also be possible to set other debugger concepts like break points and allow the tool to run until these break point are hit.

    The key difference with the mechanism herein over existing approaches is that it does not require special instrumentation to be done to the program that is being debugged. Instead, it works using tracing that already exists and so requires no change at all to the program. Most other approaches that do instrument the code tend to add instrumentation after every line.

    The mechanism herein uses trace entries that are available and infer stepping between lines without the need for line-by-line tracing. This has the added advantage of reducing the amount of tracing that is required.

    The following worked example uses a standard service trace syntax. The example requires no changes to the product itself and could work on any previous or current versions. The basic idea is to define patterns that can be used to match service trace entries to actual line positions in the source files. The entries in service trace map directly to strings in the source code:

  • logEntry(


) - written when entering a method • logExit() - written when leaving a method • logData(

) - written while in a method
Each of these types of trace entry have the following structure:

• logEntry: { ClassA::MethodB • logExit: } ClassA::MethodB • logData: ClassC::MethodD 'Checking dependencies for resource' , 'TraceLog'

Simple regular pattern matching...