Distributed indirect software instrumentation

Details Distributed indirect software instrumentation Distributed indirect software instrumentation

1998-06-19

2001-04-10

Iqbal, Nadeem (Department: 2184)

Error detection/correction and fault detection/recovery

Data processing system error or fault handling

Reliability and availability

C714S035000

Reexamination Certificate

active

06216237

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates generally to computing systems, and more particularly to software instrumentation techniques for use in such systems.
BACKGROUND OF THE INVENTION
Software instrumentation refers generally to the process of modifying a program to include additional code, referred to as instrumentation code, which is designed to provide various types of monitoring and analysis of program performance during program execution. Instrumentation also includes other activities such as modifications for fault tolerance, e.g., checkpointing, and fault injection. Instrumentation thus typically involves some modification of a target program to alter or add functionality. For example, instrumentation code may be used to provide indications as to whether or not particular branches are taken when a program is executed with a given set of inputs, or to interrupt a processor during execution in order to aid in fault location. Existing software instrumentation methods can be broadly categorized as static methods and dynamic methods.
Static methods modify program code before the start of code execution, while dynamic methods delay modifications until the program is loaded into memory. Static software instrumentation involves the direct modification of code and can be performed at various stages of code development. One very common form of instrumentation is the use of the cpp C-language preprocessor, which performs automatic source code instrumentation. Other examples of source code instrumentation tools include the FAUST fault injection tool, as described in B.-H. Suh et al., “FAUST—fault injection based automated software testing,” Proccedings of the 1991 Systems Design Synthesis Technology Workshop, Silver Spring, Md., September 1991, and the Motlira software mutation testing tool, as described in B. J. Choi et al., “The mothra tools set,” Proceedings of the 22nd Hawaii International Conference on Systems and Software, pages 275-284, Kona, Hi., January 1989.
Static instrumentation can also be performed on assembly code. Optimizers embedded in compiler backends are an example of assembly code instrumentation. Perhaps the most easily recognizable form of static software instrumentation is performed on binary code. Tools such as the pixie profiling tool described in “RISCompiler and C Programmer's Guide,” Computer Systems, Inc., 930 Arques Ave., Sunnyvale, Calif. 94086, 1986, and the FIAT fault injection tool described in J. H. Barton et al., “Fault injection experiments using FIAT,” IEEE Transactions on Computers, 39(4):575-582, April 1990, directly modify the executable image of their target applications. Other tools, such as the libft checkpointing tool described in Y. Huang and C. Kintala, “Software fault tolerance in the application layer,” Software Fault Tolerance, Michael Lyu, ed., ch. 10, Wiley, 1995, incorporate additional code into the original code by linking the original code with new libraries or object code files. In fact, the process of linking object files may also be viewed as a form of software instrumentation, because the object files themselves are modified to create a single executable program.
As noted above, dynamic software instrumentation methods, in contrast to static methods, do not perform any modifications until the program has been loaded into memory. As the program executes, the instrumentation code is executed in parallel, either as a separate process or thread, or as in-lined code. This instrumentation code allows the program's dynamic state to be observed and modified. A number of different dynamic instrumentation methods exist. The environment external to the program can be modified, as with the 3-D file system described in G. S. Fowler et al., “A user-level replicated file system,” USENIX Conference Proceedings, pages 279-290, Cincinnati, Ohio, Summer 1993. The operating system can be directly modified, as with the FTAPE fault injection tool described in T. K. Tsai et al., “An approach towards benchmarking of fault-tolerant commercial systems,” Proceedings of the 26th International Symposium on Fault-Tolerant Computing, pages 314-323, Sendai, Japan, June 1996, or the state of the operating system or system calls can be monitored, as with the UNIX strace utility. The process of linking dynamic shared libraries can be modified to substitute alternate instrumented libraries, such as with the REPL file duplication software described in the above-cited Y. Huang and C. Kintala reference. Finally, the execution of the program can be directly controlled via a software controller with the ability to selectively interrupt the program and execute instrumentation code, as in the FERRARI fault injection tool described in G. A. Kanawati et al., “FERRARI: A flexible software-based fault and error injection system,” IEEE Transactions on Computers, 44(2):248-260, February 1995.
The conventional static and dynamic instrumentation techniques described above have a number of drawbacks. For example, many of the techniques are implemented in a “direct” manner, i.e., in a manner which requires changes to either source code or executable code of an instrumented target program. This unduly increases the complexity of the instrumentation process, is unsuitable for use with certain types of target programs, and fails to provide adequate support for many increasingly important distributed computing applications. Other techniques, such as the above-noted FERRARI fault injection tool, are hard-coded to provide only certain specific types of instrumentation.
SUMMARY OF THE INVENTION
The invention provides a general-purpose software instrumentation technique, referred to as “indirect instrumentation,” in which execution of a target program is directed by a controller. The controller operates in conjunction with other processes and/or threads to instrument the target program by executing user-specified actions upon occurrence of user-specified trigger events. Advantageously, the invention can provide any desired type of instrumentation on any target program, and without modification of the source code or executable code of the target program. An illustrative embodiment of the invention is in the form of an instrumentation tool that includes a frontend portion and a backend portion. The frontend and backend portions of the tool may each be running on a different machine, or alternatively both portions may run on the same machine. The frontend portion includes a creation graphical user interface (GUI) which allows a user to graphically design a created GUI with customized instrumentation operations tailored to a given target program. The frontend portion may be implemented in, for example, Java, and executed in any Java-enabled web browser. The backend portion, which may be implemented in C++, controls the execution of the target program in accordance with user-specified actions and other instrumentation functions. The frontend and backend communicate over a communication medium which may utilize conventional TCP/IP messaging.
In accordance with the invention, a given target program is instrumented by controlling its execution and implementing user-specified actions in response to user-specified trigger events which occur during target program execution. The user-specified actions and events may be specified in the creation GUI of the above-noted frontend portion. A controller directing the execution of the target program operates in conjunction with a number of other processes and/or threads to execute the user-specified instrumentation actions upon occurrence of the designated trigger events. The controller and these other processes and/or threads may be elements of the above-noted backend portion. Information regarding the user-specified actions and triggers is communicated from the user interface of the frontend portion to the controller and other processes and/or threads of the backend portion, and is used to provide the desired inst Lamentation without modification of target program code. The processes and/or threads may also be use

Affiliated with

Also associated with

Rating

Distributed indirect software instrumentation does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Distributed indirect software instrumentation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Distributed indirect software instrumentation will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2474258