JP2009244969A - Program operation comparison device, method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To automatically collect information necessary for specifying the causes of an error, degradation, and the like which becomes obvious depending upon a program executing speed and a processing procedure. <P>SOLUTION: This program operation comparison device changes an execution file of such a program so that the program itself can output execution history of a function, acquires the execution history of the executed program by a program execution history collecting means to store the execution history of the program in an execution history storage means, divides the execution history with a local part of a function call sequence as a function block on the basis of the depth of a function call stack of the executed program and an appearance pattern to store the function block in a function block storage means, compares the function block of the function block storage means with the function call sequence of the program under execution acquired by the program execution history collecting means, detects different places and stores them in a comparison result storage means. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a program operation comparison apparatus, method, and program, and an error is detected by detecting a program operation difference caused by a difference in an environment for executing a program, a version of a program to be operated, or a difference in the operation environment. The present invention relates to a program operation comparison device, method, and program for shortening the time from occurrence of a problem until the cause is identified.

  Current debugging techniques include methods for inserting probes into programs, profilers and system monitors, debuggers, dumps, tracers and loggers.

  When debugging by inserting a probe into a program, the problem is where to insert the probe in the program. At this time, the length of time from when an error occurs until a bug is found depends on the program itself and the skill of the user who inserted the probe. For this reason, the method of inserting a probe into a program is not a method of shortening the time from the occurrence of an error to the identification of a bug.

  A profiler or system monitor is a method for monitoring the amount of computer resources consumed by a program, so it is useful for finding bugs related to the amount of computer resources consumed by the program, such as a decrease in the program execution speed. It is not possible to find a bug that becomes apparent depending on the execution speed of the program and the processing procedure of the program, for example, a bug related to a conflict problem.

  The debugger depends on the time from when an error occurs until a bug is identified at the breakpoint insertion position. Specifically, when a user with more programming skills inserts a breakpoint, the time from when an error occurs until a bug is found tends to be shorter.

  There is also a method of automatically inserting breakpoints and reducing the time from occurrence of an error to finding a bug without depending on the user's skill (for example, see Patent Document 1). When a breakpoint is used as a means for acquiring information on the program, processing with high overhead such as context switching occurs, so that the execution speed of the program is significantly reduced.

  When debugging using a dump, the timing of acquiring program information becomes a problem. In the dump, program information is acquired when an error that makes the program inexecutable occurs or when a specific external event occurs. From the program information acquired at these timings, it is difficult to find a bug that becomes apparent depending on the execution speed of the program and the processing procedure of the program.

The tracer and logger automatically acquire the execution time, function name, argument, return value, etc. of the executed function or system call. For this reason, it is considered that sufficient information can be acquired to find bugs that depend on the processing procedure of a program in a program that has been fully modularized and portability has been improved. Since the time until discovery can be shortened, the processing time required to acquire the execution history can be reduced. However, conventional tracers and loggers do not accurately obtain the arguments and return values of executed functions.
JP-A-7-73070

  As described above, in the conventional debugging method, the time from when an error occurs until a bug is found depends on the programming skill of the user who performs debugging. Further, depending on the debugging technique, it is not possible to find a bug that becomes apparent depending on the execution speed of the program and the processing procedure of the program.

  The present invention has been made in view of the above points, and finds and identifies a bug that manifests depending on the execution speed of the program and the processing procedure of the program without depending on the programming skill of the user who performs debugging. It is an object of the present invention to provide a program operation comparison apparatus, method and program for automatically collecting information necessary for the above.

  FIG. 1 is a principle configuration diagram of the present invention.

The present invention (Claim 1) is a program operation comparison device for finding a difference in operation of a program,
Program execution means 40 for executing the program;
A program execution history in which an execution file of the program is changed so that the program itself can output a function execution history, and the execution history of the executed program is acquired by the program execution means 40 and stored in the execution history storage means 180 Collecting means 100;
A program that stores the execution history of the program in the execution history storage unit 180 into the function block storage unit 250 by dividing the local area of the function call sequence as a function block based on the depth of the function call stack of the executed program and the appearance pattern. Execution history dividing means 200;
The function block of the function block storage unit 250 is compared with the function call sequence of the program being executed by the program execution unit 40, and a comparison unit 300 that detects a different portion and stores it in the comparison result storage unit 370 is provided.

Further, the present invention (Claim 2) is provided in the program execution history collecting means 100.
Execution file changing means for changing an execution file of a program for collecting information about the function with respect to a function acquired as an execution history of the program,
About the function to be acquired, debug information acquisition means for acquiring values necessary for acquiring detailed information,
For the functions defined in the execution file of the program and the functions of the shared library specified by the user, information on the time when the program was executed by the program execution means, function name, argument, and call stack depth information is obtained. And an execution history collection means for registering the acquired information in the execution history storage means 180.

Further, the present invention (Claim 3) is provided in the program execution history dividing means 200.
The history information stored in the execution history storage unit 180 is read, and only the function call is focused. The call stack is divided when the call stack depth value becomes small. Execution history classification means as a block;
A search is performed for a function block in which a function in the function block is the same including the execution order. If there is, the function in the function block is also the same in the function block including the execution order. When there is a function block having the same length as a result of repeating the process of checking whether there is a function block, a plurality of function blocks are collected as one function block for the function block having the longest series of lengths, and function block storage means Means for registering in 250;
Whether the arguments and return values of the functions in the function block are the same in all functions, whether there is a function having the same value, or is different in all functions is registered in the function block storage unit 250 associated with the function. Means.

The present invention (Claim 4) is provided in the comparison means 300.
By reading the function block from the function block storage unit 250 and comparing the function call sequence of the program being executed by the function block and the program execution unit, the operation of the program being executed differs from the operation assumed by the user. Means for detecting
By comparing the function call sequence alone, if a different part cannot be detected, the argument and return value of the executed function in the function block are compared with the argument and return value of the function executed by the executing program. And means for detecting a location where the operation of the program being executed differs from the operation assumed by the user.

  FIG. 2 is a diagram for explaining the principle of the present invention.

