JPH1091479A - Program debugging system, program debugging method and storage medium storing debugging program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To shorten time until a part where the execution result of a program becomes unjust is detected if a file outputted when the program is precisely executed previously exists. SOLUTION: A file acquirement means 1 acquires a result file name when the program precisely operates and a file name outputted by the execution of the program. A file output monitor means 4 recognizes output against the file. An output result comparison means 5 compares data-to be outputted with precise data. When unjust data is outputted as a result, a debugger 7 outputs a message and inputs a debugging command from a user. Since the debugger 7 sets an internal brake point in an output part against the file so as to monitor it, debugging can be executed when unjust data is to be outputted even if the unjust part of the program is not detected.

Description

DETAILED DESCRIPTION OF THE INVENTION

The present invention relates to a program debug system, a program debug method, and a storage medium storing a debug program.

[0001]

2. Description of the Related Art In general, program debugging is performed when the execution result of a program differs depending on the machine that executes the program or when an option specified when compiling a source program differs. Is being conducted to determine the cause.

An example of a conventional program debugging method is described in Japanese Patent Application Laid-Open No. 7-271631. The program debugging method described in this publication embeds a predetermined pattern in a source program, compiles it, debugs two execution programs having different execution machines and options in parallel, and detects different portions of the execution results. . It comprises a user input / output management unit, two debug control units, a command analysis unit, and an intermediate data comparison unit.

[0003] Each of the two debug controllers controls one interactive debugger. The interactive debugger debugs an execution program to be debugged. The intermediate data comparison unit compares the in-execution results of the two execution programs to be debugged and determines whether they match.
If the results do not match during execution, the data that does not match is displayed. The execution program is debugged with reference to the displayed data.

[0004]

In the conventional method, the program is stopped halfway up to the illegal portion and the data displayed at that time is input by inputting a user debug command. If the location where the result is incorrect is not known, there is a disadvantage that it takes time to specify the incorrect location. Many application programs repeatedly execute the same process, but if the result is incorrect during the repetition process, it is necessary to compare the data at each iteration, resulting in an incorrect result Have to execute many commands by then.

Further, in the conventional method, since two programs are simultaneously debugged using two interactive debuggers, there is a disadvantage that a large amount of resources are required for debugging. That is, when comparing results on different machines, the two machine resources being compared must be available simultaneously. Also, the two machines must be connected by a network resource or the like.

When debugging two programs with different options specified at the time of compilation on the same machine, there must be a storage area that can operate the two programs and the two interactive debuggers.

Further, in the conventional method, an error occurs in the execution result of the program, especially in the result of the floating-point operation, due to a difference in an option specified when executing the program on a different machine or compiling the program. In some cases, however, there is a disadvantage that this calculation error cannot be considered.

This is because when comparing the results of the commands executed by the two debuggers, it is determined whether or not the execution has been performed correctly by checking whether the results of the two match.

SUMMARY OF THE INVENTION An object of the present invention is to provide a debug / debug mode capable of shifting to a debug mode (waiting for input of a debug command from a user) when an output result different from the correct result occurs during development and maintenance of a program whose correct result is known. It is to provide a system.

Another object of the present invention is to compare a result in consideration of a difference in a machine architecture or a function of a compiler and a calculation error in a case where a correct result is different from a result of a program being debugged. To provide a debugging system.

[0011]

According to the first program debugging method of the present invention, when the output of the program is different from the correct result, the program shifts to the debug mode and the program can be debugged. More specifically, a file name acquisition unit (1 in FIG. 1) for acquiring a file name in which a correct result is stored and an output file name of a program, and an output destination file when the program outputs to a file. A file output monitoring unit (4 in FIG. 1) for confirming whether or not the result is to be compared, an output result comparison unit (5 in FIG. 1) for comparing the correct result with the data to be output by the program, When the comparison with the result is specified, the file name acquisition unit is called, a breakpoint is set in the output part to the file in the program, and the file is output when the program execution stops at the set breakpoint. Call monitoring means,
When an output of incorrect data is detected, a debugger that outputs a message to that effect and inputs a debug command from a user is provided.

Further, in the second program debugging method of the present invention, it is determined whether or not the output data of the program is correct in consideration of a calculation error. More specifically, an error range obtaining unit (3 in FIG. 7) for obtaining an allowable error range,
Output result determining means (6 in FIG. 7) for determining whether or not the data to be output by the program with respect to a correct result falls within a specified error range.

