Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1998-07-22
2001-07-31
Chaki, Kakali (Department: 2183)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
C714S015000, C714S047300, C714S051000
Reexamination Certificate
active
06269478
ABSTRACT:
BACKGROUND OF THE INVENTION
The present invention is directed to a monitoring method for recognizing software errors with which endless loops and/or blocked processes can be detected in a computer system and removed if necessary. In particular, detection of software errors in telecommunication switching systems is to be enabled.
Many software errors are recognized by the application software or by the hardware itself, e.g. due to plausibilization at interfaces, division by zero, memory access violation, etc. However, there are also software errors that do not fall into these categories of error, and thus regularly remain unrecognized. Such errors can have considerable consequences in the system, and can even lead to complete system blockages. However, in the earlier handling of such errors these negative effects can be avoided, or at least minimized.
SUMMARY OF THE INVENTION
It is an object of the present invention to provide a monitoring method with which software errors recognized neither by the respective application nor by the hardware can reliably be recognized.
With the inventive monitoring method, in particular endless software loops, and, if necessary, also blocked user processes, can be detected effectively and early, so that suitable countermeasures can be taken.
In general, for each deselection of a process an operating system scheduler (program) determines the runtime thereof, and compares this with a runtime limit value that is predetermined specifically for this process. If the runtime is higher than the predetermined runtime boundary value, a corresponding message is sent to the monitoring method. In a preferred construction, the monitoring method checks whether an earlier message relating to this process is already present, i.e., whether the process has already at some point exceeded the runtime limit. The first error message is thus not signaled through immediately as an endless loop; rather, at first only the possibility of an error is inferred.
A verification of the error preferably takes place with the aid of task counters, whereby the scheduler for each process maintains a specific counter that indicates whether a new task is being executed by the process. At the beginning of each new task, i.e., after a time delay has taken place, this task counter is increased. If a process is signaled for the first time, the inventive monitoring method calls this counter value, which stands for the corresponding process in the task counter, and stores it in a process control block (PCB), preferably in a field used only by the monitoring method. By means of comparison of the count state stored in the first message with the current count state of the task counter, the monitoring method can verify the error. That is, if it is determined that the process is still working on the same task, the error is considered verified, and an endless loop is inferred. Indices are then collected for the unambiguous identification of the error, and a corresponding corrective measure is introduced. In all other cases, the items of information required for the later verification of an error are stored in the process control block of the signaled process. This yields the advantage that an expensive data management within the monitoring process itself is avoided, since all data required for the monitoring are stored in the process control block of the respective process. These data are also supplied given a respective call of the monitoring method by the scheduler, so that no operating system calls are required in order to achieve what are known as snapshots.
Preferably, the monitoring program is also periodically cued by a higher-priority hardware timer, so that all programs running at a lower interrupt level are monitored. Dependent on the function to be monitored (user programs at interrupt level
0
, startup software (recovery software), protocol handlers, or other supervisor software with an interrupt level greater than or equal to 1), different monitoring times can hereby be set. If the set monitoring time has expired without processes being executed during this time, additional indices are preferably collected for the verification and recognition of the error, and a corrective measure is then cued. Such indices can also already be collected during a monitoring session in progress, in order to enable an unambiguous location of a possible error. Preferably, given detection of an endless loop a single-step monitoring and registering first takes place for a determined time period for the program running in the endless loop, so that informative data are obtained for later error removal.
Preferably, a monitoring is also provided relating to blocked user processes (“stuck” monitoring). In this monitoring, all processes are scanned and monitored to check whether they are still processing messages. Process identifiers (PIDs) for each process are hereby stored in an internal table. This monitoring can for example be triggered periodically, every five seconds, by a low-priority process. According to the invention, a process is regarded as blocked if it is postponed and if one of its buffers contains a message that it does not read out within a given time period. This holds in particular when the buffer concerned can be read out only by this one particular process. In the case of a buffer to which several processes have access (threaded buffer), it is checked whether all processes that access this specific buffer are postponed, and are no longer processing messages still contained in the buffer. Here as well, given recognition of a blockade [or: deadlock], indices are collected for the clearer identification of the error, and corresponding corrective measures are then introduced. All data required for the monitoring are hereby stored in the process control block of the respective process, so that an expensive data management within the inventive monitoring method itself is avoided.
In the following, the invention is explained in more detail on the basis of exemplary embodiments, and with reference to the drawings.
REFERENCES:
patent: 4933843 (1990-06-01), Scheller et al.
patent: 5073853 (1991-12-01), Johnson
patent: 5278976 (1994-01-01), Wu
patent: 5475732 (1995-12-01), Petsre, III
patent: 5649098 (1997-07-01), Shieh et al.
patent: 5907674 (1999-05-01), Koeninger et al.
patent: 6047220 (2000-04-01), Eryurek
patent: 6047384 (2000-04-01), Puhl et al.
patent: 6058334 (2000-05-01), Shapiro
patent: 0030233738 (1991-10-01), None
patent: 0090062520 (1995-08-01), None
Miller (Improved reliability for digital switching) Telephone Engineer & Management; pp. 1-3, Dec. 1986.
Clark Mark
Lautenbach-Lampe Dagmar
Wollenweber Johannes
Chaki Kakali
Patel Gautam R.
Schiff & Hardin & Waite
Siemens Aktiengesellschaft
LandOfFree
Monitoring method for recognizing endless loops and blocked... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Monitoring method for recognizing endless loops and blocked..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Monitoring method for recognizing endless loops and blocked... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2465929