Intelligently interpreting errors in build output log files

Details Intelligently interpreting errors in build output log files Intelligently interpreting errors in build output log files

1998-12-18

2002-02-05

Lee, Thomas (Department: 2182)

Electrical computers and digital data processing systems: input/

Input/output data processing

Input/output access regulation

C714S030000, C714S036000, C714S037000, C707S793000

Reexamination Certificate

active

06345322

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to an improved method of developing software algorithms for a data processing system, and in particular to provide such an improved method of developing software algorithms for a data processing system by identifying errors within the software algorithm. Still more particularly, the present invention relates to an improved method of developing a software algorithm by identifying errors generated during a build of the software algorithm wherein predefined error conditions are ignored.
2. Description of the Related Art
A generalized structure for a conventional computer system includes one or more processing units connected to a system memory device (random access memory or RAM) and to various peripheral, or input/output (I/O) devices. The I/O devices typically include a display monitor, a keyboard, a graphical pointer (mouse), and a permanent storage device (hard disk). The system memory device is utilized by a processing unit in carrying out program instructions, and stores those instructions as well as data values that are fed to or generated by the programs. A processing unit communicates with the other components by various means, including one or more interconnects (buses), or direct access channels. A computer system may have many additional components, such as serial and parallel ports for connection to, e.g., printers, and network adapters. Other components might further be utilized in conjunction with the foregoing; for example, a display adapter might be utilized to control a video display monitor, and a memory controller can be utilized to access the system memory, etc.
With reference now to the figures, and in particular with reference to
FIG. 1
, the basic structure of a conventional data processing system
10
is depicted. Data processing system
10
has at least one central processing unit (CPU) or processor
12
which is connected to several peripheral devices, including input/output devices
14
(such as a display monitor, keyboard, and graphical pointing device) for the user interface, a permanent memory device
16
(such as a hard disk) for storing the data processor's operating system and user programs, and a temporary memory device
18
(such as random access memory or RAM) that is utilized by processor
12
to carry out program instructions. Processor
12
communicates with the peripheral devices by various means, including a bus
20
or a direct channel
22
(more than one bus may be provided utilizing a bus bridge).
Data processing system
10
may have many additional components which are not shown such as serial, parallel, and USB ports for connection to, e.g., modems or printers. Those skilled in the art will further appreciate that there are other components that might be utilized in conjunction with those shown in the block diagram of
FIG. 1
; for example, a display adapter connected to processor
12
might be utilized to control a video display monitor, and a memory controller may be utilized as an interface between temporary memory device
18
and processor
12
. Data processing system
10
also includes firmware
24
whose primary purpose is to seek out and load an operating system from one of the peripherals (usually permanent memory device
16
) whenever data processing system
10
is first turned on.
The operation of data processing systems of the type depicted in
FIG. 1
is well known in the art. Program information comprising instructions and/or data is stored on permanent memory device
16
and may be selectively copied into temporary memory device
18
once data processing system
10
is powered on. Processor
12
executes the instructions within such program information and generates text or graphical information for presentation on display output device connected via graphics adapter, where the information may be viewed by a user. The user may selectively control operation of data processing system
10
through input entered on one of input/output devices
14
.
A software algorithm is accordingly a set of program instructions which are adapted to perform certain functions by acting upon, or in response to, the I/O devices. Program instructions that are carried out by the processor are, at that lowest level, binary in form, i.e., a series of ones and zeros. These executable (machine-readable) program instructions are produced from higher-level instructions written in a programming language. The programming language may still be low-level such as assembly language (which is difficult to use since instructions appear as hexadecimal bytes), or may be a higher level language in which instructions are created utilizing more easily understood words and symbols. During the development stage of a software algorithm, a programmer creates a series of lines of code. This code is usually completed in text format. To enable the code to be utilized within a data processing system, the code must first be converted into a format which can be understood/interpreted by the data processing system. The process for converting the code into “machine readable code” is known as compilation. Compilation is the process of translating a source program into an executable program or object code. Object code is executable machine code or a variation of machine code. During compilation, a program expressed in a high-level language is translated into a computer program or machine language program expressed in intermediate language, an assembly language, or a machine language.
Software build is a process of creating a configuration file for execution of a software algorithm. This build process usually coincides with the compilation step in program development. During the build process, a log file is generated in which elements related to the success of the build are stored. Among these elements are errors, error conditions and error strings (collectively called errors). These errors may be fatal/serious errors (true errors) or non fatal/serious errors (ignorable errors). Some of these errors are common for every software build. A list of these common errors is known by those skilled in the art and include, for example, “error” and “fatal”. Errors in ASCII files are usually defined as strings within the file when it is compiled. The success of a software build may be determined by searching the generated log file for a series of known error conditions or user defined error strings.
Searching for these errors is traditionally done utilizing search engines such as global regular expression print (Grep) or SCAN. These search engines produce matches based on a character string analysis. Grep is a standard UNIX based search tool which looks inside files and searches for a series of characters/strings. Every time it finds a line that contains the specified characters, it displays the line on screen. If it is looking in more than one file, it also tells the name of the file in which the characters occur. The user controls which files to look in and which characters to look for. Grep also distinguishes between uppercase and lowercase letters and can be run in the background.
The grep command is utilized primarily to find one or more files which contain a known string when the name of the file containing the information is unknown. It can be utilized to check all the files in a directory or a single file. Recent applications of grep include being utilized by software developers to search for known error conditions in build files.
In searching build files, grep and other traditional search tools, typically produce all potentially relevant “hits” but leave it up to the builder to determine which ones are real and what can be ignored. For example, a common error log search is for OS/2 system errors such as “SYS“xxxx”, like:
SYS0002: The system cannot find the file specified.
Unfortunately, many builds have MAKEFILEs that attempt to delete files that don't exist, creating output such as this:
erase bob.obj
SYS0002: The system cannot find the file specified. This type of error is generally ignored

Affiliated with

Also associated with

Rating

Intelligently interpreting errors in build output log files does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Intelligently interpreting errors in build output log files, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Intelligently interpreting errors in build output log files will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2973924