JP2020013385A - Information processing apparatus, patch application confirming system, patch application confirming method, and patch application confirming program - Google Patents

Abstract

To make it possible to determine whether or not a patch has been applied.SOLUTION: An information processing apparatus 10 stores a source file 2 which is a target of application of a patch for changing a part of instruction string to a correction instruction string 1a. The information processing apparatus 10 generates patch instruction kind information 3 indicating an instruction kind of each instruction in the correction instruction string 1a based on the patch file 1 including the correction instruction string 1a. Next, the information processing apparatus 10 generates source instruction kind information 4 indicating an instruction kind of each instruction in the source file 2. Further, the information processing apparatus 10, based on the patch instruction kind information 3 and the source instruction kind information 4, extracts, from the source file 2, a kind-matched instruction string 2a having the same arraying order of the instruction kind as that of the correct instruction string 1a. The information processing apparatus 10 determines, based on description contents of the kind-matched instruction string 2a and the correction instruction string 1a excluding a variable name and a function name, whether the patch has been already applied to the source file 2.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an information processing apparatus, a patch application confirmation system, a patch application confirmation method, and a patch application confirmation program.

  In recent years, the application of open source software (OSS: Open Source Software) to commercial systems has become popular. When constructing a system using the OSS, the system administrator builds, for example, the source code of the OSS, generates executable software, and introduces the software into the system.

  When a vulnerability of the OSS is found, the system administrator obtains a patch program for correcting the OSS (hereinafter, referred to as a correction patch) and corrects the OSS. Various correction patches are applied to the system. Therefore, in order to operate the system safely, the administrator of the system manages whether or not various correction patches are applied to the system. The OSS differs from the distribution in which the vulnerability management can be performed by the package management tool, and the vulnerability management tool is not sufficiently prepared. Therefore, the system administrator collects the patch information released by the provider and independently manages whether or not to apply the vulnerability patch.

  When introducing the OSS into the system, software development support technology can be used. As a technique related to software development support, for example, in a work of combining a plurality of software components, the amount of work performed by a person to maintain consistency in handling of functions that are disclosed and referred to among the plurality of software is reduced. There is a software development support system.

  There is also a technique for visualizing patch application. For example, there is a software development support method for presenting a modification candidate portion based on the likelihood of a change when reflecting a changed portion due to a version change of the reference source code in a customized reference source code.

JP-A-2004-362048 JP 2017-045354 A

  In a system in which the OSS source code is built and used, there is a problem that it takes a long time to investigate the application status of a correction patch for dealing with a vulnerability. One of the factors is that the OSS may be operated by changing the variable name or the function name.

  For example, when a line containing a variable name or function name is deleted or added in a patch, if the source code is searched by the variable name or function name, a line that is corrected by applying the patch can be easily found. be able to. However, if the OSS patch is applied by rewriting the variable name or function name of the OSS patch according to the naming rules on the program side, the search by the variable name or function name in the source code will not be performed. , It is not possible to extract the location where the patch is applied. In this case, the administrator has to check the source code in detail to determine whether or not a patch has been applied, and it takes a long time to investigate.

  In one aspect, an object of the present invention is to be able to determine whether or not a patch has been applied.

In one proposal, an information processing apparatus having a storage unit and a processing unit described below is applied.
The storage unit stores a source file to which a patch for changing a part of the instruction sequence to the correction instruction sequence is applied. The processing unit generates patch instruction type information indicating the instruction type of each instruction in the correction instruction sequence based on the patch file including the correction instruction sequence. Next, the processing unit generates source instruction type information indicating the instruction type of each instruction in the source file. Further, the processing unit extracts, from the source file, a type matching instruction sequence in which the order of the correction instruction sequence and the instruction type matches based on the patch instruction type information and the source instruction type information. Then, the processing unit determines whether a patch has been applied to the source file based on the description content of the type matching instruction sequence and the correction instruction sequence excluding the variable name and the function name.

  According to one aspect, it is possible to determine whether or not a patch has been applied.

FIG. 7 is a diagram illustrating an example of a patch application confirmation method according to the first embodiment. FIG. 14 is a diagram illustrating an example of a patch application confirmation system according to a second embodiment. FIG. 3 is a diagram illustrating an example of computer hardware. It is a block diagram which shows an example of a correction patch application visualization function. It is a figure showing an example of a correction patch. FIG. 4 is a diagram illustrating an example of a source file. FIG. 4 is a diagram illustrating an example of a fixed keyword dictionary. FIG. 14 is a diagram illustrating an example of determining an instruction type for a correction patch. FIG. 14 is a diagram illustrating an example of an instruction type determination process of a correction patch using an array. FIG. 9 is a diagram illustrating an example of determining a command type for a source file. FIG. 14 is a diagram illustrating an example of a source file instruction type determination process using an array. FIG. 9 is a diagram illustrating an example of a patch introduction location estimation process. It is a figure showing an example of matching processing. FIG. 9 is a diagram illustrating an example of a matching process using an array. It is a figure showing an example of a matching result. FIG. 11 is a diagram illustrating an example of storing correspondences between variable keywords. It is a figure showing an example of similarity calculation processing. FIG. 6 is a diagram illustrating an example of patch application information. It is a figure showing an example of a result display screen. It is a flowchart which shows an example of the procedure of a correction patch application visualization process. It is a flowchart which shows an example of the procedure of instruction type determination processing. It is the first half of the flowchart which shows the details of the procedure of the instruction type information acquisition processing. It is the latter half of the flowchart showing the details of the procedure of the command type information acquisition processing. It is a flowchart which shows an example of the procedure of a patch introduction part estimation process. It is a flowchart which shows an example of the procedure of a matching process. It is a flowchart which shows an example of the procedure of a similarity calculation process. It is a flowchart which shows an example of the procedure of a result output process.

Hereinafter, the present embodiment will be described with reference to the drawings. Note that each embodiment can be implemented by combining a plurality of embodiments within a consistent range.
[First Embodiment]
First, a first embodiment will be described.

  FIG. 1 is a diagram illustrating an example of the patch application confirmation method according to the first embodiment. In the example of FIG. 1, the patch application confirmation method is performed using the information processing device 10. The information processing device 10 includes a storage unit 11 and a processing unit 12. The storage unit 11 is, for example, a memory or a storage device included in the information processing device 10. The processing unit 12 is, for example, a processor or an arithmetic circuit included in the information processing device 10. The information processing apparatus 10 can execute the patch application confirmation method by causing the processing unit 12 to execute a patch application confirmation program that describes, for example, a processing procedure of the patch application confirmation method.