The present invention (Claim 5) is a program operation comparison method for finding a difference in operation of a program,
The execution file of the executed program is acquired by a function (program execution means) that changes the execution file of the program so that the program itself can output the execution history of the function, and the program is executed. A program execution history collection step (step 1) stored in
A program execution history in which the execution history of the program in the execution history storage means is divided into function blocks based on the depth of the function call stack of the executed program and the appearance pattern, and stored in the function block storage means A division step (step 2);
The function block of the function block storage means is compared with the function call sequence of the program being executed by the function for executing the program, and a comparison step (step 3) is performed in which a different part is detected and stored in the comparison result storage means. .

The present invention (Claim 6) provides a program execution history collection step (Step 1).
An execution file change step for changing an execution file of a program for collecting information about the function for a function acquired as a program execution history;
Debug information acquisition step to acquire the time when returning from the called function to the caller, arguments changed in the called function, return value,
For functions defined in the executable file of the program and functions of the shared library specified by the user, the time when the program was executed by the function that executes the program, the function name, the argument, the value of the depth of the call stack, An execution history collection step of acquiring information including a return value and registering the acquired information in the execution history storage means is performed.

Further, according to the present invention (Claim 7), in the program execution history dividing step (Step 2),
Reads history information stored in the execution history storage means, pays attention only to function calls, delimits when the call stack depth value of the called function becomes smaller, and separates the delimited points into one function block An execution history classification step, and
A search is performed for a function block in which a function in the function block is the same including the execution order. If there is, the function in the function block is also the same in the function block including the execution order. When there is a function block having the same length as a result of repeating the process of checking whether there is a function block, a plurality of function blocks are collected as one function block for the function block having the longest series of lengths, and function block storage means Registering with
A step of registering in a function block storage means associated with a function whether the arguments and return values of the functions in the function block are the same in all functions, whether there is a function having the same value, or different in all functions And do.

Further, the present invention (Claim 8) provides a comparison step (Step 3).
By reading the function block from the function block storage means and comparing the function call sequence of the program being executed with the function to execute the program with the function block, the operation of the program being executed differs from the operation assumed by the user. Detecting the location;
By comparing the function call sequence alone, if a different part cannot be detected, the argument and return value of the executed function in the function block are compared with the argument and return value of the function executed by the executing program. And detecting a location where the operation of the program being executed differs from the operation assumed by the user.

  The present invention (Claim 9) is a program operation comparison program for causing a computer to function as each means constituting the program operation comparison device according to any one of Claims 1 to 4.

  According to the present invention, when an error occurs during execution of a program, automatically collecting the execution information of the program eliminates the need for the user to actively collect program operation information. It can shorten the time from occurrence of a bug to finding a bug.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  The present invention makes it possible to shorten the time from the discovery of an error to the discovery of the bug by performing each process of the program execution history collection device, the program execution history division device, and the program execution history comparison device. To do. Specifically, an error occurs by obtaining an execution history executed with input values that can be assumed by the user, such as input values used in the test, and comparing the execution history with the execution history in which an error occurred. You can shorten the time from when you find a bug.

  Hereinafter, the “function call sequence” is an execution history of a function executed by the program, and is an order of the functions executed between the execution of the program and the termination.

  A “highly specific function” is a function in which there is no function having the same calling relationship in a function call sequence created by the same program or the execution rate is the lowest. A highly specific function block is also in agreement with a highly specific function.

