Browse Prior Art Database

Stack Bottoms as Unique Context (or Thread) Identifiers in AIX Processes

IP.com Disclosure Number: IPCOM000117439D
Original Publication Date: 1996-Feb-01
Included in the Prior Art Database: 2005-Mar-31
Document File: 4 page(s) / 96K

Publishing Venue

IBM

Related People

Fortin, MR: AUTHOR

Abstract

Disclosed is a technique which allows for the identification of unique execution contexts within a process. The technique allows software analysts to better understand complex programs, enabling them to more efficiently identify and fix performance and/or functional problems.

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

Stack Bottoms as Unique Context (or Thread) Identifiers in AIX Processes

      Disclosed is a technique which allows for the identification of
unique execution contexts within a process.  The technique allows
software analysts to better understand complex programs, enabling
them to more efficiently identify and fix performance and/or
functional problems.

      Performance and debugging tools often produce "callgraphs" of
programs by instrumenting routines within the programs.  A callgraph
is a visual representation of a program's execution flow from routine
to routine.  The following callgraph, in Fig. 1, depicts the flow of
a program with four routines, A(), B(),C() and D().  In the
callgraph, A() calls B() two times.  In the first call, B() calls C()
and D() one time each.  In the second call, B() only calls C().
          ->A()
             ->B()
                    ->C()
                    <-C()
                    ->D()
                    <-D()
             <-B()
             ->B()
                    ->C()
                    <-C()
             <-B()
      ->A()
  Fig. 1: Sample Callgraph

      Callgraphs can be produced by placing special instrumentation
routines at the entry and exit points of the routines in the program.
When a routine is entered or exited, an entry or exit type event is
logged in a buffer.  A post processing tool can then piece together
the sequence of events, showing enters and exits at the appropriate
indentation levels.

      Unfortunately, there are a number of events that may distort
this simple enter-exit logic.  One such event is a signal.  A signal
may be received by the program, thereby invoking a signal handler and
other routines.  As the signal handler and other routines are
executed, their enter and exit events confuse the callgraph.  As an
example, assume the above program received a signal while executing
within routine D() and that the program was designed to handle the
signal via the signal_handler_one() and signal_handler_two()
routines.

      As shown in Fig. 2, the signal's occurrence has distorted the
callgraph making it appear as though routine D() has called routine
signal_handler_one() directly.  In reality, the signal handling
routines are not part of the same program context as routines A(),
B(), C() and D().
      ->A()
             ->B()
                    ->C()
                    <-C()
                    ->D()
                           ->signal_handler_one()
                                  ->signal_handler_two()
                                  <-signal_handler_two()
                    ...