1
TRACING ERRORS IN SOFTWARE
COPYRIGHT NOTICE
A portion of the disclosure of this patent document con- 5 tains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatso- 10 ever. The following notice applies to the software and data as described below and in the drawings hereto: Copyright© 2005, Microsoft Corporation, All Rights Reserved.
BACKGROUND 15
It is often difficult to determine the root cause of an error in complex multilayered software. In some situations, upper layers of software abstract the details of the errors caused by lower layers and present a more user-friendly output to the 20 person using the software. This abstraction of failures makes diagnosing the exact cause of the error difficult.
One of the technologies that can be used to counteract this loss of information due to abstraction of errors is tracing. Optional trace statements (for example, calls to the applica- 25 tion programming interface (API) of a tracing tool) are embedded in the code to record the error at each layer in the software, thus creating a trace of the errors across the crosssection of the multilayered software. This trace may be used to better understand the error and to rapidly determine the root 30 cause.
However, if an error occurs in a portion of the software which lacks trace statements, the root cause of the error may not be clear to the person analyzing the problem.
35
SUMMARY
paths having trace statements that identify the reason for the error and/or the percentage of error paths having trace statements of any kind. These and similar quantifications may be used to compare the quality of error tracing in different pieces of code.
BRIEF DESCRIPTION OF THE DRAWINGS
Embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like reference numerals indicate corresponding, analogous or similar elements, and in which:
FIG. 1 is a flowchart of a method to measure trace statements in error paths of software code, according to some embodiments of the invention;
FIG. 2 is an exemplary sample of software code, helpful in understanding embodiments of the invention;
FIG. 3 is a functional block diagram of an error tracing analysis tool, according to some embodiments of the invention;
FIG. 4 is a graph of a finite state machine to be implemented by a component of the tool of FIG. 3, according to an embodiment of the invention;
FIG. 5 is a graph of another finite state machine to be implemented by a component of the tool of FIG. 3, according to another embodiment of the invention; and
FIG. 6 is an illustration of an exemplary system for implementing embodiments of the invention, the system including one or more computing devices.
It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity.
DETAILED DESCRIPTION
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to 40 identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Tracing helps people understand what a software program is doing by showing how the program is executed. It is good 45 practice for a programmer to add tracing statements (for example, calls to the application programming interface (API) of a tracing tool) to the software code of the program. If the tracing is enabled while the program is running, the trace statements will output trace messages to a debugger or to a log 50 file.
A software function may return a value to the function that called it. If a called function behaves as intended, it may return a value to indicate the success of the called function. However, if the called function does not behave as intended, 55 it may return a value that indicates that an error has occurred.
An error tracing analysis tool applies static code analysis to software source code to identify error paths in the code and determine how many of these error paths have trace statements. Recommendations to include trace statements in error 60 paths that are identified as lacking trace statements may be made. Trace statements may be automatically inserted in error paths that are identified as lacking trace statements.
Trace statements that identify the reason for the error provide more information than trace statements that merely indi- 65 cate that an error has occurred. The quality of error tracing in the code may be quantified based on the percentage of error
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the invention. However it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments of the invention.
According to some embodiments of the invention, an error tracing analysis tool applies static code analysis to software source code to identify error paths in the code and determine which, if any, of these error paths have trace statements. In one example, an error path is defined as starting a point in the code where an error could be returned from a function called by the current function and as ending either where the error is returned by the current function or at the start of another error path that starts before the error is returned by the current function.
A non-exhaustive list of examples of trace statements includes statements that print a trace message to an output file or a printer, calls to the application programming interface (API) of a tracing tool, and statements that log the error in a circular buffer in the memory.
The error tracing analysis tool may make recommendations to include trace statements in error paths that are identified as lacking trace statements. For example, the error tracing analysis tool may produce output that identifies the starting points of error paths that lack trace statements. A software engineer may then add trace statements to the software source code. Trace statements may be automatically
inserted in error paths that are identified as lacking trace
statements. The automatic insertion of trace statements may
be performed by the error tracing analysis tool or by another
tool that makes use of the output of the error tracing analysis
tool. 5
Trace statements that identify the particular error that has
occurred provide more information than trace statements that
merely indicate that an error has occurred. The quality of
tracing in the code may be quantified based on the percentage
of error paths having trace statements that identify the error 10
and/or the percentage of error paths having trace statements
of any kind. These and similar quantifications may be used to
compare the quality of tracing in different pieces of code.
FIG. 1 is a flowchart of a method to measure trace statements in error paths of software code, according to some 15 embodiments of the invention. The method may be implemented by an error tracing analysis tool such as that described below with respect to FIG. 3.
At 102, the tool systematically detects error paths in the software code using static code analysis. For example, this 20 systematic detection may include matching code constructs in the software code to predefined patterns.
In one specific example, the OPAL functional programming language, an informal specification of which is found at http://www.cs.oberlin.edu/~jwalker/opal/spec/, was used to 25 define the following patterns for the start of error paths:
pattern p_Trace
{CALL A?WPP_SF_/ $1} or
{ CALL A?WPP_S F_/ $ 1};
pattern p TraceNoError
{CALL A?WPP_SF_J } or
{CALL TraceEvent} or
{CALL TraceEventlnstance } or
{CALL TraceMessage } or
{CALL TraceMessageVa } or
{CALL EventWriteTransfer } or
{CALL EventWrite } or
{CALL EvenfWriteString } or
{CALL EtwWrite } or
{CALL EtwWriteString };
The p_Trace pattern is matched if a function the name of which includes WPP_SF_ is called that returns a value. The p_TraceNoError pattern is matched if a function the name of which includes WPP_SF_ is called that does not return a value or if a function with one of the other names listed above is called. WPP is an acronym for Windows® software trace processor.
At 106, the tool identifies the location in the software code of an error path detected at 102 and not identified at 104 as including at least one trace statement. For example, this loca
pattern p FuiictionReturnedNtStatus
{CALL fonction RETURNS :$1} and
fonction:TYPE:RETURNS:TYPESYMBOL:NAME:"NTSTATUS"
where {NE $10};
pattern p FvrnctionReturnedHresultError
{CALL fonction RETURNS:$1} and
fonction:TYPE:RETURNS:TYPESYMBOL:NAME:"HRESULT"
where {NE $10};
pattern p FvrnctionReturnedDWORD
{CALL fonction RETURNS :$1}
and function:TYPE:RETURNS :TYPESYMBOL:NAME:"DWORD"
where {NE $10};
pattern p FvrnctionReturnedlnt
{CALL fonction RETURNS :$1}
and function:TYPE:RETURNS :TYPESYMBOL:NAME:"int"
where {NE $10};
pattern p FvrnctionReturnedHANDLE
{CALL fonction RETURNS :$1}
and function:TYPE:RETURNS :TYPESYMBOL:NAME:"HANDLE"
where {NE $1-1};
These error path start patterns are matched if a function is called that returns a value of a specified type and the value is not equal to the return value that indicates no error.
The OPAL language was used to define the following pattern for the end of an error path:
At 104, the tool automatically determines, using static code analysis, which, if any, of those error paths detected at 102 that include at least one trace statement. Again, this may be accomplished by matching code constructs in the software code to predefined patterns. To continue the specific OPALbased example, the following patterns may be used to define and recognize a trace statement:
tion may be identified by code line number, and may be
5Q provided to the user of the tool via a suitable output such as a log file. The output is effectively a recommendation to the user to insert at least one trace statement in the software code in the detected error path that currently lacks trace statements. The identification of locations of error paths that lack trace
55 statements may be performed for one or more of such error paths in the software code.
At 108, the tool automatically inserts a trace statement into the detected error path that does not include at least one trace statement. The inserted trace statement may be a simple trace
60 statement that merely indicates that an error occurred. Alternatively, the inserted trace statement may identify the particular error that has occurred.
The identification of the locations is optional and may depend upon the implementation and/or configuration of the
65 tool. The automatic insertion of trace statements is optional and may depend upon the implementation and/or configuration of the tool.
