Error detection/correction and fault detection/recovery – Data processing system error or fault handling – Reliability and availability
Reexamination Certificate
1994-11-28
2001-03-13
Le, Dieu-Minh T. (Department: 2184)
Error detection/correction and fault detection/recovery
Data processing system error or fault handling
Reliability and availability
C714S025000
Reexamination Certificate
active
06202173
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to fault location in software.
2. Related Art
Fault location and analysis is an important aspect of writing software. It is extremely difficult to create a program or system of any complexity which has no faults or errors. These may not appear when the software is first run but at some later time when a particular set of circumstances arises and an expected result is not achieved. A program might crash or there might be total system failure.
SUMMARY OF THE INVENTION
Clearly, it is important to analyse what went wrong so that it can be corrected, and this analysis can be done in more than one way. For instance, fault checking can be done as a “post mortem” exercise, an operating system being designed automatically to copy memory onto disk when the software fails. The data stored at the time of failure then provides a “snap shot” of the prevailing circumstances from which an attempt can be made to find out what caused the failure. Alternatively, dedicated debugging software can be written into the main software such that when compiled after a system failure, and run under the debugging software, a faulty program or piece of software can be stopped, allowing a problem to be pinpointed perhaps at an earlier stage.
In use, there are disadvantages with each of these types of fault checking system. With the post mortem type, it is only possible to look at a snapshot of information at the time the system goes down. This may not be sufficient for fault analysis. In taking the alternative approach and using specially created debugging software, however, the extra software can make a major contribution to the size of a system overall. It is necessary for the debugger to know where the relevant variables are in memory. This type of debugger is therefore expensive in that the program incorporating it becomes much larger, and there is a big expense in memory in having to flag where the variables are located. Further, although the debugger is more flexible in that it is possible to re-run the program, it still can only be re-run in one direction. This is a significant limitation particularly in big systems since re-running whole programs can be unwieldy and time-consuming.
An object of the present invention is to provide a system or arrangement for fault location in software which is not particularly expensive in terms of memory or software complexity but which gives more information about events leading up to a system problem than simply data at the time of system failure.
According to the present invention, there is provided an arrangement for locating faults in software which comprises means for storing multiple values for each of one or more data variables during running of said software, and means for accessing the values stored thereby for review.
Preferably, said means for accessing is adapted to review the values stored in an order which can be selected from either a forward or a backward order with respect either to their storage locations or to their chronological occurrence.
Hence, an embodiment of the present invention may create a “history file” during running of software in which are stored the values relevant to each of a number of variables over a period of time, which values can then be reviewed, for instance on system failure, in a forward or backward chronological direction, in the manner of viewing a video-tape. Preferably, a search facility is also provided.
Embodiments of the present invention can be particularly useful in software which provides flow chart coding from a screen. This is a known technique by means of which a user creates an end program by selecting a combination of flow chart elements from a screen, configuring them to provide the end software function required. Known flow chart coding systems, that automatically generate code from graphical symbols selected and shown on the screen, provide program execution tracing information referencing the generated code. This is typically line number in a textual generated language code. The process of correlating the information to the graphical symbol level is then manual. Embodiments of the present invention can have a major advantage if the program execution tracing information is tied directly with the graphical symbols selected and shown on the screen.
A method for fault location in software according to an embodiment of the present invention might comprise the steps of
1. storing consecutive or sampled values for each of one or more variables during running of the software, in a memory or allocated portion of memory, and;
2. in the event of detection of a fault in the running of the software, displaying said values for review.
The values may be displayed sequentially, in a forwards or backwards direction with respect to their relative storage locations in said memory, or with respect to their chronological order of storage in said memory. In particularly advantageous embodiments of the present invention, the values are displayed on a screen simultaneously with a flow chart display which had been generated during a flow chart coding process in which the relevant fault occurred, the graphical symbol from the display which is relevant to each set of values being identifiable. For instance, said values may be displayed in a banner or footnote, together with the flow chart displaying the relevant symbol from the flow chart being highlighted.
Where the values are displayed sequentially, a predetermined interval can be set during which values for each selected box or graphical symbol are shown, followed by values for the next box or graphical symbol. This provides a form of “animation” of the values which makes the debugger particularly easy to use, and to learn to use.
REFERENCES:
patent: 4730315 (1988-03-01), Saito
patent: 4872167 (1989-10-01), Maezawa
patent: 4943968 (1990-07-01), Hirose
patent: 4956773 (1990-09-01), Saito
patent: 5210859 (1993-05-01), Aoshima
patent: 5287449 (1994-02-01), Kojima
patent: 5375125 (1994-12-01), Oshima
patent: 0439342 (1991-07-01), None
Corsin: et al., Multibug: Interactive Debugging in Distributed Systems, IEEE Micro, vol. 6, No. 3, Jun. 1986, pp. 26-33.
Bemmerl et al., Menu and Graphic Driven Human Interfaces for High Level Debuggers, Microprocessing and Microprogramming, vol. 24, Aug. 1988, pp. 153-159.
Moser, GADD—A Tool for Graphical Animated Design and Debugging, IEEE Conf. on Communications, vol. 3, Jun. 10, 1987, pp. 1337-1341.
Davidson Colin Stirling
Hollett Raymond Michael
British Telecommunications public limited company
Le Dieu-Minh T.
Nixon & Vanderhye P.C.
LandOfFree
Software fault location does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Software fault location, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Software fault location will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2460222