Further, in the third program debugging method of the present invention, an allowable error range can be set for each output file. Specifically, it has file information acquisition means (2 in FIG. 13) for acquiring a file name in which correct results are stored, a file name output by the program, and an allowable error range for each output file.

A first program debugging system of the present invention instructs a first storage unit in which correct data is stored in advance, a second storage unit, and an output of data to the second storage unit. A debug target program having a breakpoint set in a data output instruction portion is executed, and when the execution of the program stops at the breakpoint, the program is output to the second storage means according to the instruction of the data output instruction portion. And debugging means for comparing the data with correct data in the first storage means corresponding to the data, and checking the program.

A second program debug system according to the present invention comprises a first storage means for storing correct data in advance, a second storage means, and a third storage means for storing an allowable value indicating an allowable error range. Means for executing a debug target program having a breakpoint set in a data output instruction portion for instructing output of data to the second storage means, and when the execution of the program is stopped at the breakpoint, The difference between the data output to the second storage means in accordance with the instruction of the data output instruction part and the correct data in the first storage means corresponding to the data is obtained, and the difference is stored in the third storage means. Debugging means for examining whether or not the value is within an allowable range indicated by the stored allowable value and inspecting the program.

[0016]

Next, embodiments of the present invention will be described in detail with reference to the drawings.

Referring to FIG. 1, in a first embodiment of the present invention, an input device 16 such as a keyboard, an output device 15 such as a display device, a control unit 17 for controlling execution of a program, and a program A memory 18 for storing information required for execution and an external storage device 19 for storing output results of the program and the like are provided.

The control section 17 includes a debugger 7 and a program 8 to be debugged.

The debugger 7 comprises: a file name obtaining means 1;
A file output monitoring unit 4 and an output result comparison unit 5 are provided. When it is specified from the input device 16 that the output file 13 in the external storage device 19 and the result file 14 are to be compared, the debugger 7 acquires the file name
Is started, a breakpoint is set in the output portion to the file in the program 8, and the program is executed. When the execution of the program 8 is stopped by the set break point, the file output monitoring means 4 is activated. If it is determined that the data in the output buffer 12 to be output to the output file 13 does not match the corresponding data in the result file 14,
This is output to the output device 15, the mode is shifted to the debug mode, and the debug command is received from the input device 16. Data in output buffer 12 and result file 1
If the corresponding data in 4 does not match or is not output to a file to be compared, the execution of the program 8 is continued until the next breakpoint.

The file name obtaining means 1 includes a name of the result file 14 (result file name) input from the input device 16 and a name of the output file 13 (output file name).
Is obtained, an area of the file correspondence table 9 is secured in the memory 18, and the obtained result file name and output file name are stored in the file correspondence table 9.

The file output monitoring means 4 includes a program 8
Starts the output result comparison means 5 when the name of the file whose contents are to be output from the output buffer 12 matches one of the output file names in the file correspondence table 9.

The output result comparing means 5 includes an output buffer 12
Is compared with the corresponding data in the result file 14 to determine whether they match.

The program 8 is a program to be debugged by the debugger 7.

The memory 18 has a file correspondence table 9 and the output buffer 12.

The file correspondence table 9 contains the name of the output file 13 output by the program 8, ie, the output file name, and the name of the result file 14, in which data output when the program 8 operates correctly, ie, the result file name, is stored. And are stored in pairs. When there are a plurality of files output by the program 8 during execution, and a file in which correct data corresponding to each is specified as a comparison target, a plurality of file name pairs are stored in the correspondence table 9. .

The output buffer 12 is an area for temporarily storing data to be output to a file by the program 8, or an area for temporarily storing data to be output to a file by the program 8.

The external storage device 19 has an output file 13 and a result file 14.

The output file 13 is a file to which the program 8 outputs data.

The result file 14 is a file that stores data that should be output to the output file 13 when the program 8 operates correctly.

Next, the operation of the first embodiment of the present invention will be described with reference to FIGS.

A correct output result of the program 8 has already been obtained by compiling and executing the source program of the program 8 on another machine, or compiling and executing the same program with other options on the same machine. In this case, the user inputs in advance information from the input device 16 in which the file name and the file name output by the execution of the program 8 are paired.

The debugger 7 determines whether or not the pair of files to be compared has been input (step 701 in FIG. 2). If the pair has been input (the comparison file has been specified), the file name is determined. The acquisition unit 1 is started (Step 702 in FIG. 2).

