System and method for trace verification

[0002] The present invention relates in general to data processing systems, and in particular, to programming for data processing systems.

[0003] Today's real-world computing environments consist of many different and often incompatible hardware systems, operating systems and product versions running on client/server networks. As a result, Management Information Systems (MIS) professionals face daunting obstacles in deploying, updating and maintaining applications on all the clients and servers across their enterprises. JavaOS has been designed to help overcome these obstacles.

[0004] JavaOS is a software platform that enables Java applications to run directly on hardware without requiring a host operating system. JavaOS includes the Java Virtual Machine, the standard packages of classes, and enough operating system (“OS”) code to support them. The OS code includes low-level code written in C or assembly language, plus device driver, networking, windowing, and graphics-rendering code mostly written in the Java programming language.

[0005] One application for JavaOS is to run Java programs on a variety of computing and consumer platforms. JavaOS is an operating system programmed as an object. JavaOS has been designed specifically to support Java and Java applets without having to provide backward compatibility with other legacy applications. This approach improves performance by eliminating needless layers of software and enabling the operating system to run in minimal memory configurations.

[0006] Despite all the advantages of JavaOS, there still is a need to analyze or debug programs generated in JavaOS. As with other program execution environments, one of the most common methods for debugging a program is to implement a trace program. Trace files generated from a JavaOS client are often analyzed using information that is available from the build image containing symbolic data regarding the C and the similar functions in the Java classes and their methods. The symbolic image is stripped in order to have the client load a small image. The problem is that there is an exposure for the end-user to use the wrong symbolic image with the generated trace file and thereby receive incorrect results. A variation of this problem occurs when a trace file is available and a user is not confident against which image the trace was generated.

[0007] The present invention addresses the foregoing need by ensuring that the trace file is analyzed using the correct symbolic image. This is implemented by generating a date/time stamp as part of the build process to be used to validate that the trace file and the symbolic image correspond to each other.

[0008] In one embodiment of the present invention, a build identifier is updated with an updated date/time stamp and version number. The process then builds the program to be traced and the build identifier is placed into the symbol file. The object code of the program is then installed into a designated machine. A trace is initiated against this program collecting data regarding specified events occurring within the program. The build identifier is captured and placed into the raw file produced by the trace program. A comparison is then made between the build identifier in the raw file and the build identifier within the symbol file. If there is a match, post-processing of the trace data is continued.

[0009] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention.

[0010] The present invention is applicable to any situation where data collected from an executing system (or object) image needs to be compared to a static copy of that same image.

[0011] For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

[0012] FIG. 1 illustrates a data processing system configured in accordance with the present invention; and

[0013] FIG. 2 illustrates a flow diagram configured in accordance with the present invention and operable for running on the data processing system illustrated in FIG. 1.

[0014] In the following description, numerous specific details are set forth to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art that the present invention may be practiced without such specific details. In other instances, well-known circuits have been shown in block diagram form in order not to obscure the present invention in unnecessary detail. For the most part, details concerning timing considerations and the like have been omitted inasmuch as such details are not necessary to obtain a complete understanding of the present invention and are within the skills of persons of ordinary skill in the relevant art.

[0015] Refer now to the drawings wherein depicted elements are not necessarily shown to scale and wherein like or similar elements are designated by the same reference numeral through the several views.

[0016] Referring first to FIG. 1, an example is shown of a data processing system 100 which may be used for running the method of the invention. The system 100 has a central processing unit (CPU) 110 coupled to various other components by system bus 112. Read only memory (“ROM”) 116 is coupled to the system bus 112 and includes a basic input/output system (“BIOS”) that controls certain basic functions of the data processing system 100. Random access memory (“RAM”) 114, I/O adapter 118, and communications adapter 134 are also coupled to the system bus 112. I/O adapter 118 may be a small computer system interface (“SCSI”) adapter that communicates with a disk storage device 120. Communications adapter 134 interconnects bus 112 with an outside network enabling the data processing system to communication with other such systems. For example, various components, or steps, of the present invention may be run on separate machines coupled together in a network.

[0017] Input/Output devices are also connected to system bus 112 via user interface adapter 122 and display adapter 136. Keyboard 124 and mouse 126 are interconnected to bus 112 via user interface adapter 122. Display monitor 138 is connected to system bus 112 by display adapter 136. In this manner, a user is capable of inputting to the system throughout the keyboard 124 or mouse 126 and receiving output from the system via display 138.

