JP6301851B2 - Program analysis device, error detection device, program analysis method, error detection method, program analysis program, and error detection program - Google Patents

Description

  The present invention relates to a technique for statically analyzing source code.

  Techniques for detecting errors when creating programs are being studied. One of them is a technique for detecting a potential error in a program by static code analysis.

As an example of an error detection technique based on static code analysis, refer to a technique for detecting a location in which a memory secured by a malloc function for a C program is not released by a free function, and an uninitialized memory secured by a malloc function. For example, there is a technique for detecting a spot (see Non-Patent Document 1).

W. R. Bush, J. D. Pincus, and D. J. Sielaff, "A static analyzer for finding dynamic programming errors", Software Practice and Experience, 2000, vol. 30, No. 7, pp. 775-802

In addition to using general resource capture functions and resource release functions such as a malloc function and a free function, unique resource capture functions and resource release functions may be created.

  In this case, the existing static code analysis tool can detect the uninitialized reference of the resource captured by a general function such as the malloc function or the free function, but uses an original resource capture function defined by the user. There was a problem that it was not possible to detect an uninitialized reference of a captured unique resource.

User-defined resources can be added to existing static code analysis tools by registering user-defined resource capture functions and resource release functions and adding static code analysis functions equivalent to malloc and free functions. It is considered that an error in uninitialized reference can be detected for the capture function.

For this purpose, the user needs to manage the resource capture / release function and register it in the static code analysis tool.

The present invention has been made in view of the above, and the resource capturing function used in the program by the user analyzing the source code of the program without managing the resource capturing / release function defined by the user. extracts and resource release function, and an object thereof is to detect errors in the use of the resource capture function.

A program analysis device according to a first aspect of the present invention is a program analysis device for extracting a resource capture function for capturing a resource and a resource release function for releasing the resource from a source code, and an input means for inputting the source code; Two different first functions and second functions appearing in the source code are selected, and the return value of the first function in all the execution paths that can be traced from the position where the first function is called on the source code. If the reference status of the variable storing the variable and the call status of the second function apply to the general usage of the resource storage variable and the general resource release function, the first function and the second function are comprising extraction means for extracting as a resource acquisition function and the resource release function, wherein the common resource storage variable and common resource release The number is used when the number of calls of the resource release function is within one in the execution path after the resource capture function is called, and when the resource release function is not called in the execution path, The execution path has a branch after the resource capture function is called, and the resource storage variable is not referred to after the branch, and when the resource release function is called in the execution path The resource storage variable is not referenced after merging of branches after the resource release function is called .

  The error detection apparatus according to the second aspect of the present invention is a program analysis apparatus according to the first aspect of the present invention, and a location where resources captured by a resource capture function extracted by the program analysis apparatus are referred to without being initialized. And detecting means for detecting on the source code.

A program analysis method according to a third aspect of the present invention is a program analysis method executed by a computer, wherein a resource capture function for capturing a resource and a resource release function for releasing the resource are extracted from source code. In the input step, the two different first and second functions appearing in the source code are selected, and in all the execution paths that can be traced from the position where the first function is called on the source code, the first function When the reference status of the variable storing the return value of one function and the calling status of the second function apply to the general resource storage variable and the general resource release function, the first function and the first function comprising extracting a respective 2 functions as a resource acquisition function and the resource release function, wherein the common resource The storage variable and a general resource release function are used in such a manner that the number of calls of the resource release function is within one in the execution path after the resource capture function is called, and the resource release function is in the execution path. Is not called, the execution path has a branch after the resource capture function is called, and the resource storage variable is not referenced after the branch, and the resource is released in the execution path. When the function is called, the resource storage variable is not referred to after the branch is merged after the resource release function is called .

  An error detection method according to a fourth aspect of the present invention is an error detection method executed by a computer, the step of extracting a resource capture function by the program analysis method according to the third aspect of the present invention, and the capture by the resource capture function And a step of detecting, on the source code, a location where the resource that has been referenced is referred to without being initialized.

  A program analysis program according to a fifth aspect of the present invention is characterized by operating a computer as each means of the program analysis apparatus according to the first aspect of the present invention.

  An error detection program according to a sixth aspect of the present invention is characterized by operating a computer as each means of the error detection apparatus according to the second aspect of the present invention.