The file name obtaining means 1 takes into account the number of designated comparison file pairs, the length of the file name, etc., and the name of the file (result file 14) in which the correct result is stored in the memory. The result file name) and the area (file correspondence table 9) enough to store the name (output file name) of the file (output file 13) output by the execution of the program 8 are secured (step 101 in FIG. 3). The name and output file name are stored in the file correspondence table 9 (step 102 in FIG. 3). When there are a plurality of pairs of comparison files, all of them are stored in the file correspondence table 9.

After the processing of the file name obtaining means 1 is completed, the debugger 7 sets a breakpoint at an output portion for the file in the program 8 (step 705 in FIG. 2).

After setting a breakpoint, or when a pair of files to be compared is not specified, the process waits for a user to input a debug command from the input device 16 (step 706 in FIG. 2).

When the user inputs a debug command and the command is an end command, the debugger 7 ends its operation (step 707 in FIG. 2).

If the input debug command is not the end command, the designated debug command is processed (step 708 in FIG. 2).

If the designated debug command is the execution of the program 8 and the execution of the program 8 is stopped at a breakpoint, it is determined whether the stopped breakpoint is the breakpoint set in step 705 (step 709). If the operation is stopped at the break point set in step 705, the file output monitoring means 4 is activated (step 710).

The file output monitoring means 4 determines whether the name of the file to be output by the program 8 matches the output file name in the file correspondence table 9 (step 401 in FIG. 4). If there are a plurality of output file names in the file correspondence table 9, it is determined whether or not the output file names match any of them. Then, only when there is an output file name in the file correspondence table 9 that matches the output file name, the output result comparison means 5 is started (step 402 in FIG. 4).

The output result comparison means 5 determines whether the corresponding result file 14 is open (FIG. 5).
In step 501), if the file is not opened, the result file is opened (step 502 in FIG. 5).
Subsequently, it is determined whether or not data is stored in the output buffer 12 (step 503 in FIG. 5). If no data is stored, the file output monitoring means 4 returns to indicate that there is no inconsistent data. The value is returned (step 509 in FIG. 5). If there is data in the output buffer 12, data is input from the result file (step 504 in FIG. 5), one data is also input from the output buffer 12 (step 505 in FIG. 5), and both are compared ( FIG.
Step 507). If they do not match,
A return value indicating that invalid data is output is returned to the file output monitoring means 4 (step 508 in FIG. 5). If the two data match, the same processing (steps 503 to 507 in FIG. 5) is repeated for the next data in the output buffer 12.

The file output monitoring means 4 returns the return value of the output result comparing means 5 to the debugger 7 as it is.

The debugger 7 determines whether or not the output is incorrect data based on the return value from the file output monitoring means 4 (step 711 in FIG. 2). If the output is incorrect, the data to be output is correct. A message to the effect that the result does not match is output to the output device 15 (step 713 in FIG. 2), and input of the next debug command is waited for (step 706 in FIG. 2). If the output is not invalid data, the program 8 is executed until the next breakpoint (step 714 in FIG. 2).

According to the first embodiment of the present invention, when data output to a file is invalid, it is necessary to determine where the invalidity occurs or what data becomes invalid. Debugging can be performed without any information, so that the operability of the debugger is improved and the efficiency of the debugging work is also improved.

Next, the operation of one example of the first embodiment of the present invention will be described in detail.

Referring to FIG. 6, it is assumed that the user has designated RESULT1 and OUTPUT1 as an environment variable CMPFILE1 as a pair of files to be compared. The name of the program 8 to be debugged is a. out, and the command for starting the debugger 7 is debug.

When the debugger 7 is started by “debug a.out”, the file to be compared is specified, so the file name obtaining means 1 is started (step 702 in FIG. 2), and the file correspondence table 9 is created. (Step 101 in FIG. 3). That is, RESULT1 as a result file name and OUT as an output file name of the program 8 (a.out) are included in the file correspondence table 9.
PUT1 is stored (step 102 in FIG. 3).

The debugger 7 causes the program 8
A breakpoint is set for the output portion of (a.out) to the file (step 705 in FIG. 2).

When a debug command run instructing execution of the program 8 (a.out) is input, the program 8 (a.out) is executed (step 70 in FIG. 2).
8). On the way, every time the output to the output file (OUTPUT1) is performed, the execution of the program 8 (a.out) stops at the breakpoint set in step 705 in FIG.
The file output monitoring means 4 is started (step 7 in FIG. 2).
10), and the output result comparing means 5 is activated (FIG. 4).
Step 402).

