JPH10198578A - System and method for debugging - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a debug system in which the efficiency of debug can be sharply improved by automatically executing the reproduction of program failure. SOLUTION: A computer system which executes a program while obtaining a check point 3 is provided with a program error generation detecting part 4 which detects the generation of the failure of a program 2, and a program debug mode restart part 5 which moves the program 2 to a debug mode, and allows it to restart from the check point when the generation of the failure of the program 2 is detected.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a debugging method and a debugging method suitable for application to, for example, debugging of a program in a computer system. The present invention relates to a debugging method and a debugging method that can easily analyze a failure that has been difficult.

[0002]

2. Description of the Related Art In recent years, a number of techniques have been developed for debugging a program, such as setting a breakpoint, executing in a single step, and symbolic debugging. It can be said that a general technique has been established.

[0003] However, this is about a debugging technique in a single processor system, and it can be said that a debugging technique for a parallel program in a multiprocessor system is still in a search stage.

[0004] In particular, in a parallel processing program, since the processing proceeds simultaneously on a plurality of processors, even if a failure occurs, even if an attempt is made to reproduce the processing, the same processing is performed due to a slight timing shift. Often, the failure cannot be reproduced, making debugging more difficult.

[0005] For example, as shown in FIG.
In a situation where programs are executed in parallel under a multiprocessor system having three processors 1a to 11c, exclusive processing 13a in the program is executed.
Exclusion control does not function properly due to a bug in .about.13c, and a failure occurs due to mutual execution timing. In such a case, synchronization under the control of the multiple processors 11a to 11c is performed. If the user does not operate the debugger while retrieving the data, the failure cannot be reproduced and the efficiency of debugging has been significantly reduced. In some cases, reproduction was impossible, and debugging could not be performed.

In order to ensure the reproducibility of a program, there is also a method of continuously collecting various information such as a time stamp even during a normal program execution. There is a problem that the overhead increases and a storage medium for storing such various information is consumed in large quantities.

[0007]

As described above, in the conventional debugging method, for example, when a failure due to timing occurs in a program processed in parallel on a plurality of processors, the debugging is performed. However, there has been a problem that debugging is extremely difficult or debugging is impossible because the failure cannot be reproduced.

[0008] In order to ensure the reproducibility of a program, a method of continuously collecting various information such as a time stamp at the time of normal program execution increases the overhead at the time of normal program execution. However, there is a problem that a large amount of a storage medium for storing the various information is consumed.

The present invention has been made in view of the above circumstances. For example, when a failure occurs in a program that is processed in parallel on a multiprocessor system, the failure is automatically reproduced. Accordingly, it is an object of the present invention to provide a debugging method capable of dramatically improving debugging efficiency.

[0010]

SUMMARY OF THE INVENTION In order to achieve the above-mentioned object, the present invention monitors the occurrence of a program failure and, when the occurrence of a program failure is detected, synchronizes the program with all processors. Is shifted to the debug mode and restarted from the checkpoint.

That is, according to the present invention, when a failure occurs, the program can be synchronously executed in all the processors in the debug mode without causing an overhead such as collecting various information such as a time stamp at the time of normal program execution. By restarting from the checkpoint and restarting from the checkpoint, it is possible to automatically attempt to reproduce the failure and to improve the efficiency of debugging by collecting only the minimum necessary information for program analysis after the restart point. It becomes possible.

[0012]

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing a configuration of a debugging system according to an embodiment of the present invention. Now, processor 1
Executes the program 2, and at this time, the processor 1 acquires the checkpoint 3 for restart at a predetermined interval. If any failure occurs in the program 2, the processor 1 generates a trap.

The program error occurrence detecting section 4 detects a trap generated by the processor 1, and the program debug mode restarting section 5
To the debug mode, and restart from the time immediately before the occurrence of the failure based on the information acquired at the checkpoint 3.

A code (usually called ASSERT) for checking whether the execution state of the program is properly controlled is embedded in the program 2, and if the execution state of the program 2 is not properly controlled,
It is also effective that the program 2 generates a trap by itself, causes the program error occurrence detection unit 4 to detect the occurrence of an abnormal state, and shifts to the above-described processing.

After the program debug mode restart unit 5 shifts the program 2 to the debug mode, the program 2 is executed under the control of the debugger. For example, the program 2 is step-executed. , Or while the execution history is being collected.

Here, the operation of the debugging system according to the embodiment will be described with reference to FIGS. 2 and 3 are flowcharts for explaining the operation of the debugging method according to the embodiment.