According to the present invention, a user detects an error in the usage of a resource capture function used in a program by analyzing the source code of the program without managing the resource capture / release function defined by the user. Can do.

It is a functional block diagram which shows the structure of the source code inspection apparatus in this Embodiment. It is a flowchart which shows the flow of a process of the source code inspection apparatus in this Embodiment. It is a flowchart which shows the flow of the analysis process of a source code. It is a figure which shows the example of the source code which a source code inspection apparatus inputs. It is a figure which shows the example of the subroutine expansion | deployment code produced from the source code of FIG. It is a figure which shows the function list extracted from the subroutine expansion code of FIG. 6 is a control flow graph created from the subroutine development code of FIG. It is a figure which shows the analysis result of the subroutine expansion code of FIG. It is a figure which shows the analysis result of the subroutine expansion | deployment code | cord of FIG. 5 following FIG. 8A. FIG. 8 is a diagram illustrating an analysis result of the subroutine development code of FIG. 5 following FIG. 8B. It is a figure explaining the appearance pattern of the resource capture function used in this Embodiment, a resource release function, and a resource storage variable. It is a flowchart which shows the flow of the extraction process of a resource capture function and a resource release function. It is a flowchart which shows the flow of the process which investigates whether two functions and variables apply to the appearance pattern of a resource capture function, a resource release function, and a resource storage variable.

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

  FIG. 1 is a functional block diagram showing a configuration of a source code inspection apparatus 1 according to the present embodiment. The source code inspection apparatus 1 is an apparatus that receives and analyzes a source code and detects an error referring to an uninitialized resource.

  A source code inspection apparatus 1 shown in FIG. 1 includes an input unit 11, an analysis unit 12, an extraction unit 13, and a detection unit 14. Each unit included in the source code inspection device 1 may be configured by a computer including an arithmetic processing device, a storage device, and the like, and the processing of each unit may be executed by a program. This program is stored in a storage device included in the source code inspection apparatus 1, and can be recorded on a recording medium such as a magnetic disk, an optical disk, or a semiconductor memory, or provided through a network. Hereinafter, each part will be described.

  The input unit 11 inputs a source code to be inspected. In the embodiment described later, an example in which C language source code is input will be described. However, the present invention is not limited to C language but can be applied to other programming languages.

  The analysis unit 12 analyzes the source code input by the input unit 11. Specifically, the analysis unit 12 creates a subroutine expansion code by adding the definition code of the subroutine (function) to the place where the subroutine call (function call) is made in the source code, and generates each line of the subroutine expansion code. Is a function call, what is the variable that stores the return value of the function, what is the argument of the function, whether it is branched, where is the merge point after the branch, what variable is being used, etc. Analyze information. The analysis unit 12 also creates a control flow graph with each line of the subroutine expansion code as a node.

The extraction unit 13 extracts a resource capture function and resource release function pair based on the analysis result of the analysis unit 12. Specifically, for two different functions in the source code, check whether the resource capture function and the resource release function match the pattern used, and set the resource capture function and resource release function pair in the source code. Extract. For example, as the pattern resource acquisition function and the resource release function is used, it is called the resource acquisition function, the result is assigned to the resource storage variable, after the used resources via the resource storage variable, resource release There is a pattern where the function is called. In this case, the resource storage variable is referenced after the resource capture function is called. The resource storage variable is not referenced after the resource release function. Further, the resource release function is called after the resource capture function is called, but the resource release function is never called more than once. In Examples described later, it extracts a pair of resource acquisition function and the resource release function using the pattern in consideration of the error handling of resource acquisition function and resource release function.