The storage unit 11 stores a source file 2 to which a patch for changing a part of the instruction sequence to the modified instruction sequence 1a is applied.
The processing unit 12 generates patch instruction type information 3 indicating the instruction type of each instruction in the correction instruction sequence 1a based on the patch file 1 including the correction instruction sequence 1a. For example, the patch file 1 defines which instructions in the source file 2 are deleted and what instructions are added. By analyzing the patch file 1, the processing unit 12 determines what kind of instruction sequence the part corrected by the patch in the source file 2 becomes after application of the patch, and converts the instruction sequence into a modified instruction sequence. 1a. Further, the processing unit 12 generates source instruction type information 4 indicating the instruction type of each instruction in the source file 2. The instruction types include “declaration” for defining a variable type, “condition” for defining an execution condition of processing, and “assignment” for setting a value to a variable or an element of an array.

  Next, based on the patch instruction type information 3 and the source instruction type information 4, the processing unit 12 determines, in the source file 2, the position of the type matching instruction sequence 2a (instruction Type match). The instruction type matching position is indicated, for example, by the range of the line of the source code in the source file 2 (from what line to what line). Then, the processing unit 12 extracts, from the source file 2, the type matching instruction sequence 2a described in the instruction type matching location.

  The processing unit 12 determines whether a patch has been applied to the source file 2 based on the description contents of the type matching instruction sequence 2a and the correction instruction sequence 1a excluding the variable name and the function name. For example, the processing unit 12 calculates the similarity between the description content of the type matching instruction sequence 2a excluding the variable name and the function name and the description content of the correction instruction sequence 1a excluding the variable name and the function name. Then, the processing unit 12 determines whether a patch has been applied to the source file 2 based on the calculated similarity.

  In the similarity calculation, for example, the processing unit 12 sequentially assigns a line number to each instruction line of the type matching instruction sequence 2a and the correction instruction sequence 1a from the top. Then, the processing unit 12 determines the similarity of the description of the lines having the same line number, and sets the ratio of the lines determined to match as the similarity.

  In determining the identity between lines, for example, the processing unit 12 compares words in the line to be compared sequentially from the beginning of the line. At that time, the processing unit 12 determines that the words match if, for example, at least the types of the words are the same. Further, the processing unit 12 may determine that the words match if not only the type of the word but also the characters or symbols of the word are completely the same. Further, the processing unit 12 determines, based on the type of the word, a determination method to be adopted among a method of determining a match if the types are the same and a method of determining a match if the characters or symbols are completely the same. You may decide. For example, when the type of a word is a variable type, if the type is the same, the processing unit 12 determines that the words match, and when the type of the word is an operator such as an arithmetic operator, the characters or symbols are completely the same. If so, it is determined that the words match.

  A keyword dictionary can be used to determine the type of word. For example, the storage unit 11 stores a keyword dictionary including a list of words to be compared in determining the identity between lines. The processing unit 12 includes a word included in the keyword dictionary in the first line of the type matching instruction sequence 2a and a word included in the keyword dictionary in the second line having the same line number as the first line in the correction instruction sequence 1a. Are compared to determine the identity between rows having the same row number.

  When determining whether or not to apply a patch based on the similarity, the processing unit 12 determines that the patch has been applied to the source file 2 if the similarity is 100%. If the similarity is equal to or greater than the preset threshold, the processing unit 12 determines that there is a high possibility that the source file 2 has a patch applied. Further, if the similarity is less than the threshold, the processing unit 12 determines that the patch has not been applied to the source file 2.

  In this way, it is possible to determine whether or not to apply a patch, excluding words that have a high degree of freedom of change, such as variable names and function names, and that can be freely changed by the system administrator. That is, the processing unit 12 extracts, from the source file 2, the type-matching instruction sequence 2a having the same instruction sequence as the correction instruction sequence 1a, so that a portion that is likely to be modified by applying a patch can be appropriately extracted. Then, the type matching instruction sequence 2a, which is likely to be modified by the patch application, is compared with the modification instruction sequence 1a to determine whether or not the patch is applied, thereby excluding the variable names and the function names. However, the determination can be made with high accuracy.

  In addition, the processing unit 12 may change the word in the same type, such as a change in the definition of the type of the variable type, such that the algorithm of the processing in the program does not change if the type is the same. It can be determined that they match. As a result, the accuracy of determining whether a patch has been applied is improved. For example, in the example of FIG. 1, the first word in the first line of the correction instruction sequence 1a is a variable-type word “short”. On the other hand, the first word in the first line of the type matching instruction sequence 2a is a variable-type word “int”. The word “short” and the word “int” are designations of a type called an integer type among the variable types, and only differ in the size of the value stored in the variable. Such a change of the variable type may be performed by the user of the information processing apparatus 10 independently. Therefore, if the type of the variable type word is the same in the variable type, the processing unit 12 may determine that the words or symbols are not the same even in the comparison at the time of calculating the similarity, even if the characters or symbols are not the same. . As a result, even when the change of the variable type is changed in the source file 2, it is possible to correctly determine whether or not the patch is applied.

[Second embodiment]
Next, a second embodiment will be described. In the second embodiment, the application status of a correction patch on a computer using the OSS is visualized.

  FIG. 2 is a diagram illustrating an example of a patch application confirmation system according to the second embodiment. The computer 100 using the OSS is connected to the server 200 via the network 20. The server 200 is a computer that distributes a correction patch.

  The computer 100 determines whether or not a correction patch is applied to the source file based on the similarity between the correction patch released by the OSS community using the server 200 and the source file.

  For example, if the vulnerability of the OSS introduced in the computer 100 can be corrected by the patch distributed on the server 200, the administrator of the computer 100 checks whether the patch has been applied to the computer 100 or not. It will be. At this time, the administrator executes the patch application confirmation program on the computer 100 to cause the computer 100 to visualize the application status of the correction patch. The administrator checks the contents of the source code with reference to the application status of the visualized patch, for example, and checks whether the patch is correctly applied.

  FIG. 3 is a diagram illustrating an example of computer hardware. The computer 100 is entirely controlled by a processor 101. The processor 102 is connected to the memory 102 and a plurality of peripheral devices via a bus 109. Processor 101 may be a multiprocessor. The processor 101 is, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), or a DSP (Digital Signal Processor). At least a part of the function realized by the processor 101 executing the program may be realized by an electronic circuit such as an ASIC (Application Specific Integrated Circuit) or a PLD (Programmable Logic Device).

  The memory 102 is used as a main storage device of the computer 100. The memory 102 temporarily stores at least a part of an OS (Operating System) program and an application program to be executed by the processor 101. Further, the memory 102 stores various data used for processing by the processor 101. As the memory 102, for example, a volatile semiconductor storage device such as a RAM (Random Access Memory) is used.

  The peripheral devices connected to the bus 109 include a storage device 103, a graphic processing device 104, an input interface 105, an optical drive device 106, a device connection interface 107, and a network interface 108.

  The storage device 103 electrically or magnetically writes and reads data on a built-in recording medium. The storage device 103 is used as an auxiliary storage device of a computer. The storage device 103 stores OS programs, application programs, and various data. As the storage device 103, for example, a hard disk drive (HDD) or a solid state drive (SSD) can be used.

  The monitor 21 is connected to the graphic processing device 104. The graphic processing device 104 displays an image on the screen of the monitor 21 according to a command from the processor 101. Examples of the monitor 21 include a display device using an organic EL (Electro Luminescence) and a liquid crystal display device.

  The keyboard 22 and the mouse 23 are connected to the input interface 105. The input interface 105 transmits a signal transmitted from the keyboard 22 or the mouse 23 to the processor 101. The mouse 23 is an example of a pointing device, and another pointing device can be used. Other pointing devices include touch panels, tablets, touchpads, trackballs, and the like.

  The optical drive device 106 reads data recorded on the optical disk 24 using laser light or the like. The optical disk 24 is a portable recording medium on which data is recorded so as to be readable by light reflection. The optical disc 24 includes a DVD (Digital Versatile Disc), a DVD-RAM, a CD-ROM (Compact Disc Read Only Memory), a CD-R (Recordable) / RW (ReWritable), and the like.

  The device connection interface 107 is a communication interface for connecting a peripheral device to the computer 100. For example, the memory device 25 and the memory reader / writer 26 can be connected to the device connection interface 107. The memory device 25 is a recording medium having a communication function with the device connection interface 107. The memory reader / writer 26 is a device that writes data to the memory card 27 or reads data from the memory card 27. The memory card 27 is a card-type recording medium.

  The network interface 108 is connected to the network 20. The network interface 108 transmits and receives data to and from another computer or communication device via the network 20.

  The computer 100 can realize the processing functions of the second embodiment with the above hardware configuration. Note that the server 200 can also be realized by the same hardware as the computer 100 shown in FIG. Further, the information processing apparatus 10 described in the first embodiment can also be realized by the same hardware as the computer 100 illustrated in FIG.

  The computer 100 realizes the processing functions of the second embodiment, for example, by executing a program recorded on a computer-readable recording medium. The program describing the processing to be executed by the computer 100 can be recorded on various recording media. For example, a program to be executed by the computer 100 can be stored in the storage device 103. The processor 101 loads at least a part of the program in the storage device 103 into the memory 102 and executes the program. Further, the program to be executed by the computer 100 may be recorded on a portable recording medium such as the optical disk 24, the memory device 25, and the memory card 27. The program stored in the portable recording medium becomes executable after being installed in the storage device 103 under the control of the processor 101, for example. Further, the processor 101 can also read out the program directly from the portable recording medium and execute the program.