[0018] Preferred implementations of the invention include implementations as a computer system programmed to execute the method or methods described herein, and as a computer program product. According to the computer system implementation, sets of instructions for executing the method or methods are resident in the random access memory 114 of one or more computer systems configured generally as described above. Until required by the computer system, the set of instructions may be stored as a computer program product in another computer memory, for example, in disk drive 120 (which may include a removable memory such as an optical disk or floppy disk for eventual use in the disk drive 120). Further, the computer program product can also be stored at another computer and transmitted when desired to the user's workstation by a network or by an external network such as the Internet. One skilled in the art would appreciate that the physical storage of the sets of instructions physically changes the medium upon which it is stored so that the medium carries computer readable information. The change may be electrical, magnetic, chemical or some other physical change. While it is convenient to describe the invention in terms of instructions, symbols, characters, or the like, the reader should remember that all of these and similar terms should be associated with the appropriate physical elements.

[0019] Note that the invention may describe terms such as comparing, validating, selecting, identifying, or other terms that could be associated with a human operator. However, for at least a number of the operations described herein which form part of at least one of the embodiments, no action by a human operator is desirable. The operations described are, in large part, machine operations processing electrical signals to generate other electrical signals.

[0020] When a trace program is applied to the operation of an object, the trace program is searching for the occurrences of certain events. Upon the occurrence of these events, data is output, which may include a state of the program at the occurrence of each such event, and the address of the instruction at the time of the occurrence of the event. This trace data is then outputted as raw data into a trace file (also referred to herein as a “raw file”). Post-processing of the raw file is then performed in a manner specified by the programmer of the trace program.

[0021] However, the present invention is not dependent upon a trace being performed, but is also applicable to any situation where data is collected from an executing object or image, and then possibly later manipulated.

[0022] In JavaOS, during the build process after the program is compiled, the modules within the program are linked. Furthermore, a map, or symbol file (also referred to herein as a “symbolic file” or “symbolic image”), is produced that indicates where functions are located by their addresses (memory locations) and, optionally, the length they occupy within memory. The symbols essentially are the file names of the functions within the program. This build process creates an image of the entire JavaOS image (program), which can be downloaded and run on the appropriate computer hardware. Other programs can be built in a similar manner. The resolution of linkages between subroutines may be done at build time or at load time, that is, when the application is being run.

[0023] Note, the present invention is not limited to a symbolic image, but is applicable to any static copy of the image.

[0024] It is often desired to analyze the trace file (collected data) with the symbolic image (static image). The trace file contains addresses of modules and program counters used to identify a position within a module. The symbolic information is used by the trace analyzer program to convert the physical addresses to symbolic names, which are understandable by humans. However, as briefly noted above, there is a risk that the wrong symbolic image will be used to analyze the trace file. The present invention ensures that the symbolic file corresponds to the trace file. This is performed by including a date/time stamp within both the symbolic file and the trace file.

[0025] Referring to FIG. 2, during the build process, the Build Identifier will be updated with a date/time stamp and a version number, which is incremented each time a new build is produced, resulting in a unique Build Identifier. In step 202, the program (object) is built. In step 203, the Build Identifier is inserted into the produced symbol file. In step 204, the object code pertaining to the program is installed into a designated machine (server), which is also referred to as the loading or copying of the image (object) to the designated machine. In step 205, the desired trace program is initiated against this image (object). The trace is a programmable operation collecting data regarding events occurring in the program. In step 206, the previously updated Build Identifier is captured and inserted into the trace file produced by step 205. The trace data may be collected into a buffer or raw file. A separate BIF (Build Identifier File) may be used to contain the build identifier. This file is read into RAM, the version number is incremented, and the current time is captured. The file is written back to disk with the new information. The data from this file is copied to the symbol file in a designated position, preferably the front of the file. A copy to the beginning may be performed by writing a temporary file with the build information, followed by the symbolic map information and then copied over the file with just the map information. Also, during the build process, the string data representing the build identifier is linked into the build image.

[0026] Thereafter, in step 207, a post-processor program is initiated whereby the Build Identifiers within the raw file and the symbol file are compared. The raw file's header is updated with the build identifier by involving a subroutine during trace initiation that returns the build identifier string. In step 208, if the Build Identifiers match, then the process proceeds to step 209 to continue with post-processing of the trace file. However, if the Build Identifiers do not match, then another step may be performed, such as step 210 where an error message is returned to the user.

[0027] The present invention has been described above with respect to JavaOS, which is a single object. However, the present invention is also applicable to other systems having many objects, whereby the principles of the present invention are applied to a multiple of sub-systems.

[0028] The present invention has been described above with specific reference to trace. Trace is typically implemented as a time serial recording of events, subsequently post-processed by a trace analyzer. However, the present invention is also applicable to any situation involving the manipulation of data collected from an executing system (or object) image whose analysis has dependencies on additional data which is to be obtained from a static copy of that same image.

[0029] Although the present invention and its advantages have been described in detail, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.