The detection unit 14 detects a location that refers to an uninitialized resource returned by the resource capturing function extracted by the extraction unit 13. Existing static code analysis tools can analyze uninitialized references of resources captured with common resource capture functions such as malloc and new. The detection unit 14 is realized by registering a resource capture function and resource release function pair extracted by the extraction unit 13 in an existing static code analysis tool. As a method for detecting a reference to an uninitialized resource, for example, a method for detecting a reference to an uninitialized memory described in Non-Patent Document 1 can be used.

  Next, the operation of the source code inspection apparatus 1 in this embodiment will be described.

  FIG. 2 is a flowchart showing a processing flow of the source code inspection apparatus 1 in the present embodiment.

  The input unit 11 inputs the source code to be inspected (step S1).

  The analysis unit 12 analyzes the source code (step S2). Details of the source code analysis processing will be described later.

The extraction unit 13 extracts a resource capture function and resource release function pair from the source code based on the analysis result of the source code (step S3). Details of the resource capture function and resource release function extraction processing will be described later.

  Then, the detection unit 14 detects a location that refers to an uninitialized resource including a resource captured by the resource capture function extracted by the extraction unit 13 in addition to a general resource capture function (step S4). ).

(Source code analysis processing)
Next, source code analysis processing will be described.

  FIG. 3 is a flowchart showing the flow of source code analysis processing. Below, the analysis process of a source code is demonstrated with the specific example which input the source code shown in FIG.

  The analysis unit 12 creates a subroutine development code from the source code input by the input unit 11 (step S21). FIG. 5 shows an example of a subroutine expansion code created from the source code of FIG. In the example of FIG. 5, the analysis unit 12 expands and appends the source code of the finish function and abort_program function called from the main function under the location where the source code is called. The analysis unit 12 further expands and adds an abort_program function called from the finish function. Specifically, the abort_program function is expanded at the locations indicated by reference numerals 101A, 101B, and 101C, and the finish function is expanded at the location indicated by reference numeral 102. The abort_program function expanded at the locations indicated by reference numerals 101B and 101C is called from the finish function.

  In the subroutine development code, the line number obtained by adding the line number of the original source code to the caller line number (hereinafter referred to as “line number with call stack”) is assigned as the line number of the location where the function is expanded. For example, the abort_program function at the position denoted by reference numeral 101A is called on the ninth line of the main function, and the abort_program function is described on the 28th to 30th lines of the source code in FIG. Line numbers 9-28, 9-29, and 9-30 are assigned to the lines of the abort_program function expanded in FIG. In another example, the finish function at the location indicated by reference numeral 102 is called at the 13th line of the main function, and the abort_program function at the location indicated by reference numeral 101B is called at the 23rd line of the finish function. Row numbers 13-23-28, 13-23-29, and 13-23-30 are assigned to each row of the abort_program function at the location indicated by reference numeral 101B.

  Subsequently, the analysis unit 12 extracts a function from the subroutine development code and creates a function list (step S22). FIG. 6 shows a list of functions extracted from the subroutine expansion code of FIG. The analysis unit 12 assigns a function ID to the extracted function.

  Subsequently, the analysis unit 12 creates a control flow graph from the subroutine development code (step S23). The control flow graph is a directed graph representing the flow of control when a program is executed. FIG. 7 shows a control flow graph created from the subroutine development code of FIG. In this embodiment, the line number with a call stack is a node, and two edges of a step-in connection that follows the flow of control inside the called function and a step-over connection that does not follow the flow of control inside the function are provided. Granted. An edge indicated by a dotted line in FIG. 7 indicates a step-in connection, and an edge indicated by a solid line indicates a step-over connection. In the present embodiment, a loop that is one of the control structures of a program is not considered, and the loop is analyzed by assuming that it is executed only once.

  Then, the analysis unit 12 analyzes the subroutine development code (step S24). 8A to 8C are diagrams illustrating the analysis results of the subroutine development code by the analysis unit 12. In the present embodiment, an alias set, a function call, a function ID, a function return value storage variable, an argument, a branch, a popular number, and a variable with reference to an effect are extracted for each line of the subroutine expansion code.

  An alias set is a set of alias sets of variables that appear in the source code. In this embodiment, an alias set at the time after execution of the corresponding row is obtained. For example, since the cmd on the 4th line and the cmd on the 5th line are the same, the flow dependent variables (4, cmd), (5, cmd) in which the line number and the variable name are paired are added to the alias set. . The elements of the alias set can be considered the same when the variable names are different. When different alias sets belong, they can be regarded as different variables. The alias analysis assumed in this embodiment is a flow-sensitive alias analysis, and considers that the relationship of variables changes depending on the line of the source code. The flow dependent variable is a set (k, r) of the variable name r and the line number k with the call stack in which the variable appears.

  The function call indicates whether or not a function is called on the line. When a function is called, the ID of the calling function, a variable for storing the return value of the calling function, and the function argument are described. If the argument passed to the function in the source code is a variable that is qualified with the address operator (&) or indirect operator (*), the variable that excludes these operators is also included in the argument of the analysis result To do. This is because the value of the variable not modified by the address operator or indirect operator is referred to before the variable modified by the address operator or indirect operator is referenced. For example, when the argument passed to the function in the source code is & a, & a and a are described in the argument item of the analysis result. In another example, when the argument passed to the function on the source code is ** a, ** a, * a, and a are described in the argument item of the analysis result.

  A branch indicates whether or not the row is a branch. If there is a branch, enter the destination of the branched route in the popular number. In the branching of the “if” statement, the execution path branches to the “then” clause and the “else” clause, but the line after the “then” clause and the “else” clause becomes the merge destination.

  The variable that is referred to as effective refers to the variable that is actually used in the line. More specifically, it is defined that the variable v is referred to as being effective if it satisfies any of the following conditions.