In the output result comparing means 5, at first,
In the example of FIG. 6, the data that matches the data in the output file (RESULT1) is stored in the output file (OUTPUT).
Since it is output to 1), 0 is returned as a return value (step 509 in FIG. 5). Therefore, it is determined that there is no output of incorrect data (step 711 in FIG. 2), and the execution of the program 8 (a.out) is continued until the next breakpoint (step 714 in FIG. 2). However, as shown in FIG. 6, when "31" is stored in the output buffer 12, the corresponding result file (RESULT) is stored.
The value of the data in 1) is “1362”, and they do not match. Therefore, the output result comparison means 5 returns a return value 1 indicating an invalid data output (step 5 in FIG. 5).
08).

As a result, the debugger 7 determines that incorrect data has been output (step 711 in FIG. 2), and outputs a message indicating that the incorrect data has been output to the output device 1.
5 (step 713 in FIG. 2), and waits for a debug command input from the user (step 7 in FIG. 2).
06).

Next, a second embodiment of the present invention will be described in detail with reference to the drawings.

Referring to FIG. 7, in the second embodiment of the present invention, in addition to the configuration of the first embodiment shown in FIG. 1, error range obtaining means 3 and error allowable range storage means 10 are provided. And an output result determination unit 6 instead of the output result comparison unit 5.

The error range obtaining means 3 receives the output file 1 (13a) and the output file 2 (13b) from the input device 16.
If an allowable error range is input to the output file 3 (13c), the value is stored in the allowable error storage unit 10.

The output result judging means 6 corresponds to the data which the program 8 intends to output to the output file 1 (13a), the output file 2 (13b) and the output file 3 (13c), and the respective output files. File 1 (14a), result file 2 (14b) and result file 3 (14c) in which correct results are stored
It is determined whether or not the error with the corresponding data in the range is within the range of the error stored in the error allowable range storage means 10.

Each of the result files 1, 2, and 3 (14a, 14b, and 14c) is stored in the error allowable range storage means 10.
The error range obtaining means 3 stores the value of the error allowed between the data corresponding to the output files 1, 2 and 3 (13a, 13b and 13c).

Next, the operation of the second embodiment of the present invention will be described in detail with reference to FIGS.

The operation until the debugger 7 activates the file name obtaining means 1 (step 702 in FIG. 8) and the processing of the file name obtaining means 1 is completed is the same as the operation of the first embodiment. Omitted. Thereafter, the debugger 7 activates the error range obtaining means 3 (Step 703 in FIG. 8).

The error range obtaining means 3 determines whether an error range has been designated (step 301 in FIG. 9).
If specified, the specified value is obtained (FIG. 9).
Step 302), and stores the value in the error tolerance storage unit 1.
0 (step 303 in FIG. 9). If the error range is not specified, the value 0 is stored in the error allowable range storage means 10 (Step 304 in FIG. 9).

After the error range obtaining means 3 is activated, the debugger 7 sets a breakpoint at an output portion for a file in the program 8 (step 7 in FIG. 8).
05) to the processing (step 401 in FIG. 10) in which the file output monitoring means 4 determines whether the file name that the program 8 is trying to output matches any of the output file names in the file correspondence table 9. Since the operation is the same as that of the first embodiment, the description is omitted.

If the file to be output by the program 8 matches one of the output file names in the file correspondence table 9, the file output monitoring means 4 activates the output result judging means 6 (step in FIG. 10). 40
3).

The output result judging means 6 judges whether a file (result file) storing a correct result corresponding to a file (output file) to be output by the program 8 has already been opened (FIG. 1).
(Step 601 in FIG. 11), and open if not opened (Step 602 in FIG. 11). Next, it is determined whether data is stored in the output buffer 12 (step 603 in FIG. 11), and if no data is stored, a value indicating that there is no invalid data is returned to the file output monitoring means 4. (Step 609 in FIG. 11). When data is stored in the output buffer 12, one data is input from the result file (step 60 in FIG. 11).
4) One data is also input from the output file 12 (step 605 in FIG. 11), and the relative error between them is calculated (step 606 in FIG. 11). The calculated relative error is compared with the value stored in the error allowable range storage means 10 (Step 607 in FIG. 11). If the calculated relative error is larger, a return value indicating the output of incorrect data is returned to the file output monitoring means 4 (step 608 in FIG. 11). On the other hand, if the calculated relative error is equal to or less than the value stored in the error allowable range storage means 10, the same processing is performed for the next data in the output buffer 12 (step 6 in FIG. 11).
From step 03, step 607) is repeated.