When a failure occurs in the program 2 being executed, first, the program error occurrence detection section 4 detects the occurrence of the failure (step A1 in FIG. 2). Then, the program debug mode restart unit 5 shifts the program 2 to the debug mode (step A2 in FIG. 2) and sets the execution step of the program 2 to the check point 3
Is returned to the checkpoint acquired immediately before the occurrence of the failure from the information stored in step (A3 in FIG. 2), and a restart under the debugger is performed (step A4 in FIG. 2).

The program is shifted to the debug mode, and the program restarted from the checkpoint obtained immediately before the occurrence of the failure is processed while collecting the execution history (step B1 in FIG. 3). Processing when a trap occurs in debug mode, such as entering a trap (interrupt) and saving execution history (step B5 in FIG. 3)
Is terminated after the execution of.

On the other hand, if the failure has not been reproduced and the next checkpoint has been reached (Y in step B2 in FIG. 3), the execution history collected so far is discarded (FIG. 3). Step B3), and restart from the checkpoint acquired immediately before the occurrence of the failure again (Step B4 in FIG. 3).

As a result, the above processing is repeated until the failure is reproduced, and only the execution history at the time when the failure is reproduced can be collected. FIG.
And FIG. 5 is a conceptual diagram showing a flow of a system to which the debugging method according to the embodiment is applied.

As shown in FIG. 4, the processors 11a to 11a
In a situation where programs are executed in parallel under a multiprocessor system having three processors 1c, exclusive processes 13a to 13c in the programs are executed.
If exclusive control does not function properly due to a bug in the program and a failure occurs due to mutual execution timing, all programs being executed by the processors 11a to 11c are transferred to the debugger and re-executed. Restart from checkpoint 12. This program is repeatedly restarted until the failure is reproduced.

Next, the flow of the system will be described with reference to FIG. The program 2 is executed while obtaining checkpoints at predetermined intervals ((1) in FIG. 5).
Here, if a failure occurs in the program 2 due to any cause ((2) in FIG. 5), the occurrence of the failure is detected by the program error detection section 4 and the program debug mode restart section 5 switches to the debug mode. The process is shifted ((3) in FIG. 5), and is restarted from the checkpoint acquired immediately before the occurrence of the failure ((4) in FIG. 5).

The program 2 is shifted to the debug mode and restarted from the checkpoint acquired immediately before the occurrence of the failure, and the process proceeds while collecting the execution history, but the failure is not reproduced and the next checkpoint is acquired. If the location has been reached ((5) in FIG. 5), the execution history collected so far is discarded ((6) in FIG. 5).
Again, restart from the checkpoint acquired immediately before the occurrence of the failure is performed ((7) in FIG. 5).

This process is repeated until the failure is reproduced, and when the failure occurs ((9) in FIG. 5), the execution history is saved and the processing is terminated. As a result, it is possible to efficiently perform debugging of a failure that has conventionally been difficult to reproduce.

[0025]

As described above in detail, according to the present invention, when a failure occurs in any program, all the processors synchronously shift the program to the debug mode and restart from the checkpoint. This automatically attempts to reproduce the failure, and collects only the minimum necessary information for program analysis after the restart point. This allows effective use of the storage medium and improves debugging efficiency. Can be dramatically improved.

[Brief description of the drawings]

FIG. 1 is a diagram showing a configuration of a debugging system according to an embodiment of the present invention.

FIG. 2 is a flowchart for explaining the operation of the debugging method according to the embodiment;

FIG. 3 is an exemplary flowchart for explaining the operation of the debugging method according to the embodiment;

FIG. 4 is an exemplary conceptual view showing the flow of a system to which the debugging method according to the embodiment is applied.

FIG. 5 is an exemplary conceptual view showing the flow of a system to which the debugging method according to the embodiment is applied.

FIG. 6 is a conceptual diagram showing a flow of a system to which a conventional debugging method is applied.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 1 ... Processor, 2 ... Program, 3 ... Checkpoint, 4 ... Program error occurrence detection part, 5 ... Program debug mode restart part, 6 ... Debug method, 11
a, 11b, 11c: Processor, 12: Checkpoint, 13a, 13b, 13c: Exclusive processing, 14: Error occurrence point.

Claims (2)

[Claims] In a computer system debugging method for executing a plurality of programs in parallel on a plurality of processors while acquiring checkpoints, means for detecting a failure of the program, and detecting occurrence of a failure in the program by the means. Means for causing all the processors to synchronously shift the program to a debug mode and restarting from a checkpoint. 2. A method for debugging a computer system in which a plurality of programs are executed in parallel on a plurality of processors while acquiring checkpoints, the method comprising: detecting a failure of the program; And a step of synchronously shifting a program to a debug mode in all processors and restarting from a checkpoint.