(1) The value of the variable v is read and the value is assigned to another variable w. As a result, the variable v and the variable w do not have an alias relationship. (2) The variable v is referred to as a function argument. (3) The variable v is referenced in the conditional expression of the condition judgment statement

  Hereinafter, specific examples of variables that are referred to as effective will be described. For example, when a line with a = v is considered, as a result of executing this line, the variable a becomes an alias of the variable v. Therefore, the variable v is not referred to in this line because of the effect. In another example, if a line with a = v + 1 is considered, the value of the variable v is read and the value is set in the variable a. As a result, the variable a and the variable v are not in an alias relationship. In this line, the variable v is referred to as effective. Further, considering the variable a in this row, the value of the variable a is not referenced, and therefore the variable a is not referred to as effective.

  In another example, considering a line in which * v = a + 1 is described, the value of the variable v is referred to, dereferenced and stored in the variable * v, and as a result, the variable v and the variable * Since v does not have an alias relationship, the variable v is referred to as effective. In yet another example, when a line in which a = & v is described is considered, the address of the variable v is referred to, but the value of the variable v is not referred to. Therefore, the variable v is not referred to effectively.

  If the example referred in a conditional expression is given, for example, in the line where if (v) {...} Is described, the value of the variable v is referenced in the conditional expression of the conditional judgment statement. The variable v is referred to as effective.

(Resource capture function and resource release function extraction process)
Next, the resource capture function and resource release function extraction processing will be described.

As the appearance pattern of the general resource capture function and general resource release function in the source code, for example, the variable (resource storage variable) that stores the return value of the resource capture function is specified as the simplest pattern. After the capture function is called, there is a pattern in which the resource indicated by the resource storage variable is used, and then the resource release function is called only once. Resource storage variables are never used before the resource capture function and after the resource release function. It can be estimated that two functions that fall under such an appearance pattern may be a resource capture function and a resource release function.

In the present embodiment, two functions corresponding to the pattern including the error processing of the resource capturing function and the error processing of the resource releasing function are extracted as the resource capturing function and the resource releasing function.

FIG. 9 is a diagram for explaining the appearance pattern of the resource capture function, the resource release function, and the resource storage variable used in the present embodiment. The pattern shown in FIG. 9 is a pattern in which error processing is performed after the resource capture function and error processing is performed after the resource release function. In the error processing after the resource capture function, the resource storage variable is not referred to, and the processing is terminated without calling the resource release function. Further, in the error processing after the resource release function, the resource storage variable may be referred to for log output or the like, but the resource storage variable is not referred to after exiting the error processing.