[Program execution history collection device]
FIG. 3 shows the configuration of the program execution history collection apparatus according to the embodiment of the present invention.

  The program execution history collection device 100 changes the execution file 10 loaded in the memory so that the program itself outputs data on its own memory. The timing of the change is immediately after being loaded into the memory (before the main function of the program is executed) or when the program is being executed, when the program is stopped using the function of the OS. The output data includes the time when the function was executed, the function name, the argument, and the return value.

  The program execution history collection device (logger device) 100 shown in FIG. 1 includes an execution file change unit 110, a debug information acquisition unit 120, an execution history collection unit 130, an execution file list 140 that acquires an execution history, a symbol information storage unit 150, It comprises a debug information storage unit 160, a register list 170, and an execution history storage unit 180. The conventional execution environment is shown on the left side of the figure. The conventional execution environment includes an execution file 10 loaded in a memory, a program execution file 20, a library execution file 30, and a program execution unit 40.

  First, a processing procedure performed by the executable file changing unit 110 will be described.

  FIG. 4 is a flowchart of the execution file change process according to the embodiment of the present invention.

  Step 110) First, the execution file changing unit 110 determines whether to record the execution history of the function defined in the program execution file 20, whether to record the library function in the library execution file 30, and The user is inquired whether to record the execution history of the function defined in the library. If not, the process proceeds to step 130. If acquired, the process proceeds to step 120.

  Step 120) The execution file of the program is changed so as to output information on the function in the execution file executed by the program itself to the program execution history collection device 100 (logger).

  Step 130) As processing of loop A, first, an initial value i = 0 (increment 1), and a closing price is set to the number of libraries for monitoring an application designated by the user.

  Step 140) The program execution file 20 is changed so that the program itself outputs information related to the function executed by the library application to the program execution history collection apparatus 100.

  As processing of loop A, i is set to i + 1, and step 140 is repeated until the closing price is reached.

  Step 150) As loop B, the initial value i = 0 (increment 1) and the final value are the number of libraries to monitor the functions described in the library designated by the user.

  Step 160) The library execution file 30 is changed so that the library itself specified by the user outputs information on the functions in the library executed by the program execution history collection apparatus 100.

  As processing of loop b, i = i + 1 and step 160 is repeated until the closing price is reached.

  FIG. 5 is a flowchart of an outline operation of the executable file changing unit in the embodiment of the present invention.

  Step 2010) The execution file 20 is loaded from the disk into the memory.

  Step 2020) When the execution history of the function defined in the execution file 20 is acquired, the process proceeds to Step 2030, and when not acquired, the process is terminated.

  Step 2030) The executable file is read from the disk.

  Step 2040) As loop A ′, processing is performed for each record in the symbol table of the statically linked function.

  Step 2050) If the record is a main function, the process returns to Step 2040. If the record is not a pair, the process proceeds to Step 2060.

  Step 2060) The symbol information is registered in the symbol information storage unit 150.

  Step 2070) It is determined whether or not there is a machine language instruction for calling the registered function in the execution file loaded in the memory. If there is, the process proceeds to Step 2080, and if not, the process proceeds to Step 20120.

  Step 2080) The machine language instruction for reading the function of the execution file loaded in the memory is replaced with an instruction for executing the execution history collecting unit 130.

  Step 2090) The information about the location where the execution file on the memory is changed is registered in the symbol information storage unit 150.

  Step 20100) It is determined whether there is a machine language instruction for branching to the location where the execution file is changed in the execution file loaded in the memory. If there is, the process proceeds to Step 20110, and if not, the process proceeds to Step 2070. To do.

  Step 20110) The branch instruction is corrected in accordance with the change processing of the branch instruction, and the process proceeds to Step 20100.

  Step 20120) The debug information acquisition unit 120 (FIG. 8) performs processing.

  As a result, the program execution unit 40 executes the main function and ends the process.

  The processing of the execution file changing unit 110 of the program execution history collection device 100 will be described in detail.

  FIG. 6 is a flowchart of detailed operation of the executable file changing unit according to the embodiment of the present invention.

  First, it is assumed that the execution file 20 of the program is loaded when a processing target is selected from the memory or the disk 140 in which the execution file list for acquiring the execution history is stored in the execution file changing unit 110.

  Step 1210) When the user starts the program, the program is loaded from the disk into the memory.

  Step 1220) Information on whether or not to acquire the execution history of the function defined in the execution file 20 is acquired from the execution file list (memory) 140 for acquiring the execution history. Whether or not to acquire a function defined in the execution file 20 is acquired from the environment variable of the system. At this time, the following two pieces of information are also acquired.

-Library name for acquiring API API execution history for dynamic linking;
-Library name for acquiring the execution history of functions defined in dynamically linked libraries:
It is also possible to create a setting file on the disk and read out this information from the setting file.

  Step 1230) As an inquiry as to whether or not to acquire the execution history of the function defined in the execution file 20, the execution history of the static link function (defined in the .symtab section of the ELF) of the execution file 20 is obtained. It is determined whether or not to acquire. If acquired, the process proceeds to step 1240. If not acquired, the process ends.

  Step 1240) The executable file 20 is read from the disk.

  Step 1250) Next, as processing for the static symbol information of the function, the number of symbols related to the function is obtained from the static symbol table (ELF .symtab section) in the executable file 20 read from the disk (symnum ← static Number of link functions).

  Step 1260) Loop A is processed with i = 0 as the initial value and i = symnum.

  Step 1270) The i-th symbol information of the static symbol table is acquired (symbol ← i-th symbol information).

  Step 1280) It is determined whether symbol is symbol information of a function. If so, the process proceeds to Step 1290, and if not, the process proceeds to Step 1260.

  Step 1290) It is determined whether symbol is symbol information of the main function. If so, the process proceeds to Step 1260; otherwise, the process proceeds to Step 12100.

  Step 12100) The acquired symbol information is registered in the symbol information storage unit 150. Information registered in the symbol information storage unit 150 is an address mapped with a function name.

  Step 12110) A machine language instruction (ie call instruction, jmp instruction) for calling a symbol not registered in the symbol information storage unit 150 in the machine language instruction (ELF .text section) of the program of the execution file 10 loaded in the memory Etc.), and if so, the process proceeds to step 12130. If not, the process proceeds to step 12170.

  Step 12120) The machine language instruction for calling the symbol of the execution file 10 loaded in the memory is replaced with an instruction for executing the execution history collection unit 130.

  Step 12130) The following information is registered in the symbol information storage unit 150.

The address of the instruction that calls the symbol;
-Original machine language instruction replaced;
-Return address after replacement (the address of the instruction next to the instruction that executes the function execution history acquisition unit);
Step 12140) An instruction (jmp) for jumping to the address of the instruction next to the “replaced original machine language instruction” is added to the “replaced original machine language instruction”.

  Step 12150) It is determined whether there is a machine language instruction to jmp in the replaced instruction in the machine language instruction (ELF .text section) of the program of the execution file 10 loaded in the memory. If not, go to Step 12110.

  Step 12160) The value of the address serving as the operand of the machine language instruction to be jumped (jmp) in the execution file 10 loaded in the memory is replaced with the address of the “replaced original machine language instruction” registered in the symbol information storage unit 150. Return to step 12150.

  Step 12170) The debug information acquisition unit 120 performs processing, and the program execution unit 40 executes the main function and ends the processing.