The file output monitoring means 4 returns the return value of the output result judgment means 6 to the debugger 7 as it is.

The processing of the debugger 7 after the processing of the file output monitoring means 4 has been completed is the same as the operation of the first embodiment, and will not be described.

According to the second embodiment of the present invention, in comparing the data output by the program 8 with the data of the correct result, the calculation error caused by the difference in the machine architecture or the option at the time of compiling the program is eliminated. This can be taken into account, and the display of a message indicating incorrect data output due to a slight difference from a correct result due to an arithmetic error can be suppressed. This eliminates the need for the user to check whether the displayed message is due to a calculation error, and has the effect of improving the efficiency of the debugging operation.

Next, the operation of one example of the second embodiment of the present invention will be described in detail.

Referring to FIG. 12, the user sets RESULT1 and OUTPUT1 as environment variables CMPFILE1 and RESULT2 and OU
TPUT2 and the environment variable CMPFILE2, and RESU
LT3 and OUTPUT3 are converted into environment variables CMPFILE3.
It is assumed that each is specified. Further, it is assumed that a value of 0.0001 is specified in the environment variable CMPERROR as a permissible error range. Further, the name of the program 8 to be debugged is a. out, and the command for starting the debugger 7 is debug.

When the debugger is started by "debug a.out", the file to be compared is specified, so the file name obtaining means 1 is started (step 702 in FIG. 8), and the file correspondence table 9 is created. (Step 101 in FIG. 3). In the file correspondence table 9, RESULT1, RESULT2, and RESULT3 as the result file names and OUTPUT1, OUTPUT2, and OUTPUT3 as the output file names of the program 8 (a.out) are stored as a pair, respectively ( Step 102 in FIG. 3).

Also, the program 8
A breakpoint is set for the output portion of (a.out) to the file (step 705 in FIG. 8).

When a debug command run instructing execution of program 8 (a.out) is input, program 8 (a.out) is executed (step 70 in FIG. 8).
8). On the way, the file name is OUTPUT1 or OUT
Whenever output to the file of PUT2 or OUTPUT3 occurs, execution of the program 8 (a.out) stops at the breakpoint set in step 705 of FIG. 8 and the file output monitoring means 4 is activated (FIG. 2). Step 710), and the output result determination means 6 is activated (step 403 in FIG. 10).

The output result judging means 6 determines a result file (RESULT1) and an output file (OUTPU) for the data to be output to the output file (OUTPUT1).
For the data to be output to T2), a result file (RE
SULT2) and a result file (RESULT3) for the data output to the output file (OUTPUT3).
Then, the relative error with the corresponding data is calculated (step 606 in FIG. 11). Program 8 (a.ou
Assuming that the data output by t) is output data and the corresponding correct result data is result data, the relative error is {(result data−output data) / result data}. When it is determined whether or not the relative error is within the allowable range (step 606 in FIG. 11), the absolute value of the relative error is compared with the value of the error allowable range storage unit 10 (FIG. 1).
1 step 607).

In the example of FIG. 12, since the relative error is within the allowable range for any of the output files (OUTPUT1, OUTPUT2 and OUTPUT3) at first, 0 is output from the output result determination means 6. Is returned (step 60 in FIG. 11).
9), a message indicating the output of illegal data is not displayed. However, in the output to the output file (OUTPUT2), the data “2862.43” is stored in the output buffer 12.
When "2" is stored, the data in the result file (RESULT2) for that data is "8692.93".
5 ", and the relative error at this time is" 0.6707 ", which exceeds the value" 0.0001 "stored in the error allowable range storage means 10. Therefore, the output result determination means 6 returns 1 is returned (step 608 in FIG. 11).

Since the file output monitoring means 4 also returns 1,
The debugger 7 outputs a message indicating that the output is incorrect data (step 713 in FIG. 8), and waits for a debug command input from the user (step 706 in FIG. 8).

Next, a third embodiment of the present invention will be described in detail with reference to the drawings.

Referring to FIG. 13, the third embodiment of the present invention differs from the configuration of the second embodiment shown in FIG. The difference is that a file information obtaining unit 2 is provided instead, and a file information area 11 is provided instead of the file correspondence table 9 and the error tolerance storage unit 10.