Based on the analysis result of the analysis unit 12, the extraction unit 13 estimates resource storage variables for all combinations of two functions in the function list, and the appearance patterns of the two functions and the resource storage variables are shown in FIG. Whether the resource capturing function, the resource releasing function, and the appearance pattern of the resource storage variable apply is checked. If the pattern is applied, the two functions are extracted as the resource capturing function and the resource releasing function. Hereinafter, the flow of extraction processing of the resource capture function and the resource release function will be described.

10 and 11 are flowcharts showing the flow of the process of extracting the resource capturing function and the resource releasing function.

First, the extraction unit 13 sets an empty set to a function pair set that stores a pair of a resource capture function and a resource release function (step S31).

The extraction unit 13 selects two functions f and g from the function list, and repeats the following processing for all function combinations (step S32). If a set of function IDs included in the function list is F, fεF, gεF, and f ≠ g. In the following processing, it is checked whether the function f is a resource capture function or the function g is a resource release function.

  The extraction unit 13 refers to the analysis result and creates a line number set K by listing the line number k at which the function f is called (step S33).

  The extraction unit 13 refers to the analysis result, and sets a flow-dependent variable set R as a flow-dependent variable (k, r) with a pair of variables r storing the return value of the function f at the line number kεK and the line number k. Is created (step S34). By this processing, the flow dependent variable set R = {(k1, r1), (k2, r2),..., Which is a pair of the line number k where the function f is called and the variable r which is a candidate for the resource storage variable. } Is created.

  The extraction unit 13 sets the number of suitable patterns to 0, and for all flow-dependent variables (k, r) εR, the appearance patterns of the two functions f and g and the variable r are present in the execution path after the line number k. It is determined whether or not the pattern shown in FIG. 9 is applicable (steps S35 to S37). When the determination result in step S36 is positive, 1 is added to the number of suitable patterns. Details of the process for determining whether the appearance patterns of the two functions f and g and the variable r apply to the pattern shown in FIG. 9 will be described later.

When the determination results of all the flow dependent variables (k, r) εR are positive, the function pair (f, g) is assumed to be a function pair, assuming that the functions f, g are a resource capture function and a resource release function. It adds to a set (step S38). When the number of flow dependent variables | R | matches the number of suitable patterns, the determination result of all the flow dependent variables is positive, so the function pair (f, g) is added to the function pair set. However, if the number of line numbers k | K | and the number of flow-dependent variables | R | do not match, there are places in the source code where the return value of the function f is not stored in the variable. Therefore, the function pair (f, g) is not added to the function pair set.

  The extraction unit 13 performs steps S33 to S38 for all function pairs (f, g), fεF, gεF, and f ≠ g (step S39).

Through the above processing, a function pair that is likely to be a pair of a resource capture function and a resource release function is stored in the function pair set.

  Next, details of a process for determining whether or not the appearance patterns of the two functions f and g and the variable r apply to the pattern shown in FIG. 9 will be described.

FIG. 11 is a flowchart showing a flow of processing for checking whether or not two functions f and g and a variable r are applicable to the resource capture function, the resource release function, and the appearance pattern of the resource storage variable. In the processing shown in FIG. 11, it is determined whether or not the appearance patterns of the functions f and g and the variable r are applicable to the pattern shown in FIG. 9 in all the execution paths after the line number k where the function f is called. .

The extraction unit 13 refers to the control flow graph and creates an execution path set P by listing all execution paths p after the line number k from which the function f is called (step S51). Here, when the execution path p is created, the step-in connection to the functions f and g is not followed. If there is a step-in connection to a function other than the functions f and g, only the step-in connection is followed. When there are a plurality of step-over connections starting from one node, an execution path corresponding to how to select the connection is created. The execution path p is represented by an ordered set p = {n ₁ , n ₂ ,..., N _m } of line numbers with call stacks.

  The extraction unit 13 sets the number of preferred routes and the number of acquisition failure candidate routes to 0, and repeats the following processing for all execution routes pεP (step S52). The preferred number of paths indicates the number of execution paths p that match the pattern in FIG. The number of acquisition failure candidate paths indicates the number of execution paths p applicable to the error processing of the resource acquisition function.

  The extraction unit 13 sets the post-supplemented used section survey flag to true (step S53). The post-supplemented used section survey flag is a flag indicating the inspection result of the execution path p, and false is set when the execution path p does not correspond to the pattern of FIG.