The output result is shown in FIG. The symbol information storage unit 150 stores an address mapped with a function name. Here, as an address to be mapped,
The address of the instruction that calls the function;
-Original machine language instruction replaced;
・ Return address after replacement;
Etc.

  Next, the operation of the debug information acquisition unit 120 of the program execution history collection device 100 will be described in detail. The debug information acquisition unit 120 is a processing unit that acquires information (return value, argument type information, argument storage location) necessary to accurately acquire the argument and return value information of the executed function. is there.

  In the following description, “execution file” refers to both the execution file 20 of the program and the execution file 30 of the library.

  The “compile unit” is information of a source file. The compile unit stores information such as names, type information, registers to be used, and memory locations to be used in association with functions, global variables, structures, and the like defined in the source file.

  In the debug information acquisition unit 120, a program execution file becomes an input value. FIG. 10 shows an example of debug information. When the sample source code (a) is compiled by GCC, the debug information of func () is (b) debug information (DWARF) about func () added by GCC.

  FIG. 8 is a flowchart of an outline operation of the debug information acquisition unit according to the embodiment of the present invention.

  Step 2110) The executable files 20 and 30 are read from the disk.

  Step 2120) It is determined whether or not debug information is included in the execution files 20 and 30. If included, the process proceeds to Step 2130. If not included, the process is terminated.

  Step 2130) The debug position information is registered in the debug information storage unit 160.

  Step 2140) It is determined whether there is information on a compile unit that has not been registered. If there is, information is transferred to Step 2150, and if not, the processing is terminated.

  Step 2150) The debug information of the compilation unit is registered in the debug information storage unit 160.

  Step 2160) It is determined whether there is information on an unregistered function for the obtained compilation unit. If there is, information is transferred to Step 2170, and if there is not, information is transferred to Step 2140.

  Step 2170) The function debug information is registered in the debug information storage unit 160.

  Step 2180) It is determined whether there is argument information that is not registered for the acquired function. If there is, information is transferred to Step 2190. If there is not, information is transferred to Step 2160.

  FIG. 9 is a flowchart of detailed operation of the debug information acquisition unit according to the embodiment of the present invention.

  Step 13010) The executable files 20 and 30 are read from the disk.

  Step 13020) It is determined whether or not the execution files 20 and 30 include debug information. Here, the debug information is type information such as variables, and it is determined whether or not this information is included. If it is included, the process proceeds to step 1330. If it is not included, the process ends.

  Step 1330) In order to obtain the argument value accurately, in order to obtain information indicating the storage location of the argument when the storage location is changed during execution, the debug location information table (. It is determined whether there is a record that is not registered in the debug information storage unit 160 in the debug_loc section). If there is a record, the process proceeds to step 1340, and if not, the process proceeds to step 1360.

  Step 1340) Acquire records that are not registered.

Step 1350) The information in the acquired record is registered in the debug information storage unit 160, and the process returns to Step 303. The information to register is
·offset;
-Valid address range;
-Storage location (register name, distance from base pointer);
It is.

  Step 1360) In order to accurately acquire the value of the argument, the type information of the argument and the return value, and information indicating the storage location of the argument are acquired. At this time, it is determined whether or not there is a compile unit record that is not registered in the debug information storage unit 160 in the debug information table (.debug_info section) of the executable files 20 and 30. Ends the process.

  Step 1370) The record of the compile unit that is not registered is acquired from the debug information table (cu ← record of the acquired compile unit).

Step 1380) The information in the cu is registered in the debug information storage unit 160. The information to register is
-Source file name;
・ Compile directory name;
It is.

  Step 1390) It is determined whether or not there is a record of a function stored in association with the cu not registered in the debug information storage unit 160 in the debug information table (.debug_info section) of the executable files 20 and 30. The process proceeds to step 13100. Otherwise, the process proceeds to step 1360.

  Step 13100) Among the functions stored in association with cu, a record of a function that has not been registered is obtained (function ← obtained function record).

Step 13110) The information in the function is registered in the debug information storage unit 160, and the process proceeds to Step 13120. The information to register is
・ Function name;
The mapped address range;
-The position described in the source file;
・ Return value type information;
It is.

  Step 13120) It is determined whether or not there is a function argument record that is not registered in the debug information storage unit 160 in the debug information tables (.debug_info section) of the executable files 20 and 30. If yes, go to Step 1390.

  Step 13130) Among the arguments of function, the record of the argument that is not registered is acquired (argument ← the record of the acquired argument).

Step 13140) The information in the argument is registered in the debug information storage unit 160, and the process proceeds to Step 13120. The information to register is
・ Argument name;
-The position described in the source file;
・ Type information;
-Value storage location (register name, distance from base pointer, offset of debug position information table);
It is. “Register name” and “distance from base pointer” are registered in the debug information table in “value storage location” of variables and arguments whose storage location is not changed during execution of the function. In the “value storage location” of the variable or argument to be changed, “debug position information table offset” is registered in the debug information. “Register” indicates a register in which a value is stored. “Distance from the base pointer” indicates a distance from the base pointer, that is, a position on the memory.

  The data shown in FIG. 11 is stored in the debug information storage unit 160 by the processing of the debug information acquisition unit 120 shown in FIG.

  Next, a process of executing the program after the execution files 20 and 30 are changed, and the execution history collection unit 130 acquiring the execution history will be described.

  FIG. 12 is a flowchart of an outline operation of the execution history collection unit in the embodiment of the present invention.

  Step 2210) The program execution state is held in the register list 170.

  Step 2220) It is determined whether debug information is added to the program being executed. If it is added, the process proceeds to Step 2260, and if not, the process proceeds to Step 2230.

  Step 2230) Information of the executed function is registered in the execution history storage unit 180.

  Step 2240) The state of the retained program is restored.

  Step 2250) The jmp instruction is executed for the hooked function, and the process is terminated.

  Step 2260) When debug information is added to the program being executed in Step 2220, an argument is acquired for the function to be executed.

  Step 2270) The information of the executed argument is registered in the execution history storage unit 180.

  Step 2280) The state of the retained program is retained.

  Step 2290) A call instruction is executed for the hooked function.

  Step 22100) The program execution state is held in the register list 170.

  Step 22110) Information on the executed function is registered in the execution history storage unit 180.

  Step 22120) The stored program state is restored.

  Step 22130) The ret instruction is executed, the process is terminated, and control is transferred to the program execution unit.

  FIG. 13 is a flowchart of detailed operation of the execution history collection unit according to the embodiment of the present invention.

  Step 1410) When the program execution unit 40 executes a function for acquiring a history, the execution history collection unit 130 saves the general-purpose registers and index registers in the register list 170 on the memory, and holds the current program execution state.

