Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method of Tracing Events in Multi-threaded OS/2 Applications

IP.com Disclosure Number: IPCOM000105697D
Original Publication Date: 1993-Sep-01
Included in the Prior Art Database: 2005-Mar-20
Document File: 4 page(s) / 98K

Publishing Venue

IBM

Related People

Huggins, JA: AUTHOR [+3]

Abstract

Disclosed is a method for implementing an event trace facility for multi-threaded application programs running under OS/2*. This event trace has the capability of recording the application use of OS/2 functions, intra-application function calls, and other events and data specific to an application. It can be used for the debugging of problems which are found in a multi-threaded application due to the occurrence of deadlocks or improper serialization of resource usage where the events occur in unanticipated sequences.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Method of Tracing Events in Multi-threaded OS/2 Applications

      Disclosed is a method for implementing an event trace facility
for multi-threaded application programs running under OS/2*.  This
event trace has the capability of recording the application use of
OS/2 functions, intra-application function calls, and other events
and data specific to an application.  It can be used for the
debugging of problems which are found in a multi-threaded application
due to the occurrence of deadlocks or improper serialization of
resource usage where the events occur in unanticipated sequences.

      The trace facility has the capability of tracing the
interaction of the application with the underlying OS/2 operating
system by intercepting selected OS/2 function calls.  Calling
parameters are extracted and saved, the OS/2 function is invoked, and
return parameters are extracted and saved.  Control is then returned
to the application.  The saved parameters, along with information
identifying the type of OS/2 function and the issuing thread and
process identifiers, are saved sequentially in a wrap-around table in
memory, providing a sequential recorder of the order in which the
events occurred.

      In addition, application specific events can be traced in two
ways.  First, application function calls can be traced in the same
way as OS/2 function calls, as described above.  Secondly, an
application programmer may add trace points to the application by
explicitly issuing function calls to the trace facility to trace
arbitrary events and their associated data.

      The Figure shows the general logic flow for making an entry in
the trace table.  The trace table may be viewed in memory using a
source debugger or any other tool that allows memory to be examined.

      Upon termination of the application, the contents of the trace
table in memory are written to disk using the exit list processing
facilities of OS/2.  This dump can then be used for debugging the
problem.  Alternatively, an option can be set to dump the trace table
to disk each time that it fills.

      The trace facility is constructed as a Dynamically Linked
Library (DLL) which can be linked to any program to remap specified
function calls.  Thus, it can be added to an existing application
transparently without the need for recompilation of the existing
code.  Because the trace code is a DLL, multiple threads and
processes can be linked with the trace facility and make entries into
the same table.

A sample link command to create an untraced executable module might
be:

     link main.obj+module.obj+crtexe.obj,main.exec,,crtlib.lib
os2.lib;

 ...