The computer 100 has a correction patch application visualization function for visualizing whether or not a correction patch has been applied.
FIG. 4 is a block diagram illustrating an example of the correction patch application visualization function. The computer 100 can acquire the installed patch of the OSS from the repository 210 of the server 200 and visualize whether or not the acquired patch has been applied. In order to visualize whether or not a correction patch has been applied, the computer 100 has the components shown in FIG. That is, the computer 100 includes a source file storage unit 110, a fixed keyword dictionary storage unit 120, a similarity threshold storage unit 130, a source code acquisition unit 141, an instruction type determination unit 142, an instruction type storage unit 143, a patch introduction location estimation unit 144, It has a patch introduction estimated location storage unit 145, a matching processing unit 146, a matching result storage unit 147, a similarity calculation unit 148, a similarity storage unit 149, a result output unit 150, and a patch application information storage unit 151.

  The source file storage unit 110 stores a source file in which the OSS source code is described. The source file is stored in the source file storage unit 110 in advance before the start of the correction patch application visualization processing. Note that in the OSS source code described in the source file, variable names and function names may be changed.

  The fixed keyword dictionary storage unit 120 stores a fixed keyword dictionary. The fixed keyword dictionary is information indicating words corresponding to the fixed keywords when words included in the source code are classified into fixed keywords and variable keywords. A fixed keyword is a word, such as an arithmetic operator, that changes the processing content of the program indicated by the source file when changed. Characters that cannot be replaced with other characters due to the specification of the programming language, such as “;” indicating the end of the instruction, are also fixed keywords. A variable keyword is a word, such as a variable name or a function name, that does not change the processing content of the program indicated by the source file even if it is changed.

  The fixed keyword dictionary indicates the type of each word (variable type, conditional operator, etc.). The fixed keyword dictionary is stored in the fixed keyword dictionary storage unit 120 in advance before the correction patch application visualization process starts.

  The similarity threshold value storage unit 130 stores a similarity threshold value for determining whether a modified patch introduction estimated location is partially matched or not matched. The threshold value of the similarity is, for example, “50%”. The similarity threshold is stored in the similarity threshold storage unit 130 in advance before the correction patch application visualization processing is started.

  The source code acquisition unit 141 acquires a correction source code described in a patch file indicating a patch to be applied and a source code of an OSS to which the patch is applied. For example, the source code obtaining unit 141 obtains a correction source code of a correction patch from the repository 210 in the server 200 via the network 20. Further, the source code acquisition unit 141 acquires, from the source file in the source file storage unit 110, the source code of the OSS to which the correction patch is applied.

  The instruction type determination unit 142 determines an instruction type for each line for each of the correction source code of the correction patch and the source code in the OSS source file based on the type of the word indicated in the fixed keyword dictionary. I do. The instruction type determination unit 142 stores the instruction type determination result in the instruction type storage unit 143.

The instruction type storage unit 143 stores an instruction type for each line of a correction source code of a correction patch and an OSS source code.
The patch introduction location estimation unit 144 specifies a patch introduction estimation location in the OSS source code based on the instruction type of each line of the source code of the correction patch and the OSS source code. The estimated patch introduction location is a portion of the OSS source code that may be modified based on the modified patch. The patch introduction location estimation unit 144 stores information indicating the patch introduction estimation location in the patch introduction estimation location storage unit 145.

The estimated patch introduction location storage unit 145 stores information indicating the estimated patch introduction location.
The matching processing unit 146 refers to the fixed keyword dictionary, compares the fixed keyword in each line of the estimated patch introduction location with the fixed keyword in each line of the correction source code of the correction patch, and determines the match / mismatch of each line. The matching processing unit 146 stores the matching / mismatch determination result (matching result) in the matching result storage unit 147.