For example, in the Intel x86 architecture, “general-purpose registers”
−eax, ebx, ecx, edx
And the “index register”
−esi, edi
It is.

  Step 1420) In order to confirm whether or not the debug information has been added to the program, it is determined whether or not the record of the hooked function is registered in the debug information storage unit 160. If registered, the process proceeds to Step 14110. If not registered, the process proceeds to step 1430.

  Step 1430) The record of the hooked function is read from the symbol information storage unit 150.

  Step 1440) In order to register information on the executed function in the execution history storage unit 180, the function name of the read record and the mapped address are registered in the execution history storage unit 180.

  Step 1450) The stack register and base register are returned to the state at the time of START.

  Step 1460) The general-purpose register and the index register are restored from the register list 170.

  Step 1470) If the “replaced original machine language instruction” is 2 instructions or more, the process proceeds to step 1480, and if not, the process proceeds to step 1490.

  Step 1480) The return value of the stack on the memory is changed to the instruction next to the instruction that executes the execution history acquisition unit of the “replaced original machine language instruction”.

  Step 1490) The jmp instruction is executed for the hooked function. As a result, the execution state of the specific program is restored.

  Step 14110) In step 1420, when the record of the hooked function is registered in the debug information storage unit 160, the hook information is hooked from the debug information storage unit 160 to obtain the argument value of the executed function. Get function record and argument record of hooked function.

  Step 14120) It is determined whether or not there is an argument record for which a value has not been obtained. If there is an argument record, the process proceeds to Step 14130.

  Step 14130) Using the acquired argument record information, the value of the argument is acquired from the memory or register list 170, and the process returns to Step 14120.

Step 14140) The information regarding the executed function is registered in the execution history storage unit 180. Information to be registered
-Function name of hooked function;
The address to which the hooked function is mapped;
-Obtained arguments;
It is.

  Step 14150) Among the acquired arguments, it is determined whether there is an argument whose “value storage location” is in the memory. If there is, the process proceeds to Step 14160. Otherwise, the process proceeds to Step 14180.

  Step 14160) The value of the stack pointer register is shifted by the size in which the argument is stored.

  Step 14170) The value of the base pointer register after the next function call is estimated from the stack pointer register and stored in the memory.

  Step 14180) The execution history acquisition unit 130 determines whether there is an argument that becomes a “value storage location” that is not stored in the memory. If there is an argument, the process proceeds to Step 14190, and if not, the process proceeds to Step 14200. .

  Step 14190) Stores the value of the argument obtained from “value storage location” and the estimated value of the base pointer register at an appropriate address in the memory, and returns to Step 14180.

  Step 14200) The general-purpose register and the index register are restored from the register list 170 on the memory.

  Step 14210) A call instruction is executed for the hooked function.

  Step 14220) In order to hold the current execution state of the program, the general-purpose registers and index registers are saved in the register list 170 on the memory.

  Step 14230) The return value of the function is acquired from the general-purpose register or the floating-point register using the acquired function record.

  Step 14240) The executed function is registered in the program execution history storage unit 180. Specifically, the return value is registered in the program execution history storage unit 180 in association with the record registered in step 14140.

Step 14250) The return value of the stack on the memory is changed to the second instruction of the “original machine language instruction to be replaced”.
Step 14260) The hooked function record is read from the symbol information storage unit 150.

  Step 14270) In order to restore the execution state of the stored program, the general-purpose register and the index register are restored from the register list 170 on the memory.

  Step 14280) The ret instruction is executed, and control is transferred to the program execution unit 40.

  Further, in FIG. 4, the program is changed when the program is started, but a process of acquiring an execution history can be inserted into the execution file 10 loaded in the memory even for the program being executed. The process to insert is shown below.

  FIG. 14 is a flowchart of processing for changing an execution file of a program being executed according to an embodiment of the present invention.

  Step 1910) First, the execution file changing unit 110 stops the execution program by delivering a signal (SIGSTOP) to the program.

  Step 1920) The execution program loaded in the memory is changed.

  Step 1930) The execution file changing unit 110 delivers a signal (SIGCONT) to the program and continues the execution program.

  At this time, in the conventional debugger, a breakpoint is set in the execution file, and control is forcibly transferred to the debugger. However, the present invention changes the execution file of the program so that the program itself outputs the function execution history, thereby setting the breakpoint and outputting the function execution history. Can be shortened.

