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

A SYSTEMATIC AUTOMATED PROCESS FOR REPRODUCING SOFTWARE EXECUTION

IP.com Disclosure Number: IPCOM000005545D
Original Publication Date: 2001-Oct-12
Included in the Prior Art Database: 2001-Oct-12
Document File: 4 page(s) / 47K

Publishing Venue

Motorola

Related People

Kurt Shultz: AUTHOR [+2]

Abstract

A common practice in software support is to reproduce the experience of the end-user at the support site. Usually this is for the purpose of debugging the software, although the collection of regression tests can be a motivating factor. The usual procedure for reproducing a software execution might consist of having the user gather the appropriate inputs to and environment of the software and then having the support engineer modify those inputs and environment, or a create reasonable facsimile thereof, at the support site. This procedure can be difficult even for a single piece of software and the complexity increases when that software is embedded in a system of software, or, perhaps, even unknown to the end-user. When the system is complicated, or the user is unfamiliar with its workings, there is generally a cycle of communication between the support engineer and the end-user in which more and more information is requested and delivered as the support engineer discovers he or she is missing a necessary piece. Moreover, there is no guarantee that a modified environment and/or inputs at the support-site will faithfully reproduce the end-users execution. We present a method for automating the collection of all of the information needed to reproduce software executions for a particular class of applications by instrumenting the software itself. This method also eliminates the cycle of communication, automates the regeneration of the execution at the support site, and provides a guarantee of faithful reproduction.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 36% of the total text.

A SYSTEMATIC AUTOMATED PROCESS FOR REPRODUCING SOFTWARE EXECUTION

by Kurt Shultz and Srinagesh Loke

ABSTRACT

A common practice in software support is to reproduce the experience of the end-user at the support site.  Usually this is for the purpose of debugging the software, although the collection of regression tests can be a motivating factor.  The usual procedure for reproducing a software execution might consist of having the user gather the appropriate inputs to and environment of the software and then having the support engineer modify those inputs and environment, or a create reasonable facsimile thereof, at the support site.  This procedure can be difficult even for a single piece of software and the complexity increases when that software is embedded in a system of software, or, perhaps, even unknown to the end-user.  When the system is complicated, or the user is unfamiliar with its workings, there is generally a cycle of communication between the support engineer and the end-user in which more and more information is requested and delivered as the support engineer discovers he or she is missing a necessary piece.  Moreover, there is no guarantee that a modified environment and/or inputs at the support-site will faithfully reproduce the end-user’s execution.  We present a method for automating the collection of all of the information needed to reproduce software executions for a particular class of applications by instrumenting the software itself.  This method also eliminates the cycle of communication, automates the regeneration of the execution at the support site, and provides a guarantee of faithful reproduction.

 


SCOPE OF THE METHOD

We will focus the discussion on applying the method to typical Unix batch processing applications.  For such software the inputs are generally command-line arguments and files read from the file system.  The environment is a set of variable/value pairs.

While we will not address interactive tools, the extension of the method to some class of interactive tools (those without asynchronous interrupts) is expected and has, to some degree, been achieved.

This method does not specifically address reproducing the environment beyond the reasonable, e.g. we do not address reproducing the amount of available memory, the specific CPU, drivers, hardware devices, peripherals, network, or system load.

INSTRUMENTING THE SOFTWARE

To apply the method, the software must first by instrumented by the developer.  Code is added at the points where the software interacts with its operating system.  This instrumentation serves two purposes:

a. to collect the inputs, environment, and other useful data at the end-user’s site, and

b. to translate the inputs and environment when reproducing the run at the developer’s site.

In a usual application, code is added to collect the command-line arguments, note the path of any referenced input file, and collect the environment variable name/value pairs to which the software is sensitive.  The same...