The file information obtaining means 2 is provided with the input device 16
When the result file name and the output file name are input from the memory, an area for storing the result file name, the output file name and the allowable error range for the output file, that is, the file information area 11 is secured in the memory, and the result file name is obtained. And output file name to file information area 1
1 and if an allowable error range for the output file is specified, the value is stored in the file information area 11. When a plurality of result file names, output file names, and error tolerances are input, all of them are stored in the file information area 11.

In the file information area 11, a set of a result file name, an output file name, and an allowable error range is stored by the file information acquisition means 2. Result file name,
When a plurality of output file names are specified, all the sets are stored.

Next, the operation of the third embodiment of the present invention will be described in detail with reference to FIGS.

The user compiles the program 8 by executing it on another machine or specifying another option.
If a file with a correct result already exists due to execution or the like, the name of the file (result file), the name of a file (output file) output by executing the program 8, and the data between the two files Is input from the input device 16.

The debugger 7 determines whether or not information on the result file and the output file has been input (FIG. 1).
4) (Step 701 of FIG. 14).
4).

The file information obtaining means 2 considers the number of input information, the length of a file name, etc.
1 is secured in the memory (step 20 in FIG. 15).
1) Store the input result file name and output file name in the file information area 11 (step 20 in FIG. 15).
2) If an allowable error range is specified for the output file, the value is obtained (step 2 in FIG. 15).
04), and store it in the file information area 11 (step 206 in FIG. 15). On the other hand, if no allowable error range is specified, the value 0 is stored in the file information area 11 (FIG. 1).
5 step 205). After repeating the above processing (steps 202 to 206 in FIG. 15) for all the result files and output files input by the user,
Control is returned to the debugger 7 (step 208 in FIG. 15).

After activating the file information acquisition means 2, the debugger 7 sets a breakpoint in the output portion for the file in the program 8 (step 705 in FIG. 14) and waits for a debug command input from the user. (Step 706 in FIG. 14).

Even when the information regarding the result file and the output file has not been input, it waits for the input of the debug command from the user (step 706 in FIG. 14).

For the processing after this (step 706 in FIG. 14), the operation of the second embodiment is based on the values stored in the same error allowable range storage means 10 for all the files to be compared. In contrast to the determination of whether or not the data is invalid, in the present embodiment, the operation of the second embodiment is the same as that of the second embodiment except that the value stored in the file information area 11 is used for each file. Are identical.

In the above-described third embodiment, the range of an error allowed for output data can be specified for each file output by the program 8, so that a more detailed error can be considered. In other words, this method is effective when the data cannot be processed with the same error as other files, such as when the calculation error of the data differs depending on the file output by the program 8 or when there is a file that is required to output a highly accurate result. . For example, if all files are processed with the largest allowable error value, incorrect data output or a decrease in data accuracy may be missed. If the file is processed, a message indicating incorrect data output may be displayed even for an allowable error. According to the third embodiment of the present invention, such inconvenience can be suppressed. Therefore, the efficiency of the debugging work is further improved.

[0085]

The first effect is that when data output to a file is invalid, debugging can be performed even if there is no information such as where the invalidity occurs or what data becomes invalid. What you can do. As a result, the operability of the debugger is improved, and the efficiency (productivity and maintainability) of the debugging work is also improved.

This is because a breakpoint is set at the output portion to the file, and when the execution of the program is stopped at the breakpoint, the output data is compared with the correct data.

The second effect is that an operation error caused by a difference between an architecture of a machine for executing a program and an option specified when compiling the program can be ignored. As a result, an extra check operation for the output message is not required, and the efficiency of the debug operation is improved.

This is because when comparing the data to be output to the file with the correct data, if the difference between the two is within an allowable error range, it is determined that the correct data is output.

The third effect is that the allowable error range can be changed for each output file. As a result, output of unnecessary messages can be further suppressed, and the efficiency of debugging work is further improved.

This is because the allowable error range can be set for each file output during execution of the program.

[Brief description of the drawings]

FIG. 1 is a block diagram showing a first embodiment of the present invention.

FIG. 2 is a flowchart showing an operation of the debugger according to the first embodiment of the present invention.

FIG. 3 is a flowchart showing an operation of a file name obtaining unit according to the first embodiment of the present invention.

FIG. 4 is a flowchart showing the operation of the file output monitoring means according to the first embodiment of the present invention.