[Program execution history dividing device]
Next, the program execution history dividing device will be described.

  The program is executed using the input value that the user can assume up to the output result, and the execution history is acquired. Focusing on the call stack depth and appearance pattern of the executed function in the acquired execution history, the function call sequence local is defined as a function block.

  The execution history classification process will be described below.

  FIG. 15 shows the configuration of the program execution history dividing apparatus according to one embodiment of the present invention.

  The program execution history dividing device 200 performs a process of dividing the execution history. This category focuses on the locations where the value of the function call stack depth is small. It can be said that the function in which the value of the depth of the call stack of the stack becomes the largest compared to before and after is the process for providing the service of the program being executed. The part of the function call sequence where the depth value of the previous call stack increases can be said to be a part where the function providing the service is pre-processed. For this reason, the function call stack is divided at a portion where the depth of the call stack becomes small, and this is handled as a function block. At this time, if the same sequence exists in the sequence of function blocks, the sequence having the same one is defined as one function block. The function block is set as an output pattern of the program.

  The program execution history dividing apparatus 200 includes an execution history reading unit 210, an execution history sorting unit 220, a function block generation unit 230, and a function block registration unit 240.

  FIG. 16 is a flowchart of an outline operation of the execution history sorting unit in the embodiment of the present invention.

  Step 2310) As the loop C ′, each execution history is read from the execution history storage unit 180.

  Step 2320) The process providing the service is searched. If the search is successful, the process proceeds to Step 2330. If the search is not possible, the next execution history is read.

  Step 2330) The process providing the searched service and the pre-process are registered in the function block table 250 as one process.

  Step 2340) When the loop C ′ ends, the last process is registered in the function block table 250.

  FIG. 17 is a flowchart of the detailed operation of the execution history classification unit according to the embodiment of the present invention.

  Step 310) As initial values, id = 0 and head = 0.

  Step 320) The initial value i = 0 (increment 1) and the final value are the number of functions included in the acquired program execution history, and the following loop (loop C) processing is performed.

  Step 330) When the execution history is read from the execution history storage unit 180, the function is called (i + 1) th from the function called i-th in order to search for a process that substantially provides the service. It is determined whether the call stack of the function is shallower. If the call stack is shallow, the process proceeds to step 340. If deep, the process proceeds to step 320 until the closing price (the number of functions included in the acquired program execution history) is reached. Transition.

  Step 350) Set id = id + 1, head = i + 1, and repeat the process of Step 330.

  Step 360) The function called head to i is registered as one block in the function block table 250 with the function block ID number as id.

  As a specific example of the above, FIG. 18 shows a sample source code and how to divide a function call sequence when this code is executed. At this time, a place where the function call sequence is separated is defined as a function block.

  The function block generation unit 230 generates a function pattern to be compared. The function block created above is searched for a process executed multiple times, and the function pattern to be compared is made one function block, thereby reducing the function pattern. In addition, by making a process repeated a plurality of times into a function block, the reliability that the process is a series of processes can be improved.

  The function blocks are compared, and a function block in which the functions in the function block are the same including the order is searched. Further, with respect to the function block next to the matched function block, it is checked whether the functions in the function block are the same function block including the order, and this checking process is repeated while the function block is the same. When the same function block exists, a series of function blocks that are the same are treated as one function block. Furthermore, a function block ID that can uniquely identify the function block is assigned to the created function block. This process is shown in FIGS.

  FIG. 19 is a flowchart of an outline operation of the function block generation unit in the embodiment of the present invention.

  Step 2410) As loop D ', processing is performed for each function block created in FIG.

  Step 2420) A function block is created as a function execution pattern.

  Step 2430) The created function block is registered in the function block table 250.

  The above processing is repeated as a loop D ′ until all function blocks are processed.

  The above operation will be described in detail below.

  FIG. 20 is a flowchart of detailed operation of the function block generation unit according to the embodiment of the present invention. In the following, it is assumed that the memory in the function block generation unit 230 has a function block match list as shown in FIG.

  Step 410) Let id = the number of function blocks.

  Step 420) The initial value is i = 0 (increment 1), and the final value is id.

  Step 430) Initialize the function block match list.

  Step 440) As the initial value of the loop E, k = i (increment 1) and the final value is id.

  Step 450) The function block whose function block ID number is i and the function block whose function block ID number is k are compared, and it is determined whether the function names in the block are completely matched including the order. Control goes to step 460 and loop E is repeated.

  Step 460) As the initial value of the loop F, num = 1 (increment 1) and the final value = (k-1).

  Step 470) The function block whose function block ID number is (i + num) and the function block whose function block ID number is (k + num) are compared, and it is determined whether the function names in the block completely match, including the order. In this case, num = num + 1 is set, and the processing of loop F is repeated until the final value (num = k−1) is reached.

  Step 480) A node having registered therein a function block having an ID of k and a value of num that is the number of matched blocks is added to the function block match list, and the process of loop E is repeated until k = id.

  Step 490) It is determined whether or not there is a node in the function block match list. If there is a node, the process proceeds to Step 4100. If not, the process of Loop D is repeated until i = id.

  Step 4100) Each node in the function block match list is compared, and the function block with the function block ID number i and the longest matched function block are connected with the number of matched blocks as one block. And

  Step 4110) The block corresponding to the connected block is deleted, and the created block is registered in the function block table 250. As processing of loop D, i = i + 1 is set, and processing of loop D is repeated until i = id.

  In the function block match list shown in FIG. 21B, the search result is registered. Using this function block match list, it is determined whether or not a plurality of function blocks are combined into one. Sequence 2 in FIG. 21A is a function block sequence that is a result of combining a plurality of blocks into one block using a function block match list, and this is a function block table 250 via the function block registration unit 240. Registered in

  In the program execution history dividing apparatus 200 described above, the function call sequence executed by the program is divided into processing units that are meaningful to the user, so that the user can be informed of which process has a bug. Therefore, it is possible to narrow the range of the user to view the source code for debugging, and to help shorten the time until a bug is found.