The extraction unit 13 determines whether the function g has been called twice or more on the execution path p (step S54). Since the resource release function is not called twice or more, if the function g is called twice or more (YES in step S54), the post-supplemented used section survey flag is set to false (step S60).

  The extraction unit 13 determines whether the function g is called once on the execution path p (step S55). If the function g has not been called (NO in step S55), the execution path p may be an error processing path for the resource capture function, and the process proceeds to step S58.

  When the function g is called once on the execution path p (YES in step S55), the extraction unit 13 determines whether the variable r is used before the function g is called (step S56). If the variable r is not used (NO in step S56), the post-supplemented used section survey flag is set to false (step S60).

  Note that “the variable r is used” specifically means “one of the aliases of the flow-dependent variable (k, r) is referred to as effective”. In order to simplify the description, it is described in this embodiment that “variable r is used”.

Here, the use determination of the variable r in step S56 will be described. It is assumed that the function g is called in the line corresponding to the _jth element nj in the execution path p. Extraction unit 13, in any of the elements from the first element n ₁ to j-1 th element n _j-1 execution path p, the item of variable referenced there effects of the analysis result of the variable r aliases It is checked whether any of the above is described. If the alias of the variable r is referred to as effective, the determination result in step S56 is YES. If the alias of the variable r is not referred to as effective, the determination result in step S56 is NO.

  When the variable r is used before the function g is called (YES in step S56), the extraction unit 13 determines whether the variable r is used after the function g is called (step S57). When the variable r is used (YES in step S57), the post-supplemented use section survey flag is set to false (step S60).

However, the path of the error handling resource release function, there is a possibility that even the variable r after the function g is called is used, the point you think that the error handling of the resource release function skip determining. Specifically, the extraction unit 13 in the execution path p, after the element n _j, locate the first occurrence of the branch in element n _j the same level, if a branch is present in the execution path p its a merging destination element n _h and subsequent elements of the branch and determination target in step S57. Also, if the merge destination because of a program in the middle of the case and branches branch does not exist and ends not exist, element n appearing after the element n _j in execution path p in element n _j the same level _{After h} is set as the determination target in step S57. If there is no later elements n _j in the same hierarchical elements than the function g is called element n _j in the execution path p, the process proceeds to step S61 of the determination result of the step S57 as NO.