FIG. 5 is a flowchart showing the operation of the output result comparison means according to the first embodiment of the present invention.

FIG. 6 is an explanatory diagram showing an example of the first embodiment of the present invention.

FIG. 7 is a block diagram showing a second embodiment of the present invention.

FIG. 8 is a flowchart showing an operation of the debugger according to the second embodiment of the present invention.

FIG. 9 is a flowchart illustrating an operation of an error range obtaining unit according to the second embodiment of the present invention.

FIG. 10 is a flowchart showing the operation of the file output monitoring means according to the second embodiment of the present invention.

FIG. 11 is a flowchart illustrating an operation of an output result determination unit according to the second embodiment of the present invention.

FIG. 12 is an explanatory diagram showing one example of the second embodiment of the present invention.

FIG. 13 is a block diagram showing a third embodiment of the present invention.

FIG. 14 is a flowchart showing an operation of the debugger according to the third embodiment of the present invention.

FIG. 15 is a flowchart showing an operation of a file information acquisition unit according to the third embodiment of the present invention.

FIG. 16 is an explanatory diagram showing an example of the third embodiment of the present invention.

[Description of Signs] 1 File name acquisition unit 2 File information acquisition unit 3 Error range acquisition unit 4 File output monitoring unit 5 Output result comparison unit 6 Output result determination unit 7 Debugger 8 Program 9 File correspondence table 10 Error allowable range storage unit 11 File information 12 Output buffer 13 Output file 14 Result file 15 Output device 16 Input device 17 Control unit 18 Memory 19 External storage device

Claims (9)

[Claims] 1. A breakpoint is set in a first storage unit in which correct data is stored in advance, a second storage unit, and a data output instruction portion instructing output of data to the second storage unit. When the program to be debugged is executed, and when the execution of the program is stopped at the breakpoint, the data output to the second storage means according to the instruction of the data output instruction portion and the first data corresponding to the data. A program debugging system comprising: debugging means for comparing the data with correct data in a storage means and checking the program. 2. A first storage unit in which correct data is stored in advance, a second storage unit, a third storage unit in which an allowable value indicating an error allowable range is stored, and a storage unit in the second storage unit. Executing a debug target program in which a breakpoint is set in a data output instruction portion for instructing data output, and when the execution of the program is stopped at the breakpoint, the second data output instruction portion indicates the second The difference between the data output to the storage means and the correct data in the first storage means corresponding to the data is determined, and the difference is within an allowable range indicated by the allowable value stored in the third storage means. And a debugging means for checking whether or not the program is valid and for inspecting the program. 3. The program according to claim 1, further comprising a setting unit configured to set a breakpoint at a corresponding data output instruction portion in the program based on data specifying information specified by a user. -Debug system. 4. A first step of setting a breakpoint at an output portion of a file in the program when a comparison with a file having a correct result is specified in execution of the program to be debugged; If the execution is stopped and the output is for a file to be compared, a second step of comparing the corresponding data of the file with the correct result with the data that the program is about to output,
And a third step of outputting a message when the two data do not match in the step (b) and enabling the input of a debug command. 5. The method according to claim 4, further comprising a fourth step of determining that the correct data is output if the difference between the correct data and the data to be output by the program is within an allowable error range. The method according to claim 4. 6. The program debugging method according to claim 5, further comprising a fifth step of setting the allowable error range for each file output by the program. 7. A first process for controlling execution of a debug target program in which a breakpoint is set in a data output instruction portion for instructing output of data to a first storage means; When stopping at a point, the data output to the first storage means according to the instruction of the data output instruction part is compared with the correct data in the first storage means corresponding to the data, and the program is checked. A storage medium storing a program / debugging program, which causes a computer to execute a second process of performing the following. 8. A first process for controlling execution of a debug target program in which a breakpoint is set in a data output instruction portion for instructing output of data to a first storage means, and wherein the execution of the program is the break. When stopping at the point, the difference between the data output to the first storage means according to the instruction of the data output instruction part and the correct data in the second storage means corresponding to the data is obtained, and A program / debugging program which checks whether or not it is within an allowable range indicated by an allowable value stored in the storage means of the third program, and causes the computer to execute a second process of checking the program. A storage medium that stores. 9. The method according to claim 8, wherein the third step of setting a breakpoint at a corresponding data output instruction portion in the program is executed by a computer based on data specifying information specified by a user. A storage medium storing the program / debug program according to 7 or 8.