[Program execution history comparison device]
The function block created by the program execution history dividing device 200 is defined as the execution result of the program assumed by the user. For this reason, in the function call sequence of the program in which an error occurred, a function that is different from the created function block is executed, and even in these places, there is no function that has the same function calling relationship, There is a high possibility that bugs exist in highly functional functions. This is because a program bug becomes apparent when an input value that is not assumed by the developer is input to the program. Furthermore, it becomes apparent when the performance of the computer used for program development and verification differs from the performance of the computer executing this program.

  Hereinafter, a program execution history comparison apparatus for searching for a function having high specificity will be described.

  The program execution history comparison device compares the output pattern of the program created by the program execution history dividing device 200 with the output of the program in which an error has occurred. At this time, even in the output of the program in which no output pattern exists and an error has occurred, a plurality of call patterns that do not exist are searched, and the function call pattern with a low appearance frequency is highlighted and displayed.

  FIG. 22 shows the configuration of the program execution history comparison apparatus in one embodiment of the present invention.

  The program execution history comparison apparatus 300 shown in the figure includes a function block reading unit 310, a program execution history collection unit 320, an execution history data storage unit 330, a function block and execution history comparison unit 340, a function block registration unit 350, and a function registration. Part 360 and a comparison result storage table 370.

  FIG. 23 is a diagram illustrating the operation of the program execution history comparison apparatus according to the embodiment of the present invention.

  Step 810) The function block reading unit 310 reads a table created from the function block table 250.

  Step 820) Next, when the same program as the program that created the function block is executed by the program execution unit 40, the program execution history collection unit 320 determines whether or not the execution history of the program can be acquired. The process proceeds to step 830, and if the acquisition is not possible, the program execution history and function block comparison processing is terminated.

  Step 830) The program execution history collection unit 320 acquires a program execution history.

  Step 840) The execution history data storage unit 330 acquires and stores the execution time, function name, argument, return value, and call stack depth of the acquired execution history.

  Step 850) The function block / execution history comparison unit 340 compares the read function block with the function execution sequence acquired from the execution history data storage unit 330. If they match, the process proceeds to step 860. Proceeds to step 870.

  Step 860) If they match, information about the matched function block and the functions in the function block is stored in the comparison result storage table 370.

  Step 870) If they do not match, information related to the executed function (call stack depth, function name, argument, return value) is stored in the comparison result storage table 370.

  As a result, when a program error occurs in the program being executed, a highly specific function or function block is selected from the comparison result storage table 370 and presented to the user.

  Next, a case where functions and function blocks are registered in the comparison result storage table 370 and a case where only function blocks are registered will be described.

  FIG. 24 shows an example when functions and function blocks are registered in the comparison result storage table according to the embodiment of the present invention.

  In FIG. 24, the function block and the function execution sequence are compared, and as a result, the function is found with high specificity when classified into a function block that matches and a function that does not match the function block. A function with high specificity is considered to be in a location that does not match the function block. Therefore, a highly specific function is selected from functions that do not match the function block. Also in these functions, it is searched whether or not there are execution paths having the same calling relationship. In FIG. 24, there are a part where the execution path of function A → function B is the same and a part where only function C is sandwiched between blocks. At this time, it is considered that the specificity of the function C executed only once is lower than the execution path of the function A⇒function B executed plural times. By presenting to the user in order from the part with the low specificity, the function having the bug can be presented more quickly.

  FIG. 25 shows an example when only the function block is registered in the comparison result storage table in the embodiment of the present invention.

  The example of FIG. 25 is a means for finding a highly specific function when a result of comparing a function block and a function execution sequence results in classification of the function block only. Search for the function block with the minimum number of executions. In FIG. 25, among the function blocks A, B, and C, the function block C has the smallest number of executions. Therefore, it can be defined that the specificity of the function block C is high. The determination of which function in the function block C has high specificity is made by comparing arguments and return values, and determining whether each value is the same as the value registered in the function block table 250 or not. Judge the height of sex.

  The program execution history dividing apparatus 200 acquires an execution history executed by an input value that can be assumed by the user up to an output result, and detects an output pattern of the program execution history. Next, the program execution history comparison apparatus 300 searches for the output pattern of the program created by the program execution history dividing apparatus 200 and the function call pattern having a low appearance frequency even during the output of the program in which an error has occurred. Highlight function call patterns. As a result, the time from when an error occurs until a bug in the source code corresponding to the error is found can be shortened without depending on the skill of the user who performs debugging.

  Note that the program execution history collection device, the program execution history division device, and the program execution history comparison device can be constructed as one debug support device.

  Also, the operations of the program execution history collection device, the program execution history division device, and the program execution history comparison device are constructed as a program and used as a device comprising the program execution history collection device, the program execution history division device, and the program execution history comparison device. It can be installed on a computer and executed, or distributed via a network.

  Further, the constructed program can be stored in a portable storage medium such as a hard disk device or a flexible disk / CD-ROM, and can be installed or distributed in a computer.

  The present invention is not limited to the above-described embodiment, and various modifications and applications can be made within the scope of the claims.

  The present invention is applicable to debugging in program development / execution.

  Further, the present invention can also be applied to a technique for automatically detecting occurrence of degration by detecting a difference in the program operation before and after the program version upgrade, or before and after the program operating environment change.

It is a principle block diagram of this invention. It is a figure for demonstrating the principle of this invention. It is a block diagram of the program execution log | history collection apparatus in one embodiment of this invention. It is a flowchart of the execution file change process in one embodiment of this invention. It is a flowchart of outline | summary operation | movement of the executable file change part in one embodiment of this invention. It is a flowchart of detailed operation | movement of the executable file change part in one embodiment of this invention. It is an example of the data stored in the symbol information storage part in one embodiment of this invention. It is a flowchart of outline | summary operation | movement of the debug information acquisition part in one embodiment of this invention. It is a flowchart of detailed operation | movement of the debug information acquisition part in one embodiment of this invention. It is an example of the debug information (input value with respect to FIG. 9) added in one embodiment of the present invention. It is the data stored in the debug information storage part in one embodiment of this invention. It is a flowchart of outline | summary operation | movement of the execution history collection part in one embodiment of this invention. It is a flowchart of detailed operation | movement of the execution log | history collection part in one embodiment of this invention. It is a flowchart of the process which changes the execution file of the program in execution in one embodiment of this invention. It is a block diagram of the program execution history division | segmentation apparatus in one embodiment of this invention. It is a flowchart of the outline | summary operation | movement of the execution log | history classification part in one embodiment of this invention. It is a flowchart of detailed operation | movement of the execution log | history classification part in one embodiment of this invention. It is an example of how to divide the function call sequence of the execution history section in one embodiment of the present invention. It is a flowchart of outline | summary operation | movement of the function block generation part in one embodiment of this invention. It is a flowchart of detailed operation | movement of the function Brook production | generation part in one embodiment of this invention. It is an example of the function block production | generation in one embodiment of this invention. It is a block diagram of the program execution log | history comparison apparatus in one embodiment of this invention. It is a flowchart of outline | summary operation | movement of the program execution log | history comparison apparatus in one embodiment of this invention. It is an example at the time of a function and a function block being registered into the comparison result storage table in one embodiment of this invention. It is an example when only a function block is registered in the comparison result storage table in one embodiment of the present invention.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Execution file loaded in memory 20 Program execution file 30 Library execution file 40 Program execution means, program execution section 100 Program execution history collection means, program execution history collection apparatus 110 Execution file change section 120 Debug information acquisition section 130 Execution History collection unit 140 Executable file list (memory or disk) for acquiring execution history
150 Symbol information storage (memory)
160 Debug information storage (memory)
170 Register list (memory)
180 execution history storage unit, execution history storage unit 200 program execution history division unit, program execution history division unit 210 execution history reading unit 220 execution history division unit 230 function block generation unit 240 function block registration unit 250 function block storage unit, function block Table 300 Comparison means, program execution history comparison device 310 Function block reading unit 320 Program execution history collection unit 330 Execution history data storage unit 340 Function block and execution history comparison unit 350 Function block registration unit 360 Function registration unit 370 Comparison result storage unit Comparison result storage table