On the other hand, when the function g is not called on the execution path p (NO in step S55), it is determined whether or not the execution path p is an error processing path of the resource capturing function by using the variable r in the execution path p. This is performed by determining whether or not is used (step S58). Specifically, in the execution path p, after the first element n ₁ of the element n ₁ and locate the first occurrence branch at the same hierarchy, if the branch is present, component elements n of branching appears _{If h ′} and there is no branch, element n ₁ is element n _{h ′} . Then, at a location corresponding to one element of the following elements up to the last element n _m elements n _{h 'execution} path p, checks whether the variable r is used.

  If the variable r is used (YES in step S58), the post-supplemented used section survey flag is set to false (step S60).

  If the variable r is not used (NO in step S58), the number of acquisition failure candidate paths is incremented by 1 (step S59) as an error processing path of the resource acquisition function.

  When the inspection of the appearance patterns of the functions f and g and the variable r is completed in the processes of steps S54 to S59, if the post-supplemented used section survey flag is true, the number of suitable routes is incremented by 1 (step S61). It should be noted that when the execution path p is an error processing path of the resource capturing function, it is also applied to the pattern, so that the number of suitable paths is incremented by 1. That is, when the execution path p is an error processing path of the resource capture function, 1 is added to each of the number of acquisition failure candidate paths and the number of suitable paths.

When steps S53 to S61 are processed for all the execution paths pεP (step S62), when the functions f and g and the variable r apply to the pattern of FIG. 9 in all the execution paths pεP, the functions f and g The possibility that the variable r is a resource capture function, a resource release function, and a resource storage variable is determined to be positive (step S63). Specifically, the extraction unit 13 determines positive if the number of execution paths | P | included in the execution path set P coincides with the number of suitable paths, and the number of suitable paths> the number of capture failure suitable paths.

10 and 11 can extract a function pair that is highly likely to be a resource capture function and a resource release function. For example, from the source code of FIG. 4, a function pair set = {(mpmool_alloc, mempool_free), (mmpool_aloc, finish)} is obtained. Of these, the function pair (mempool_alloc, finish) is not a function pair that is originally desired to be extracted, but mempool_free is called in the finish, and is a pair extracted in conformity with the algorithm described above (false positive). . Before the detection unit 14 performs the error detection process, a person may carefully examine the extracted function pair and remove the false positive function pair.

In addition, the mempool_constructor function and mempool_destructor function in the source code of FIG. 4 are also a resource capture function and a resource release function, but are not extracted because they did not conform to this algorithm. This is because the source code in FIG. 4 does not conform to the determination in step S56 in FIG. 11 because there is an execution path in which the resource captured by the mempool_constructor function is not used. If the determination process of step S56 is omitted, the mempool_constructor function and the mempool_destructor function are extracted, but it is expected that the false positive will increase.

As described above, according to the present embodiment, for all combinations of two different functions f and g appearing in the input source code, all the line numbers k that call the function f are listed, and the function f is When the variables r and g for storing the return value of the function f apply to the general resource storage variable and the appearance pattern of the general resource release function in all the execution paths after the called line number k, the function f , G are extracted as a resource capture function and a resource release function, and a resource capture function defined by the user is obtained by static code analysis by detecting a location where a resource captured by the resource capture function is referenced without being initialized. It is possible to detect errors in the usage of the resource release function. For example, it is possible to detect an error referring to an uninitialized resource when using a resource capture / release API developed as middleware or a basic function.

DESCRIPTION OF SYMBOLS 1 ... Source code inspection apparatus 11 ... Input part 12 ... Analysis part 13 ... Extraction part 14 ... Detection part

Claims (6)

A program analysis device for extracting a resource capture function for capturing a resource and a resource release function for releasing the resource from a source code,
An input means for inputting source code;
Two different first functions and second functions appearing in the source code are selected, and the return value of the first function in all the execution paths that can be traced from the position where the first function is called on the source code. If the reference status of the variable storing the variable and the call status of the second function apply to the general usage of the resource storage variable and the general resource release function, the first function and the second function are An extraction means for extracting as a resource capture function and a resource release function ,
The general resource storage variable and the general resource release function are used in such a way that the number of calls of the resource release function is within one in the execution path after the resource capture function is called, and the execution path When the resource release function is not called in step 1, the execution path has a branch after the resource capture function is called, and the resource storage variable is not referenced after the branch, and the execution path When the resource release function is called in a route, the resource storage variable is not referred to after the branch merges after the resource release function is called . A program analysis device according to claim 1 ;
Detecting means for detecting a location on the source code where the resource captured by the resource capturing function extracted by the program analysis device is referred to without being initialized;
An error detection apparatus comprising: A computer-executed program analysis method for extracting a resource capture function for capturing a resource and a resource release function for releasing the resource from source code,
Input source code,
Two different first functions and second functions appearing in the source code are selected, and the return value of the first function in all the execution paths that can be traced from the position where the first function is called on the source code. If the reference status of the variable storing the variable and the call status of the second function apply to the general usage of the resource storage variable and the general resource release function, the first function and the second function are Extracting as a resource capture function and a resource release function ,
The general resource storage variable and the general resource release function are used in such a way that the number of calls of the resource release function is within one in the execution path after the resource capture function is called, and the execution path When the resource release function is not called in step 1, the execution path has a branch after the resource capture function is called, and the resource storage variable is not referenced after the branch, and the execution path When the resource release function is called in a route, the resource storage variable is not referred to after the branch merges after the resource release function is called . An error detection method executed by a computer,
Extracting a resource capture function by the program analysis method according to claim 3 ;
Detecting on the source code where the resource captured by the resource capturing function is referenced without being initialized;
An error detection method comprising: A program analysis program for operating a computer as each means of the program analysis apparatus according to claim 1 . An error detection program for causing a computer to operate as each means of the error detection apparatus according to claim 2 .

Images