The matching result storage unit 147 stores the matching result.
The similarity calculation unit 148 calculates the similarity between the estimated patch introduction location and the corrected patch based on the matching result. Then, the similarity calculating section 148 ranks the similarities based on the calculated similarities. For example, when the similarity of the estimated patch introduction location is 100% identical, the similarity calculation unit 148 determines that the estimated patch introduction location is a perfect match. Further, based on the similarity threshold stored in the similarity threshold storage unit 130, if the similarity of the patch introduction estimated location is equal to or greater than the threshold, the similarity calculation unit 148 determines the similarity high ( (Partial match). When the similarity of the estimated patch introduction location is less than the threshold, the similarity calculation unit 148 determines that the estimated patch introduction location does not match. The similarity calculation unit 148 stores the calculated similarity and the rank of the similarity in the similarity storage unit 149.

The similarity storage unit 149 stores the similarity of the estimated patch introduction location and the rank of the similarity.
The result output unit 150 generates, for each OSS source file, patch application information indicating the status of application of the modified patch to the source file for each OSS source file based on the similarity of the estimated patch introduction location stored in the similarity storage unit 149. I do. Further, the result output unit 150 may generate comparison information between the source code of the estimated patch introduction location and the correction source code of the correction patch. Then, the result output unit 150 stores the patch application information or the comparison information of the source code in the patch application information storage unit 151. The result output unit 150 can also display the patch application information or the comparison information of the source code on the monitor 21.

  The lines connecting the elements shown in FIG. 4 show a part of the communication path, and a communication path other than the illustrated communication path can be set. The function of each element shown in FIG. 4 can be realized by, for example, causing a computer to execute a program module corresponding to the element.

Next, the modified patches stored in the repository 210 of the server 200 will be specifically described.
FIG. 5 is a diagram illustrating an example of the correction patch. The repository 210 stores a plurality of modified patches 211, 212,... Each of the correction patches 211, 212,... Describes a correction source code indicating the contents of correction of the OSS source file. In the modified patches 211, 212,..., A line whose first character is “+” indicates that a character string following “+” in the line is added to the source file. In the modified patches 211, 212,..., A line whose first character is "-" indicates that a line corresponding to a character string following "-" of the line is deleted from the source file. .

Next, the source file stored in the source file storage unit 110 will be specifically described.
FIG. 6 is a diagram illustrating an example of the source file. The source file storage unit 110 stores a plurality of source files 111, 112,... The source code described in each of the source files 111, 112,... May have been rewritten with variable names and function names with respect to the original source files generally distributed. For example, “int” in the source file 111 is rewritten from “short” in the original source file.

  Thus, the source code in the source files 111, 112,... May be rewritten. In this case, when determining whether or not to apply to each of the source files 111, 112,..., Even if a search is made for a correction portion using a search key including a variable name or a function name, the correction portion is appropriately detected. Can not do. Therefore, the computer 100 extracts a variable name or a function name from the source code, analyzes a description other than the variable name or the function name, and determines whether a correction patch is applied. For example, the computer 100 uses a fixed keyword dictionary to determine whether a correction patch has been applied.

Next, the fixed keyword dictionary stored in the fixed keyword dictionary storage unit 120 will be specifically described.
FIG. 7 is a diagram illustrating an example of the fixed keyword dictionary. The fixed keyword dictionary 121 has, for example, a tabular data structure. In the 0th column of each row of the fixed keyword dictionary 121, the type (word type) of a word (including a symbol) used in the source code is set. For example, there are word types such as “variable type”, “arithmetic operator”, “relational operator”, “conditional operator”, “symbol / quote”, and “other”. In the second and subsequent columns of each row of the fixed keyword dictionary 121, a word corresponding to the word type set in that row is set.

The word type “variable type” is a word indicating a variable type (character type, integer type, floating point type, etc.), and corresponds to a word indicating a type name such as “int” or “short”.
The word type “arithmetic operator” is a word indicating an arithmetic operation, and corresponds to a symbol such as “+”, “−”, “*”, “/”, “%”.

The word type “relation operator” is a word for determining the relationship between two objects, for example, “=”, “>”, “<”, “≠”, “==”, “! =”, And the like. Symbol is applicable.
The word type “conditional operator” is a word used to define a branch condition of a process, and corresponds to, for example, a word such as “if”, “while”, or “for”.

The word type "symbol / quotation mark" is a word indicating that the following character is a symbol or a quotation mark, and corresponds to a symbol such as "", "$", "'", and the like.
The word type “others” is a fixed keyword other than the above word types, and corresponds to a symbol such as “(”, “)”.

  The fixed keyword dictionary 121 is used for determining the instruction type of each line of the source code and determining whether each word is a fixed keyword or a variable keyword. The determination of the instruction type is performed for each of the patch to be checked for the presence or absence of application and the source file to which the patch is applied.

  FIG. 8 is a diagram illustrating an example of an instruction type determination for a corrected patch. The source code acquisition unit 141 acquires, from the repository 210, the correction patch 211 to be checked for the application, and transmits the acquired correction patch 211 to the instruction type determination unit 142. Then, the instruction type determination unit 142 determines the instruction type of each line of the source code in the correction patch 211.

  For example, the instruction type determination unit 142 performs editing for deleting the description in the correction patch 211 that is unnecessary for the type determination, for the type determination. For example, the instruction type determination unit 142 performs the following editing processing.

  (Edit # 1) The instruction type determination unit 142 deletes a line whose head is “-”. As a result, the line of the instruction to delete the line is deleted from the correction patches 211, 212,..., And the determination of the instruction type for the line is not performed.

(Edit # 2) The instruction type determination unit 142 deletes the character “+” at the beginning of the line “+”.
The instruction type determination unit 142 determines the instruction type of each line of the source code included in the edited correction patch 211a based on the fixed keyword dictionary 121 based on the following criteria. The number shown at the beginning of each line of the correction patch 211a is the line number of the line for which the instruction type is to be determined, and is given for explanation.

(Determination # 1) The instruction type determination unit 142 skips processing of a comment line such as a blank line or # without performing determination of the instruction type.
(Determination # 2) The instruction type determination unit 142 refers to the word type (variable type, arithmetic operator, etc.) registered in the fixed keyword dictionary 121, and sets the word at the beginning of the line to the word registered in “variable type”. If they match, the instruction type of the corresponding line is determined to be “declaration”.

  (Determination # 3) The instruction type determination unit 142 refers to the word type (variable type, arithmetic operator, etc.) registered in the fixed keyword dictionary 121, and the word at the beginning of the line is registered as a “conditional operator”. If the word matches, the instruction type of the corresponding line is determined as “condition”.

  (Determination # 4) The instruction type determination unit 142 determines that the word at the beginning of the line does not match a word registered in any of “variable type” and “conditional operator”, and “=” appears in the line. In this case, the instruction type of the corresponding line is determined as “assignment”.

(Determination # 5) The instruction type determination unit 142 determines that the instruction type of the row that does not correspond to any of the determinations # 1 to # 4 is “other”.
Thereby, the instruction type information 31 corresponding to the correction patch 211a is generated. The instruction type determination unit 142 stores the generated instruction type information 31 in the instruction type storage unit 143. For example, the instruction type determination unit 142 stores the instruction type of each row as an element of the patch meaning array 143a provided in the instruction type storage unit 143.

  FIG. 9 is a diagram illustrating an example of a correction patch instruction type determination process using an array. For example, the instruction type determination unit 142 defines a work array “tmp_mean_extract []”. The value of the index in the working array is a number indicating the order of words in the row to be determined. Numbers indicating the order of words are assumed to be assigned numbers in ascending order from 0, in order from the head of the line.

  For example, when determining the instruction type of the first line of the correction patch 211a, the instruction type determination unit 142 stores each word in the determination target line in the work array. For example, when determining the instruction type of “short ans = −1;”, the words “short”, “ans”, “=”, “−1”, “;” are stored in the work array. The work array is initialized each time a row to be determined is updated.

  The instruction type determination unit 142 determines which of the determination conditions # 1 to # 5 is satisfied for the word stored in the work array. For example, the instruction type determination unit 142 refers to the fixed keyword dictionary 121 and recognizes that the word type of the first word “short” of the line to be determined is “variable type”. As a result, the instruction type determination unit 142 determines that the row to be determined satisfies the condition of determination # 2. Note that “=” appears in the row to be determined, but in determination # 4, the condition is that the first word is neither “variable type” nor “conditional operator”. The judgment # 4 is not satisfied. Therefore, the instruction type determination unit 142 determines that the instruction type of this line is “declaration”.

  The instruction type determination unit 142 stores the determination result in the patch meaning array 143a “patch_mean_extract []”. The index value of the patch meaning array 143a is the row number of the row to be determined in the modified patch 211a after editing. The line numbers are assumed to be assigned numbers in ascending order from 0 to each line other than a blank line or a comment line in order from the top line. For example, the instruction type of the first line (line number “0”) in the correction patch 211a is stored in the patch meaning array 143a as an element of the index value “0”.

Similarly, the instruction type is also determined for the source file for which the determination of whether the correction patch 211 has been applied is made.
FIG. 10 is a diagram illustrating an example of the instruction type determination for a source file. The instruction type determination unit 142 acquires the source file 111 to be determined from the source file storage unit 110, and determines the instruction type for each line of the source code in the source file 111. The number shown at the beginning of each line of the source file 111 is the line number of the line for which the instruction type is to be determined, and is provided for explanation.

  For example, the instruction type determination unit 142 performs the determinations # 1 to # 5 in the same manner as the instruction type determination for the corrected patch, and generates the instruction type information 32 corresponding to the source file 111. Then, the instruction type determination unit 142 stores the generated instruction type information 32 in the instruction type storage unit 143. For example, the instruction type determination unit 142 stores the instruction type of each row as an element of the source meaning array 143b provided in the instruction type storage unit 143.

  FIG. 11 is a diagram illustrating an example of a source file instruction type determination process using an array. For example, when determining the instruction type of the first line of the source file 111, the instruction type determination unit 142 stores each word in the determination target line in the work array. For example, when determining the instruction type of “int res = −1;”, the words “int”, “res”, “=”, “−1”, “;” are stored in the work array.

  The instruction type determination unit 142 determines which of the determination conditions # 1 to # 5 is satisfied for the word stored in the work array. For example, the instruction type determination unit 142 refers to the fixed keyword dictionary 121 and recognizes that the word type of the first word “int” of the line to be determined is “variable type”. As a result, the instruction type determination unit 142 determines that the row to be determined satisfies the condition of determination # 2. Therefore, the instruction type determination unit 142 determines that the instruction type of this line is “declaration”.

  The instruction type determination unit 142 stores the determination result in the source meaning array 143b “source_mean_extract []”. The value of the index of the source meaning array 143b is the line number of the line to be determined in the source file 111. The line numbers are assumed to be assigned numbers in ascending order from 0 to each line other than a blank line or a comment line in order from the top line. For example, if the line of “int res = −1;” in the source file 111 is the 20th line (line number “19”), the instruction type of this line is the source semantic array 143b as an element of the index value “19”. Is stored in

  When the instruction type determination of the correction patch 211a and the source file 111 is completed, the patch introduction location estimating unit 144 estimates a correction target location in the source file 111 by applying the correction patch, based on the instruction type information 31 and 32. .

  FIG. 12 is a diagram illustrating an example of the patch introduction location estimation process. The patch introduction location estimating unit 144 compares the instruction type information 31 of the correction patch 211a with the instruction type information 32 of the source file 111. Then, the patch introduction location estimating unit 144 extracts an instruction type group that matches the instruction type group of the instruction type information 31 of the correction patch 211a from the instruction type information 32 of the source file 111. In the example of FIG. 12, the instruction type information 31 of the correction patch 211a includes a list of “declaration”, “declaration”, “condition”, “assignment”, “condition”, “assignment”, “other”, and “other”. Indicates the instruction type. The patch introduction location estimating unit 144 extracts the same sequence of instruction types from the instruction type information 32 of the source file 111. In this case, it may be extracted from a plurality of places.

  The patch introduction location estimating unit 144 specifies portions in the source file 111 corresponding to the extracted instruction type group as patch introduction estimation locations 111a and 111b. Then, the patch introduction location estimation unit 144 stores information indicating the patch introduction estimation locations 111a and 111b (patch introduction estimation location information 145a) in the patch introduction estimation location storage unit 145. The estimated patch introduction location information 145a indicates, for example, the file name of the source file having the estimated patch introduction location and the line number of the estimated patch introduction location.

When the estimated patch introduction locations 111a and 111b are specified, a matching process is next performed by the matching processing unit 146.
FIG. 13 is a diagram illustrating an example of the matching process. The matching processing unit 146 refers to the fixed keyword dictionary 121 in the fixed keyword dictionary storage unit 120, and classifies words included in the estimated patch introduction location 111a and the modified patch 211a into variable keywords and fixed keywords. That is, the matching processing unit 146 determines a word indicated in the fixed keyword dictionary 121 as a fixed keyword, and determines other words as variable keywords.

Then, the matching processing unit 146 calculates the matching rate of the fixed keyword between the lines having the same line number in the estimated patch introduction location 111a and the correction patch 211a.
In the example of FIG. 13, the first line is “match”, the second line is “mismatch”, and the third line is “match”.

  Hereinafter, the matching process will be specifically described with reference to FIGS. For example, the matching processing unit 146 divides the source code of the estimated patch introduction location 111a and the corrected patch 211a for each word and stores them in an array. Then, the matching processing unit 146 performs a matching process using the array.

  FIG. 14 is a diagram illustrating an example of a matching process using an array. The word in the estimated patch introduction location 111a is stored in the source match array “source_comp [] []”. The source match array is a two-dimensional array. The first index is set to the line number of the line in the estimated patch introduction location 111a, and the second index is set to the number indicating the order of the words in the line. Is done. In the source match array, words in the order indicated by the second index in the row indicated by the first index are set as elements corresponding to those index values.

  The words in the correction patch 211a are stored in the patch matching array “patch_comp [] []”. The patch matching array is a two-dimensional array. The first index is set to the line number of the line in the correction patch 211a, and the second index is set to the number indicating the order of the words in the line. . In the patch matching array, words in the order indicated by the second index in the row indicated by the first index are set as elements corresponding to those index values.

  Then, when performing a row-by-row comparison between the estimated patch introduction location 111a and the correction patch 211a, the matching processing unit 146 compares words set to the same index value in the source match array and the patch match array. I do. The matching processing unit 146 determines the match / mismatch of the lines by comparing the words in the lines with the same line number, and stores the determination result in the result storage array “result_comp [] []”. The result storage array is a two-dimensional array, in which the first index is set with the row number of the row to be determined, and the second index is set with a number indicating the order of words in the row. In the example of FIG. 14, the comparison result is stored in association with the first word of the line to be compared. That is, in the result storage array, the determination result of the row indicated by the first index is set as an element of the second index value “0”.

  FIG. 15 is a diagram illustrating an example of the matching result. For example, the first line of the estimated patch introduction location 111a is “int res = −1;”. This line includes three fixed keywords (“int”, “=”, “;”). Further, two variable keywords ("res", "-1") are included.

  The first line of the correction patch 211a is “short ans = −1;”. This line includes three fixed keywords (“short”, “=”, “;”). Also, two variable keywords ("ans", "-1") are included.

  When the first line is compared with each other, the fixed keyword “int” of the estimated patch introduction location 111a corresponds to the fixed keyword “short” of the correction patch 211a. “Int” and “short” are both shown to be “variable types” in the fixed keyword dictionary 121. The matching processing unit 146 determines that the fixed keywords having the word type “variable type” match each other. When the word type is other than “variable type”, the matching processing unit 146 determines that the words match if one or more characters or symbols of the words are all the same. The symbols of the remaining fixed keywords “=” and “;” in the first line of the estimated patch introduction location 111a and the first line of the modified patch 211a are the same. As a result, the matching processing unit 146 sets the matching rate of the fixed keywords in the first row to 100%.

  The second line of the patch introduction estimation location 111a is “int c = res + 1;”. This line includes four fixed keywords (“int”, “=”, “+”, “;”). Also, three variable keywords (“c”, “res”, “1”) are included.

  The second line of the correction patch 211a is “short x;”. This line includes two fixed keywords ("short", ";"). Further, one variable keyword (“x”) is included.

  Comparing the second row, the fixed keyword “int” of the patch introduction estimated location 111a corresponds to the fixed keyword “short” of the correction patch 211a. Since both “int” and “short” are “variable types” in the fixed keyword dictionary 121, the matching processing unit 146 determines that the fixed keywords match. The fixed keyword “=” (third word) on the second line of the estimated patch introduction location 111a is an added word, and the corresponding fixed keyword does not exist on the second line of the modified patch 211a. Therefore, the matching processing unit 146 determines that the fixed keyword “=” does not match. The fixed keyword ";" on the second line of the estimated patch introduction location 111a is the seventh word, and the modified patch 211a does not have the seventh word. Therefore, the matching processing unit 146 determines that the fixed keyword “;” does not match. As a result, the matching processing unit 146 sets the matching rate of the fixed keywords in the second row to 33% (（). The matching rate is obtained, for example, by dividing the number of matched fixed keywords by the number of fixed keywords in a row that includes a large number of fixed keywords among the two rows to be determined.

The matching processing unit 146 stores the comparison result for each row in the result storage array 147a in the matching result storage unit 147.
In the matching process, the matching processing unit 146 can store the correspondence between the variable keyword before and after the conversion in the memory 102 or the like. The stored correspondence relationship can be used for specifying a variable keyword thereafter.

  FIG. 16 is a diagram illustrating an example of storing the correspondence between variable keywords. In the example of FIG. 16, the correspondence between “res”, “−1”, and “* s” at the estimated patch introduction location 111a and each of “ans”, “−1”, and “* z” of the correction patch 211a. Are stored in the memory 102. The matching processing unit 146 can easily detect the modified variable keyword using, for example, the stored correspondence. For example, the matching processing unit 146 determines a word stored as a variable keyword as a variable keyword without having to collate it with the fixed keyword dictionary 121.

  Also, by storing the modified variable keywords, the result output unit 150 highlights the modified variable keywords based on the stored variable keywords, for example, when displaying the application status of the modified patch. You can also.

When the matching process is completed, the similarity calculating unit 148 calculates the similarity between the estimated patch introduction location 111a and the correction patch 211a.
FIG. 17 is a diagram illustrating an example of the similarity calculation process. The similarity calculation unit 148 calculates the proportion of matching rows (matching rate) as the similarity based on the comparison result of the patch introduction estimated portion 111a and the correction patch 211a in units of rows. In the example of FIG. 17, there is a match in seven of the eight rows, and the similarity is 87.5%.

  Next, the similarity calculating section 148 performs similarity ranking. For example, if the similarity is 100%, the similarity calculating unit 148 determines that they match. If the similarity is less than 100% and equal to or greater than the similarity threshold 131 stored in the similarity threshold storage unit 130, the similarity calculating unit 148 determines that the similarity is high. The high degree of similarity is sometimes called a partial match. Further, the similarity calculation unit 148 determines that they do not match if the value is less than the similarity threshold 131. In the example of FIG. 17, the similarity threshold value 131 is 50%. Then, the similarity calculation unit 148 stores the similarity information 149a indicating the calculated similarity and rank in the similarity storage unit 149.

After calculating the similarity, the result output unit 150 outputs the patch application determination result to the patch application information in the patch application information storage unit 151.
FIG. 18 is a diagram illustrating an example of the patch application information. In the patch application information 151a, the application status of the correction patch corresponding to the row to the source file is indicated in each row of the column indicating the file name of the source file. In the example of FIG. 18, when the similarity of the patch introduction estimated portion in the source file is 100% (perfect match), a double circle is set. If the similarity of the patch introduction estimated portion in the source file is less than 100% and equal to or more than the threshold (high similarity), a circle is set. Further, when the similarity of the patch introduction estimated portion in the source file is less than the threshold value (mismatch), a cross is set. When a plurality of estimated patch introduction locations are detected for one source file, the application status of each estimated patch introduction location is set in the patch application information 151a.

  By ranking based on the degree of similarity, it can be estimated that the case of perfect match and the case of high degree of similarity have already been corrected. In addition, when it is determined that they do not match by the ranking, it can be estimated that the modified patch has not been applied. It should be noted that patch application is not determined for source files that are not to be applied with a correction patch, and are blank “-”.

  Further, the result output unit 150 displays the patch application information 151a on the monitor 21 according to an instruction from the user. When the result output unit 150 receives a display instruction specifying a source file and a modified patch, the result output unit 150 can also display a result display screen including a comparison result between the estimated patch introduction location and the modified patch on the monitor 21.

  FIG. 19 is a diagram illustrating an example of the result display screen. The result display screen 41 shows the calculated similarity (87.5%) and the rank of the similarity (partial match) for each estimated location of the modified patch introduction. In addition, on the result display screen 41, the source code of the estimated patch introduction point and the source code of the modified patch are displayed for each estimated estimated patch introduction point.

Hereinafter, the procedure of the correction patch application visualization processing will be described in detail.
FIG. 20 is a flowchart illustrating an example of the procedure of the correction patch application visualization process. Hereinafter, the processing illustrated in FIG. 20 will be described along with step numbers.

  [Step S101] The instruction type determination unit 142 performs an instruction type determination process. In the instruction type determination process, the instruction type of each line between the source code of the correction patch and the source code in the OSS source file is determined. The details of the instruction type determination processing will be described later (see FIG. 21).

  [Step S102] The instruction type determination unit 142 performs a patch introduction location estimation process. In the patch introduction location estimation process, a location (one or more continuous lines) that may have been modified by the patch application is detected from the source code in the source file. Details of the patch introduction location estimation processing will be described later (see FIG. 24).

  [Step S103] The instruction type determination unit 142 determines whether at least one corrected patch introduction estimated location has been extracted. The instruction type determination unit 142 proceeds with the process to step S <b> 104 when the corrected patch introduction estimated portion can be extracted. If the estimated patch introduction location has not been extracted, the instruction type determination unit 142 proceeds to step S106.

  [Step S104] The matching processing unit 146 performs a matching process. In the matching process, the source code between the estimated patch introduction location and the modified patch is compared line by line, and a match / mismatch is determined. Details of the matching process will be described later (see FIG. 25).

  [Step S105] The similarity calculating section 148 performs a similarity calculating process. In the similarity calculation process, the similarity between the corrected patch introduction estimated portion and the corrected patch is calculated based on the result of the matching process. Details of the similarity calculation processing will be described later (see FIG. 26).

  [Step S106] The result output unit 150 performs a result output process. In the result output processing, storage or display of information indicating whether or not a correction patch has been applied to the source file is performed. Details of the result output process will be described later (see FIG. 27).

Next, details of the processing of each step shown in FIG. 20 will be described.
FIG. 21 is a flowchart illustrating an example of the procedure of the instruction type determination process. Hereinafter, the processing illustrated in FIG. 21 will be described along the step numbers.

  [Step S111] The instruction type determination unit 142 acquires a corrected patch and an OSS source file. For example, the source code acquisition unit 141 acquires a correction patch from the repository 210 in the server 200 and acquires an OSS source file from the source file storage unit 110. Then, the instruction type determination unit 142 acquires the corrected patch and the source file from the source code acquisition unit 141.

[Step S112] The instruction type determination unit 142 acquires the fixed keyword dictionary 121 from the fixed keyword dictionary storage unit 120.
[Step S113] The instruction type determination unit 142 performs instruction type information acquisition processing on each of the corrected patch and the OSS source file. Details of the command information acquisition process will be described with reference to FIGS.

FIG. 22 is the first half of a flowchart showing details of the procedure of the command type information acquisition process. Hereinafter, the processing illustrated in FIG. 22 will be described along the step numbers.
[Step S121] The instruction type determination unit 142 sets an initial value “0” to a variable i indicating an index value of an array.

  [Step S122] The instruction type determination unit 142 determines whether there is an unselected line in the modified patch or the source file. When there is an unselected line, the instruction type determination unit 142 proceeds with the process to step S123. When all the rows have been selected, the instruction type determination unit 142 ends the instruction type information acquisition processing.

[Step S123] The instruction type determination unit 142 selects the next unselected line in order from the top of the modified patch or the source file.
[Step S124] The instruction type determination unit 142 extracts a word from the selected line and stores it in the work array.

  [Step S125] The instruction type determination unit 142 determines whether "-" is at the beginning of the selected line. For example, if the word “−” is stored in the first element of the working array, the instruction type determination unit 142 determines that “−” is at the beginning. If the instruction type determination unit 142 has “-” at the beginning, the process proceeds to step S126. If the instruction type determination unit 142 determines that there is no "-" at the beginning, the process proceeds to step S127.

  It is to be noted that only the corrected patch includes a line with "-" at the beginning. Therefore, when performing the instruction type information acquisition processing for the source file, the processing of steps S125 and S126 may be skipped.

[Step S126] The instruction type determination unit 142 deletes the selected line of the modified patch. Thereafter, the instruction type determination unit 142 proceeds with the process to step S123.
[Step S127] The instruction type determination unit 142 determines whether the selected line is a blank line or a comment line. For example, the instruction type determination unit 142 determines that a line beginning with “#” is a comment line. In the case of a blank line or a comment line, the instruction type determination unit 142 proceeds with the process to step S123. If neither the blank line nor the comment line is present, the instruction type determination unit 142 proceeds with the process to step S128.

  [Step S128] The instruction type determination unit 142 determines whether “+” alone exists at the head of the selected line. If “+” is present alone at the beginning, the instruction type determination unit 142 proceeds with the process to step S129. In addition, when there is no single “+” at the beginning, the instruction type determination unit 142 advances the processing to step S131 (see FIG. 23).

  It is to be noted that only the corrected patch includes a line in which “+” is set alone at the beginning. Therefore, when performing the instruction type information acquisition processing for the source file, the processing of steps S128 and S129 may be skipped.

  [Step S129] The instruction type determination unit 142 deletes the leading “+” from the selected line of the correction patch. Thereafter, the instruction type determination unit 142 proceeds with the process to step S131 (see FIG. 23).

FIG. 23 is the latter half of the flowchart showing details of the procedure of the command type information acquisition processing. Hereinafter, the processing illustrated in FIG. 23 will be described along the step numbers.
[Step S131] The instruction type determination unit 142 determines whether or not there is a word that is “variable type” in the fixed keyword dictionary 121 at the beginning of the selected line. If the first word of the line is a word that specifies a variable type, such as “int” or “short,” the line is considered to be a statement declaring the variable type. When the first word is of the variable type, the instruction type determination unit 142 proceeds to step S132. If the first word is not a variable type, the instruction type determination unit 142 advances the process to step S133.

  [Step S132] The instruction type determination unit 142 stores “declaration” in the i-th element of the source meaning array 143b or the patch meaning array 143a. For example, when the instruction type information acquisition processing is performed on the source file, the instruction type determination unit 142 stores “declaration” in the element of the source meaning array 143b. Further, when the instruction type information acquisition processing is performed on the corrected patch, the instruction type determination unit 142 stores “declaration” in the element of the patch meaning array 143a. Thereafter, the instruction type determination unit 142 proceeds with the process to step S138.

  [Step S133] The instruction type determination unit 142 determines whether there is a word at the head of the selected line that is a “conditional operator” in the fixed keyword dictionary 121. When the first word of a line is a conditional operator such as “if” or “while”, the line is considered to be a statement defining a processing condition. If the first word is a conditional operator, the instruction type determination unit 142 proceeds with the process to step S134. If the first word is not a conditional operator, the instruction type determination unit 142 proceeds with the process to step S135.

  [Step S134] The instruction type determination unit 142 stores “condition” in the i-th element of the source meaning array 143b or the patch meaning array 143a. For example, when the instruction type information acquisition processing is performed on the source file, the instruction type determination unit 142 stores “condition” in the element of the source meaning array 143b. When the instruction type information acquisition processing is performed on the corrected patch, the instruction type determination unit 142 stores “condition” in the element of the patch meaning array 143a. Thereafter, the instruction type determination unit 142 proceeds with the process to step S138.

  [Step S135] The instruction type determination unit 142 determines whether “=” alone exists in the selected line. When “=” is a single item in a line, the line is considered to be a statement instructing the assignment of a value to a variable. If “=” exists alone, the instruction type determination unit 142 proceeds with the process to step S136. If there is no single “=”, the instruction type determination unit 142 proceeds with the process to step S137.

  [Step S136] The instruction type determination unit 142 stores “assignment” in the i-th element of the source meaning array 143b or the patch meaning array 143a. For example, when the instruction type information acquisition processing is performed on the source file, the instruction type determination unit 142 stores “assignment” as an element of the source meaning array 143b. Further, when the instruction type information acquisition processing is performed on the modified patch, the instruction type determination unit 142 stores “assignment” as an element of the patch meaning array 143a. Thereafter, the instruction type determination unit 142 proceeds with the process to step S138.

  [Step S137] The instruction type determination unit 142 stores “other” in the i-th element of the source meaning array 143b or the patch meaning array 143a. For example, when the instruction type information acquisition processing is performed on the source file, the instruction type determination unit 142 stores “other” in the element of the source meaning array 143b. When the instruction type information acquisition processing is performed on the corrected patch, the instruction type determination unit 142 stores “other” in the element of the patch meaning array 143a.

  [Step S138] The instruction type determination unit 142 increments the value of the variable i by one. Thereafter, the instruction type determination unit 142 proceeds with the process to step S122 (see FIG. 22).

  As described above, the instruction type determination unit 142 executes the instruction type information acquisition processing as shown in FIGS. 22 and 23 on all the lines of the corrected patch and the source file, thereby obtaining the instruction of each line. Acquires information indicating the type (instruction type information). Then, the patch introduction location estimating unit 144 performs a patch introduction location estimation process based on the instruction type information.

FIG. 24 is a flowchart illustrating an example of a procedure of a patch introduction location estimation process. Hereinafter, the processing illustrated in FIG. 24 will be described along with step numbers.
[Step S141] The patch introduction part estimating unit 144 acquires instruction type information of the correction patch source code and the OSS source code in units of lines.

  [Step S142] The patch introduction point estimating unit 144 compares the instruction type information of the source code for correction of the corrected patch with the instruction type information of the source code of the OSS. The patch introduction point estimating unit 144 searches the instruction type information of the OSS source code for a part (block) in which the instruction type indicated in the instruction type information of the correction source code of the correction patch matches the order of the instruction type. .

  [Step S143] The patch introduction location estimation unit 144 determines whether there is a matching block. If a matching block is detected, the patch introduction location estimating unit 144 proceeds with the process to step S144. If a matching block cannot be detected, the patch introduction location estimation unit 144 ends the patch introduction location estimation processing.

  [Step S144] The patch introduction location estimation unit 144 extracts all pieces of information indicating all matching blocks in the OSS source code as patch introduction estimation locations. The estimated patch introduction position indicates, for example, the position in the source code of the OSS of one or more continuous lines included in the block. Thereafter, the patch introduction location estimating unit 144 ends the patch introduction location designation processing.

If one or more estimated patch introduction locations can be identified by the patch introduction location estimation processing, matching processing between the estimated patch introduction location and the corrected patch is performed.
FIG. 25 is a flowchart illustrating an example of the procedure of the matching process. Hereinafter, the processing illustrated in FIG. 25 will be described along with step numbers.

  [Step S151] The matching processing unit 146 acquires a correction source code of the correction patch. Further, the matching processing unit 146 acquires a patch introduction estimated position in the OSS source code. For example, the matching processing unit 146 recognizes the estimated patch introduction location in the source file based on the estimated patch introduction location information 145a (see FIG. 12), and acquires one or more lines indicated in the corresponding location.

[Step S152] The matching processing unit 146 acquires the fixed keyword dictionary 121 from the fixed keyword dictionary storage unit 120.
[Step S153] The matching processing unit 146 stores words in the source match array and the patch match array.

  [Step S154] Based on the source match array and the patch match array, the matching processing unit 146 compares the estimated patch introduction location and the correction source code of the correction patch on a line-by-line basis, and determines a match / mismatch. For example, the matching processing unit 146 compares the fixed keyword in one of the two lines to be compared with a word in the other line at the same position (order of words from the beginning) as the fixed keyword. Then, when the fixed keywords having the same type and the same character as the fixed keywords in one line are located at the same position in the other line, the matching processing unit 146 determines that the fixed keywords match. When the type of the fixed keyword in one line is “variable type”, and when the fixed keyword of “variable type” is located at the same position in another line, the matching processing unit 146 matches the fixed keywords. Is determined.

[Step S155] The matching processing unit 146 stores information indicating whether the fixed keyword matches or does not match in the result storage array 147a (see FIG. 15).
[Step S156] The matching processing unit 146 stores, in the memory 102, the correspondence between the variable keywords in the row determined to match the fixed keywords.

When the matching process is completed, the similarity calculation unit 148 performs the similarity calculation process.
FIG. 26 is a flowchart illustrating an example of the procedure of the similarity calculation process. Hereinafter, the processing illustrated in FIG. 26 will be described along with step numbers.

[Step S161] The similarity calculation unit 148 acquires a matching result. For example, the similarity calculation unit 148 reads information stored in the result storage array 147a.
[Step S162] The similarity calculation unit 148 acquires the similarity threshold 131 (see FIG. 17) from the similarity threshold storage unit 130.

  [Step S163] The similarity calculation unit 148 calculates the degree of coincidence between the estimated patch introduction location and the corrected patch. For example, the similarity calculating unit 148 calculates, as the similarity, the ratio of the determination of the match (match rate) among all the determination results of the match / mismatch set in the result storage array 147a. At this time, the similarity calculating unit 148 can also classify the similarity. For example, if the similarity is 100%, the similarity calculating unit 148 sets the rank of the similarity to “match”. If the similarity is less than 100% and equal to or greater than the similarity threshold, the similarity calculating unit 148 sets the rank of the similarity to “high similarity (or partial match)”. When the similarity is less than the similarity threshold, the similarity calculating unit 148 sets the rank of the similarity to “mismatch”.

[Step S164] The similarity calculator 148 outputs similarity information 149a (see FIG. 17) indicating the similarity.
When the similarity is calculated, the result output unit 150 performs a result output process.

FIG. 27 is a flowchart illustrating an example of a procedure of a result output process. Hereinafter, the processing illustrated in FIG. 27 will be described along the step numbers.
[Step S171] The result output unit 150 acquires similarity information and patch introduction estimated location information. In addition, the result output unit 150 acquires the patch name of the acquired correction patch and the file name of the acquired source file from the source code acquisition unit 141.

[Step S172] The result output unit 150 acquires the patch application information 151a from the patch application information storage unit 151.
[Step S173] The result output unit 150 updates the patch application information 151a based on the similarity information and the estimated patch introduction location information. For example, the result output unit 150 stores the similarity information and the estimated patch introduction location information in the patch application information 151a in association with the pair of the patch name and the source file name. The result output unit 150 can also display the patch application information 151a on the monitor 21.

  In this way, even if the variable name or function name of the OSS source file has been changed, it is possible to appropriately determine whether or not a correction patch has been applied to the source file and visualize the determination result.

[Other embodiments]
In the second embodiment, it is assumed that a patch is applied to the OSS. However, the patch application confirmation method described in the second embodiment can be applied to software other than the OSS.

  Further, in the second embodiment, the matching processing unit 146 determines that a word having a variable type is a match if the two words to be compared are both variable types. , May be determined to be the same when the characters or symbols are the same. For example, when the words to be compared are “char” specifying a character type among variable types and “int” specifying an integer type, the matching processing unit 146 determines that the types of these words are the same variable type. Are determined to be mismatched because the characters are different.

  As described above, the embodiment has been exemplified, but the configuration of each unit described in the embodiment can be replaced with another having the same function. Further, other arbitrary components and steps may be added. Further, any two or more configurations (features) of the above-described embodiments may be combined.

DESCRIPTION OF SYMBOLS 1 Patch file 1a Correction instruction sequence 2 Source file 2a Type matching instruction sequence 10 Information processing device 11 Storage unit 12 Processing unit

Claims (7)

A storage unit for storing a source file to which a patch for changing some instruction sequences to a correction instruction sequence is applied;
Based on the patch file including the correction instruction sequence, patch instruction type information indicating the instruction type of each instruction in the correction instruction sequence is generated, and source instruction type information indicating the instruction type of each instruction in the source file is generated. Generating, based on the patch instruction type information and the source instruction type information, extracting, from the source file, a type matching instruction sequence in which the corrected instruction sequence matches the instruction type sequence; A processing unit that determines whether or not the patch has been applied to the source file, based on the description content excluding the variable name and the function name, with the correction instruction sequence,
Information processing device having The processing unit calculates the similarity between the description content of the type matching instruction sequence excluding the variable name and the function name and the description content of the correction instruction sequence excluding the variable name and the function name, and calculates the similarity. Determining whether the patch has been applied to the source file based on the degree;
The information processing device according to claim 1. The processing unit assigns a line number to each instruction line of the type matching instruction sequence and the correction instruction sequence in order from the beginning, determines the identity of descriptions of lines having the same line number, and determines that they match. The ratio of rows is the similarity,
The information processing device according to claim 2. The storage unit further stores a keyword dictionary including a list of words to be compared in determination of the identity between lines,
The processing unit stores a word included in the keyword dictionary in a first line of the type matching instruction sequence and the keyword dictionary in a second line having the same line number as the first line in the correction instruction sequence. Based on the result of comparison with the included words, determine the identity of the lines with the same line number,
The information processing device according to claim 3. A server for distributing a patch file including the correction instruction sequence for a patch for changing a part of the instruction sequence to a correction instruction sequence,
A storage unit for storing a source file to which the patch is to be applied; and a patch instruction type information indicating an instruction type of each instruction in the correction instruction sequence based on the patch file, acquiring the patch file from the server. Generating source instruction type information indicating the instruction type of each instruction in the source file, and based on the source instruction type information and the patch instruction type information, from the source file, the correction instruction sequence and A type-matching instruction sequence in which the order of the instruction types matches is extracted, and the patch is included in the source file based on the description contents of the type-matching instruction sequence and the correction instruction sequence, excluding variable names and function names. An information processing apparatus having a processing unit, which determines whether or not the information is applied; and
Patch application confirmation system having Computer
For a patch that changes a part of the instruction sequence to a correction instruction sequence, based on a patch file including the correction instruction sequence, generate patch instruction type information indicating the instruction type of each instruction in the correction instruction sequence,
Generating source instruction type information indicating an instruction type of each instruction in a source file to which the patch is applied;
Based on the patch instruction type information and the source instruction type information, from the source file, extract a type matching instruction sequence in which the sequence of the correction instruction sequence and the instruction type match,
Determining whether the patch has been applied to the source file, based on the description of the type matching instruction sequence and the correction instruction sequence, excluding variable names and function names;
Patch application confirmation method. On the computer,
For a patch that changes a part of the instruction sequence to a correction instruction sequence, based on a patch file including the correction instruction sequence, generate patch instruction type information indicating the instruction type of each instruction in the correction instruction sequence,
Generating source instruction type information indicating an instruction type of each instruction in a source file to which the patch is applied;
Based on the patch instruction type information and the source instruction type information, from the source file, extract a type matching instruction sequence in which the sequence of the correction instruction sequence and the instruction type match,
Determining whether the patch has been applied to the source file, based on the description of the type matching instruction sequence and the correction instruction sequence, excluding variable names and function names;
A patch application confirmation program that executes processing.

Images