Claims (9)

A program operation comparison device for finding a difference in program operation,
Program execution means for executing the program;
Program execution history collection for changing the execution file of the program so that the program itself can output the function execution history, and acquiring the execution history of the executed program by the program execution means and storing it in the execution history storage means Means,
Program execution in which the execution history of the program in the execution history storage means is stored in the function block storage means by dividing the local area of the function call sequence as a function block based on the depth of the function call stack of the executed program and the appearance pattern History dividing means;
A comparison means for comparing the function block of the function block storage means with a function call sequence of a program being executed by the program execution means, detecting a different location, and storing the comparison result in the comparison result storage means;
A program operation comparison device comprising: The program execution history collection means includes
Execution file changing means for changing an execution file of a program for collecting information about the function with respect to a function acquired as an execution history of the program,
Debug information acquisition means for acquiring values necessary for acquiring detailed information about the function to be acquired;
For functions defined in the execution file of the program or functions of the shared library specified by the user, the time when the program was executed by the program execution means, function name, argument, call stack depth value, return Execution history collection means for acquiring information including a value and registering the acquired information in the execution history storage means;
The program operation comparison apparatus according to claim 1, comprising: The program execution history dividing means is
Read the history information stored in the execution history storage means, pay attention only to the function call, delimit when the call stack depth value of the called function becomes small, and separate the delimited position into one function Execution history classification means as a block;
A search is performed to determine whether there is a function block in which the function in the function block is the same including its execution order. If there is, the function in the function block is the same including the execution order for the next function block. If there is a function block that is identical, a plurality of function blocks are grouped as one function block with respect to the function block having the longest series of lengths. Means for registering in the storage means;
Registers in the function block storage means associated with a function whether the function argument and return value in the function block are the same in all functions, whether there is a function having the same value, or is different in all functions Means to
The program operation comparison apparatus according to claim 1, comprising: The comparison means includes
By reading the function block from the function block storage unit and comparing the function block with the function call sequence of the program being executed by the program execution unit, the operation of the program being executed is assumed to be an operation assumed by the user. Means for detecting different locations;
By comparing the information about the executed function in the function block with the information about the function executed by the program being executed when a different part cannot be detected by comparing only the function call sequence, the Means for detecting a location where the operation of the program being executed differs from the operation assumed by the user;
The program operation comparison apparatus according to claim 1, comprising: A program operation comparison method for finding a difference in program operation,
Program execution that changes the execution file of the program so that the program itself can output the function execution history, and acquires the execution history of the executed program and stores it in the execution history storage means by the function of executing the program A history collection step;
Program execution in which the execution history of the program in the execution history storage means is stored in the function block storage means by dividing the local area of the function call sequence as a function block based on the depth of the function call stack of the executed program and the appearance pattern History splitting step;
A comparison step of comparing the function block of the function block storage unit with a function call sequence of a program being executed by a function of executing the program, detecting a different portion, and storing the comparison result in the comparison result storage unit;
The program operation comparison method characterized by performing. In the program execution history collection step,
For a function acquired as a program execution history, an execution file change step for changing a program execution file for acquiring the function;
Debug information acquisition step to acquire the time when returning from the called function to the caller, arguments changed in the called function, return value,
The time, function name, argument, and call stack depth values when the program is executed by the function that executes the program for the functions defined in the execution file of the program or the functions of the shared library specified by the user , An execution history collection step of acquiring information including a return value and registering the acquired information in an execution history storage unit;
6. The program operation comparison method according to claim 5, wherein: In the program execution history division step,
Read the history information stored in the execution history storage means, pay attention only to the function call, delimit when the call stack depth value of the called function becomes small, and separate the delimited position into one function Execution history classification step to be a block;
A search is performed to determine whether there is a function block in which the function in the function block is the same including its execution order. If there is, the function in the function block is the same including the execution order for the next function block. If there is a function block that is identical, a plurality of function blocks are grouped as one function block with respect to the function block having the longest series of lengths. Registering in the storage means;
Registers in the function block storage means associated with a function whether the function argument and return value in the function block are the same in all functions, whether there is a function having the same value, or is different in all functions And steps to
6. The program operation comparison method according to claim 5, wherein: In the comparison step,
By reading the function block from the function block storage unit and comparing the function call sequence of the program being executed by the function to execute the program with the function block, the operation of the program being executed is assumed by the user. Detecting a point different from the movement;
When a different part cannot be detected by comparing only the function call sequence, the argument and return value of the executed function in the function block are compared with the argument and return value of the function executed by the executing program. A step of detecting a location where the operation of the program being executed differs from the operation assumed by the user;
6. The program operation comparison method according to claim 5, wherein:   The program operation comparison program for functioning a computer as each means which comprises the program operation comparison apparatus of any one of Claims 1 thru | or 4.

Images