1. Technical Field
The present invention relates in general to the field of data processing systems, and more specifically, the field of tracing program flows utilizing a data processing system.
2. Description of the Related Art
Tracing is an important part of software development. Conventional tracing allows an application programmer or user to analyze the flow of data through the processing logic of the software. In particular, tracing statements may be added to the program source code to indicate the status of variables and other indicators at the entry and exit of a function. Tracing may also indicate the status of variables when an exception occurs. By including tracing options in a product, the product offers an increased level of serviceability to its customers.
There are two general, conventional approaches to trace statement insertion. First, there is the manual approach, which involves going through source code and manually inserting trace statements. Second, there are trace statement insertion programs that facilitate the insertion of trace statements into source code.
Manual insertion of entry, exit, and exception trace statements typically requires significant time and effort on the part of the programmer. Even with the use of tools to aid in the process (for example, the Eclipse/Websphere Application Developer (WSAD) Reusable Asset (RAS) plug-in, in the case of Java code), manual insertion of trace statements required a significant amount of developmental time and effort, and is also subject to human error. Manual trace statement insertion allows, for example, misspelled function or method names and overlooked classes. Minor mistakes can significantly impact product serviceability. Manual trace statement insertion also requires substantial code management and maintenance. Changes in function names or the addition of new functions makes it difficult to track the portions of the program code that include trace statements and the extent to which the trace statements are implemented. Manual trace statement insertion generates undesirable clutter in the source code. Also, the addition of trace statements increases the size of the source code and increases the difficulty of later review of the source code, if necessary.
To manage the insertion of trace statements, it is well-known in the art that there are trace statement insertion programs that facilitate the insertion of trace statements by looking for keywords in the program code that often trigger the insertion of a trace statement. Once the trace statements (hereinafter referred to as “trace points”) are inserted into the source code, there is a need for a system and method for managing the trace points. Since each trace point consumes system resources, it is important that the utilization of trace points is monitored. Therefore, due to the limitations of the prior art, there is a need to intelligently, yet automatically, enable trace points on a running data processing system when information about a particular application under debug is limited.
The present invention includes a system and method for controlling trace points utilizing source code directory structures. According to an embodiment of the present invention, a debug engine sets a debug level to a default debug level for an application to be debugged, wherein said application includes a collection of files organized within a collection of directories. A debug utility creates a set of trace point selections by selecting at least one file among the plurality of files in the first directory for debug when a first directory among the collection of directories is evaluated. The debug utility enables at least one trace point within the at least one file. The debug engine debugs the application according to the set of trace point selections and the debug level selected.
After the debug engine debugs the application, the debug results are presented via the debug utility to enable trace point selection optimization. If the trace point selections are optimized, the debug utility sends the optimized trace point selections back to the debug engine for debug processing.
The above, as well as additional purposes, features, and advantages of the present invention will become apparent in the following detailed written description.
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further purposes and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying figures, wherein:
The present invention includes a system and method for controlling trace points utilizing source code directory structures. According to an embodiment of the present invention, a debug engine sets a default debug level for an application or kernel to be debugged. A debug utility sends debug parameters to define a scope for the debug engine to perform the debug operation, which may be performed at a directory-level, individual file-level, or individual trace point-level. Once the debug operation is performed, the results of the debug operation are presented to a user.
Referring to the figures, and more particularly, referring now to
Those skilled in the art will appreciate that data processing system 100 can include many additional components not specifically illustrated in
As illustrated, operating system 202 also includes kernel 206, which provides lower levels of functionality for operating system 202, including providing essential services required by other parts of operating system 202 and application programs 208, including memory management, process and task management, disk management, and mouse and keyboard management. Application programs 208 can include a browser, utilized for access to the Internet, word processors, spreadsheets, and other application programs. Also, as depicted, system memory 106 includes a debug engine 210 and debug utility 212, which interfaces with kernel 206 or a program within application programs 208 for controlling trace points utilizing source code directory structures, in accordance with an embodiment of the present invention.
As discussed herein in more detail, the relationship between application programs 208, debug engine 210, and debug utility 212 is as follows. Debug utility 212 acts as an interface to debug engine 210, which enables a user to activate or deactivate trace points within kernel 206 or an application program 208. Generally, debug utility 212 generates a collection of selection menus (
Since application programs 208 and kernel 206 are preferably organized in a file system, debug engine 210 enables a user to specify files, directories, or entire programs in which trace points are activated or deactivated. An example of a trace point (for example, in the C programming language) would be a “print” statement that the user or software developer to determine the current value of a certain variable during program execution. Examples of trace points are shown in
Generally, debug utility 212 presents a collection of selection menus to enable a user to adjust the scope of the application or kernel debug function, depending on a set of preferences. The first selection identifies the application or kernel that will be the target of the debug operation (
Next, a selection is made to determine whether the debug function will be carried out utilizing a generalized debug setting or a customized setting (
If the user selects the “customized debug” option, debug utility 212 presents a customized debug selection menu 308 (
If the user has selected the “individual trace point” option, debug utility 212 enables the user to enable or disable specific trace points within the files of the application or kernel selected for a debug operation (
One debug engine 210 has completed the trace point processing, debug utility 212 receives the results. The results of the processing (shown as log entries) can be sorted by trace point or by the number of occurrences (
Referring back to
General debug selection menu 306 includes a collection of debug levels controlled by a system log utility (e.g., syslog in Linux). The system log utility logs system messages, including messages generated by trace points within applications 208 or kernel 206 according to a set of predetermined rules. The predetermined rules include a priority field (e.g., debug, info, notice, warning, warn, err, error, crit, alert, emerg, panic, etc.) that defines the severity of the particular system message. The system log utility logs all messages of a certain priority or higher. The debug levels are tied to the priority fields so that the system messages are logged by the system log utility depending on the particular priority setting of a system message. Generally, the higher the selected debug level, the more trace points are enabled for monitoring in the selected application 208 or kernel 206.
Once debug utility 212 has received a selection from debug level selection menu 306, the process continues to step 410, which illustrates debug utility 212 sending the selected general debug level to debug engine 210 for processing. The process continues to step 442, which will be discussed herein in more detail.
Returning to step 404, if “customized debug” is selected (step 412), the process continues to step 414, which depicts debug utility 212 displaying a customized debug selection menu 308 (
If debug utility 212 receives, via customized debug level selection menu 308, a selection of “directories”, the process continues to step 424, which shows debug utility 212 (via directory selection menu 310 in
Once the user has selected the directories for debug, debug utility 212 will prompt the user to select a generalized debug level to apply to the selected directories (via general debug level selection menu 306), as illustrated in step 430. For example, a user may want to only debug the files located in the directory “my_application1/io” at a “notice” generalized debug level. Once the user has selected the desired generalized debug level, debug utility 212 sends the selected generalized debug level to debug engine 210, as depicted in step 432. Then, the process continues to step 442, which will be discussed herein in more detail.
Returning to step 416, if debug utility receives, via customized debug level selection menu 308, a selection of “individual files”, the process continues to step 434, which depicts debug utility 212 (via file selection menu 312 in
Once the user has selected the files for debug, debug utility 212 will prompted the user to select a generalized debug level to apply to the selected files (via general debug level selection menu 306), as illustrated in step 430. For example, a user may want to only debug files “my_application1/main.c” and “my_application1/io/keyboard_io.c” at a “notice” generalized debug level. Once the user has selected the desired generalized debug level, debug utility 212 sends the selected generalized debug level to debug engine 210, as depicted in step 432. Then, the process continues to step 442, which will be discussed herein in more detail.
Returning to step 416, if debug utility 212 receives, via customized debug level selection menu 308, a selection of “individual trace points”, the process continues to step 418, which illustrates debug utility 212 (via file selection menu 314 in
After debug engine 210 completes the trace point processing based on the trace point selections sent in step 422, the process continues to step 442, which illustrates debug utility 212 receiving the debug results from debug engine 210. The process proceeds to step 444, which depicts debug utility 212 presenting the debug results from debug engine 210, as shown in
The user can also optimize the trace point selections by selecting/deselecting trace points based on their number of occurrences, as illustrated in step 446. For example, a log in the results such as “dc390_freeDCBs”, which generated 1884 results, may be considered a “noisy result”. In future trace point processing, the user may want to deactivate “dc390_freeDCBs” to prevent cluttering the results. Also, if a particular log in the results include multiple individual trace points, the user may select/deselect the individual trace points via trace point selection menu 324. Trace point selection menu 324 may be reached by selecting a particular log entry in result log menu 322.
If debug utility 212 receives a command to not sort the results and optimize trace point selections, the process proceeds to step 450, which illustrates the process ending. If debug utility 212 receives a command to sort the results and optimize trace point selections, the sorting and optimization is performed. The optimized trace point selections are sent back the debug engine 210 for further processing, as depicted in step 448. The process then returns to step 442 and proceeds in an iterative fashion.
If the current trace point is registered with debug engine 210, the process continues to step 506, which depicts debug engine 210 enabling each trace point in the file to be handled as specified by debug database 210. The process then continues to step 514, which illustrates debug engine 210 processing each trace point, based on the settings in debug database 320.
The process proceeds to step 516, which depicts debug engine 210 determining if there are any more trace points to process. If there are more trace points to process, the process returns to step 504 and proceeds in an iterative fashion. If there are no more trace points to process, the process continues to step 518, which illustrates debug engine 210 presenting the results of the debug operation via a variety of methods, including, but not limited to: (1) a results screen (e.g., results log menu 302 in
Returning to step 504, if the current trace point is not registered with debug engine 210, which illustrates debug engine 210 determining whether or not debug is set to “on” (or whether the trace point is active). If debug is set to “on”, as depicted in step 508, the process continues to step 510, which illustrates debug engine 210 deactivating the trace point (forcing the debug to “off” for the particular trace point). The process then continues to step 514. If the debug not set to “on”, the process continues to step 514. The debug value (set to “on” or “off”) is a default debug value established in step 406 and 432, where a generalized debug level is selected by the user. If the individually configured debug setting for a particular trace point is unknown, the default value is the debug value established in the generalized debug level selection in steps 406 and 432.
As discussed, the present invention includes a system and method for controlling trace points utilizing source code directory structures. According to an embodiment of the present invention, a debug engine sets a debug level to a default debug level for an application to be debugged, wherein said application includes a collection of files organized within a collection of directories. A debug utility creates a set of trace point selections by selecting at least one file among the plurality of files in the first directory for debug when a first directory among the collection of directories is evaluated. The debug utility enables at least one trace point within the at least one file. The debug engine debugs the application according to the set of trace point selections and the debug level selected.
It should be understood that at least some aspects of the present invention may alternatively be implemented as a program product. Program code defining functions in the present invention can be delivered to a data storage system or a computer system via a variety of signal-bearing media, which include, without limitation, non-writable storage media (e.g., CD-ROM), writable storage media (e.g., hard disk drive, read/write CD-ROM, optical media), system memory such as, but not limited to Random Access Memory (RAM), and communication media, such as computer and telephone networks including Ethernet, the Internet, wireless networks, and like network systems. It should be understood, therefore, that such signal-bearing media when carrying or encoding computer-readable instructions that direct method functions in the present invention represent alternative embodiments of the present invention. Further, it is understood that the present invention may be implemented by a system having means in the form of hardware, software, or a combination of software and hardware as described herein or their equivalent.
While the present invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.