JP6574151B2 - Program analysis apparatus, program analysis method, and program analysis program - Google Patents

Description

  The present invention relates to a program analysis apparatus, a program analysis method, and a program analysis program.

  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 where 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

  By the way, the program creator not only uses a general resource capture function and resource release function such as a malloc function and a free function, but also creates a program using an original resource capture function and resource release function. .

  An existing static code analysis tool can detect an uninitialized reference to a resource captured by a general function such as a malloc function or a free function, or a resource release omission. However, with existing static code analysis tools, when a program creator creates a program using its own resource capture function and resource release function, the resources captured using the program creator's own resource capture function Failed to detect uninitialized references and missing resources release.

  Therefore, it is also conceivable to register a resource capture function and resource release function unique to the program creator in an existing static code analysis tool and perform static code analysis in the same manner as the malloc function and free function. That is, the resource captured by the program creator's own resource capture function is handled in the same manner as the memory captured by the malloc function, and the resource captured by the program creator's own resource capture function is released by the original release function. By treating the relationship that should be handled in the same way as the relationship that the memory captured by the malloc function should be released by the free function, it is considered that uninitialized references to the captured resource and resource release omissions can be detected. .

  In order to register a function unique to the program creator in the static code analysis tool, it is necessary for the user of the static code analysis tool to manage and register the resource capture / release function. However, in order to perform static code analysis, it takes time and effort for the user to manage the resource capture / release function and register it without error in the tool, which is inconvenient.

  Therefore, it is conceivable to develop a technique for automatically detecting from the program a resource capture / release function unique to the program creator. The inventor has so far focused on the fact that the resource capture function and the resource release function appear in pairs in the source code, and analyzed the source code to automatically analyze the resource capture function and the resource release function. A technique for detecting a pair has been proposed (Japanese Patent Application No. 2015-028456). The present inventor has also proposed a technique for detecting a path that may contain a resource release omission error, assuming that the created program may contain a resource release omission (Japanese Patent Application No. 2015-156945).

  An embodiment of the disclosure has been made in view of the above, and an object thereof is to extract a pair of a resource capture function and a resource release function from a source code including a branch and a loop.

  The disclosed program analysis device, program analysis method, and program analysis program, when a loop is included in an execution path that may be traced from the position where the first function is called in the source code, An execution path that can be traced by the process is generated for each of the processes executed repeatedly from n times to n times (n is a natural number of 2 or more). The program analysis apparatus, the program analysis method, and the program analysis program are different from the first function in the generated execution path, unlike the first function, the variable that stores the return value of the first function, and the first function. If the appearance pattern of the second function that uses the variable storing the return value of the function of the first argument matches the appearance pattern of the resource capture function and the resource release function, the first function and the second function are Extract as a resource capture function and resource release function pair.

  The disclosed program analysis device, program analysis method, and program analysis program have an effect of extracting a resource capture function and resource release function pair from source code including a branch and a loop.

FIG. 1 is a diagram for explaining an outline of a program analysis process in the present embodiment. FIG. 2 is a diagram for explaining a function pair extraction method when the function f is called a plurality of times in the source code. FIG. 3 is a block diagram showing an example of the configuration of the program analysis apparatus according to the present embodiment. FIG. 4 is a flowchart showing an example of the flow of program analysis processing in the present embodiment. FIG. 5 is a flowchart showing an example of the flow of source code analysis processing. FIG. 6 is a diagram illustrating an example of source code which is an analysis target of the program analysis apparatus. FIG. 7 is a diagram showing an example of a subroutine expansion code created from the source code of FIG. FIG. 8 is a diagram showing a full function set and a full function pair set of functions extracted from the subroutine expansion code of FIG. FIG. 9 is a diagram showing a simplified structure of branches and loops included in the source code. FIG. 10 is a diagram illustrating an example of a set of non-deterministic execution paths for explaining the execution path generation processing. FIG. 11 is a diagram illustrating an example of a set of label paths for explaining the execution path generation process. FIG. 12 is a diagram for explaining a case where a reduced execution path is generated by executing a loop once in the execution path generation process. FIG. 13 is a diagram for explaining a case where a reduced execution path is generated by executing a loop twice in the execution path generation process. FIG. 14 is a diagram for explaining a case where a reduced execution path is generated by executing a loop three times in the execution path generation process. FIG. 15 is a diagram for explaining a case where a reduced execution path is generated by executing a loop four times in the execution path generation process. FIG. 16 is a diagram for explaining a case where a reduced execution path is generated by executing a loop five times in the execution path generation process. FIG. 17 is a diagram for explaining a case where a reduced execution path is generated by executing a loop six times in the execution path generation process. FIG. 18 is a diagram for explaining the reduced execution path generated in the execution path generation process shown in FIGS. 12 to 17. FIG. 19 is a flowchart illustrating an example of a flow of execution path generation processing according to the embodiment. FIG. 20 is a diagram illustrating an example of a configuration of information generated by the execution path generation processing according to the embodiment and stored in the execution path storage unit. FIG. 21 is a flowchart illustrating an exemplary flow of a function pair extraction process according to the embodiment. FIG. 22 is a diagram illustrating that information processing by the program analysis program according to the disclosed technique is specifically realized using a computer. FIG. 23 is a diagram for describing a case where the application program manages resources and dynamically captures and releases them.

  Hereinafter, embodiments of the disclosed apparatus, method, and program will be described in detail with reference to the drawings. In addition, this invention is not limited by this embodiment. Moreover, each embodiment can be combined suitably.

[Example of missing resource initialization]
As an example in which release omission (initialization error) occurs after the resource is captured, a case where the application program manages the resource and dynamically captures and releases it can be considered. As an example, when a system and a certain number of FAX boards are connected, there is a case where an application program creates a program that provides resources for operating the FAX board.

  FIG. 23 is a diagram for describing a case where the application program manages resources and dynamically captures and releases them. In the case of the example (1) in FIG. 23, when the application program (AP) is executed, a plurality of resources (M1 to M7) are first generated. Then, while the application program is executed, a predetermined resource is captured and used from among a plurality of resources generated first, and released after use. For example, in the example of FIG. 23, resources M1 to M4 are captured in order, and values A, A, B, and A are written, respectively. Resources M5, 6 and 7 are initial values because they are unused.

  In the example (2) of FIG. 23, the application already uses the resources M1 to M7 in order, and tries to use the resource M1 again. At this time, if the first use of the resource M1 is completed and the place to be initialized remains uninitialized, the value A remains stored. As described above, when the resource should be initialized after the resource is captured, a state in which the resource is not initialized is referred to as a resource initialization omission error. When such an error in resource initialization omission occurs, the next process is performed with the content written in the resource by the previous process as it is, and an unintended result may occur.

  In the embodiment described below, for a program including a loop in which the same process (capture, use, and release of the resource M1) is repeatedly executed, a pair of a resource capture function and a resource release function set independently is extracted. To do.

[Flow of Program Analysis Processing According to Embodiment]
FIG. 1 is a diagram for explaining an outline of a program analysis process according to the present embodiment. The program analysis apparatus according to the present embodiment analyzes a source code and extracts a pair of a resource capture function and a resource release function from the source code. Specifically, the program analysis device extracts a function pair that matches a predetermined appearance pattern as a resource capture function and resource release function pair based on the analysis result of the source code. Further, the program analysis apparatus according to the present embodiment extracts a resource capture function and resource release function pair after executing source code analysis on the assumption that the source code includes a branch or a loop.

  Referring to FIG. 1, in the program analysis processing according to the embodiment, the program analysis apparatus first receives an input of source code ((1) in FIG. 1). The program analysis apparatus analyzes the input source code and extracts a function included in the source code. Then, the program analysis apparatus generates a total function set F that is a set of all the functions included in the source code ((2) in FIG. 1). Further, the program analysis apparatus extracts two function pairs from the generated total function set F to generate a total function pair set F × F ((3) in FIG. 1).

  Further, the program analysis apparatus analyzes the source code and extracts branches and loop structures included in the source code ((4) in FIG. 1). The program analysis device analyzes a branch or loop structure and generates a flow of processing that can occur when the source code is executed as an execution path. In the present embodiment, when a branch or loop is included in the source code, one execution path is determined nondeterministicly from a plurality of execution paths that can be processed when the branch or loop is executed. It is considered to be executed. Hereinafter, a plurality of execution paths that can be traced when the source code is executed are referred to as non-deterministic execution paths ((5) in FIG. 1).

  The program analysis apparatus extracts one function pair (f, g) from the total function pair set F × F generated in (3). Then, the program analysis apparatus determines whether or not the appearance pattern of the function pair (f, g) in the non-deterministic execution path matches the pattern predicted for the resource capture function and the resource release function ((FIG. 1 ( 6)).

  For example, a common pattern in which resource capture and resource release functions are used is after a resource capture function is called, the result is assigned to a resource storage variable, and the resource is used through the resource storage variable. There is a pattern where the resource release function is called. In this case, the resource storage variable is referenced after the resource capture function is called. The resource storage variable is never referenced after the resource release function. Also, the resource release function is called after the resource capture function is called, but the resource release function is never called more than once.

  Here, it is assumed that the function pair (f, g) is a resource capture function and a resource release function. Then, in the source code, it is considered that a code for assigning the return value of the function f to the resource storage variable r first in order to capture the resource appears. Next, it appears that code that uses the captured resource appears and finally releases the resource by function g. That is, the following codes are expected to appear in the order of (1) to (3) in the source code.

(1) r = f ()
(2) func (r)
(3) g (r)
That is, if the function pair (f, g) is a pair of a resource capture function and a resource release function, if the function f appears as in (1), it is considered that (2) (3) always appears thereafter. In the following, for convenience of explanation, the code corresponding to (1) will be referred to as “ALLOC” (abbreviated as “A”), the code corresponding to (2) as “USE” (abbreviated as “U”), and (3). The corresponding code is called “FREE” (“F” for short). In the following description, func (r) in (2) is also expressed as some_func (r).

  Based on the above assumption, the program analysis apparatus determines whether or not the function pair (f, g) appears in the above pattern in the generated non-deterministic execution path. Then, when there is a non-deterministic execution path in which the function pair (f, g) appears in the above pattern, the program analysis apparatus extracts the function pair (f, g) as a pair of the resource capture function and the resource release function. ((7) in FIG. 1). On the other hand, if the function pair (f, g) does not appear in the above pattern in any non-deterministic execution path, the program analysis apparatus extracts the function pair (f, g) as a pair of the resource capture function and the resource release function. Not ((8) in FIG. 1).

  The program analysis apparatus may repeat the processing for all function pairs included in the total function pair set F × F, so that the function analysis function may be a resource capture function and resource release function pair among the function pairs included in the source code. High function pairs can be extracted. Thereafter, the program analysis apparatus can further analyze the source code by applying an arbitrary static code analysis technique using the extracted function pair ((9) in FIG. 1).

  Note that when the function f is called in the source code, the variable for storing the return value is not necessarily one. FIG. 2 is a diagram for explaining a function pair extraction method when the function f is called a plurality of times in the source code. In the example of FIG. 2, the function f is called three times in the source code. When called for the first time, the return value of the function f is assigned to the variable r. When called for the second time, the return value of the function f is assigned to the variable r '. When called for the third time, the return value of the function f is assigned to the variable r ″. In this case, whether or not the function (f, g) is a pair of a resource capture function and a resource release function. In determining whether or not, the program analysis apparatus first generates a non-deterministic execution path for the process corresponding to the variable r ((1) in FIG. 2). Then, it is determined whether or not there is an execution path corresponding to the pattern “AUF”. In the example of FIG. 2, the program analyzing apparatus determines that there is an execution path corresponding to the pattern “AUF” (“matches the condition”) ((2) in FIG. 2). Next, the program analysis apparatus generates a nondeterministic execution path for the process corresponding to the variable r ′ ((3) in FIG. 2). Then, the program analysis apparatus determines whether there is an execution path corresponding to the pattern “AUF” among the generated non-deterministic execution paths. In the example of FIG. 2, the program analysis apparatus determines that there is an execution path corresponding to the pattern “AUF” (“matches the condition”) ((4) in FIG. 2). Finally, the program analysis apparatus generates a non-deterministic execution path for the process corresponding to the variable r ″ ((5) in FIG. 2). Then, the program analysis apparatus includes the pattern “ It is determined whether or not there is an execution path corresponding to “A-U-F”. In the example of FIG. 2, the program analysis apparatus determines that there is an execution path corresponding to the pattern “AUF” (“matches the condition”) ((6) in FIG. 2). The program analysis apparatus, when there is at least one execution path that matches the pattern “AUF” among the nondeterministic execution paths corresponding to all variables, the function pair (f, g) is It is determined that the resource capture function is a pair of the resource release function ((7) in FIG. 2). Thus, the determination accuracy can be further improved by determining whether or not the resource capture function and the resource release function are paired based on the appearance pattern of the function pair (f, g) corresponding to a plurality of variables. it can.

[Example of the configuration of the program analysis device]
FIG. 3 is a block diagram showing an example of the configuration of the program analysis apparatus 1 according to the present embodiment.

  The program analysis apparatus 1 illustrated in FIG. 3 includes an input unit 10, a control unit 20, a storage unit 30, and an output unit 40.

  The input unit 10 is a processing unit that receives input of information. For example, the input unit 10 receives input of source code to be analyzed by the program analysis apparatus 1. In an example described later, C language source code will be described. However, the program analysis method of this embodiment can be applied not only to the C language but also to other programming languages.

  The control unit 20 controls the program analysis device 1. The control unit 20 can be configured by, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), an ASIC (Application Specific Integrated Circuit), or the like. The control unit 20 includes an analysis unit 21, a generation unit 22, and an extraction unit 23.

  The analysis unit 21 analyzes the source code received by the input unit 10. Specifically, the analysis unit 21 creates a subroutine expansion code by adding the definition code of the subroutine (function) to the location where the subroutine is called (function call) in the source code, and generates each subroutine expansion code line. 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 processing by the analysis unit 21 is the same as the processing described in Japanese Patent Application No. 2015-156945.

  The analysis unit 21 also extracts a function included in the source code and creates a full function set F and a full function pair set F × F.

The generation unit 22 generates an execution path based on the analysis result of the analysis unit 21. The execution path represents the flow of source code processing. The generation unit 22 expands branches and loops in the source code based on the analysis result, and generates a plurality of possible execution paths (non-deterministic execution paths). For example, the example of (4) in FIG. 1 shows a flow of processing including a loop structure and a branch. For example, in the case of (4) in FIG. 1, the generation unit 22 generates the following nondeterministic execution path that is executed once in the loop.
(1) 1-2-3-4-11
(2) 1-2-5-6-11
(3) 1-2-7-8-11
(4) 1-2-9-10-11

The generation unit 22 further generates a label path in which only processes that match any of the above-mentioned “ALLOC”, “USE”, and “FREE” are extracted from the non-deterministic execution path processes. For example, in the above example, “2” matches “ALLOC”, “7” and “10” match “USE”, and “8” matches “FREE”. In this case, the generation unit 22 generates the following label path from the above nondeterministic execution path.
(1) A
(2) A
(3) AUF
(4) AU

  The generation unit 22 further generates a contracted execution path by discarding patterns that do not affect the determination of the pair of the resource capture function and the resource release function in the label path. A method for generating the contracted execution path will be described in detail later. Further, the generation unit 22 adjusts so that there is no duplication when the generated contracted execution path includes a plurality of the same paths.

  The generation unit 22 repeats the same processing for a case where the inside of the loop is executed a plurality of times, and is generated when the reduced execution path generated when the inside of the loop is executed n times and the inside of the loop is executed n + 1 times. When the contracted execution path becomes the same, the execution path generation process ends.

  The non-determined execution path, label path, and contracted execution path generation process (execution path generation process) by the generation unit 22 will be described in more detail later. In this specification, “execution path” is information indicating a possible execution order for each process included in the source code. The “execution path” is a concept including “non-deterministic execution path”, “label path”, and “reduced execution path”. “Non-deterministic execution path” displays a possible execution order for each process for all processes, and one of the non-deterministic execution paths is executed when the actual source code is executed. “Label path” displays only the processes associated with “A”, “U”, and “F” among the processes included in the “non-deterministic execution path”. Even when a label path is generated based on the same non-deterministic execution path, different label paths are generated depending on the function pairs associated with “A”, “U”, and “F”. The “reduction execution path” is obtained by deleting the arrangement part of “A”, “U”, and “F” that can be discarded in the determination of the resource capture function and the resource release function in the “label path”.

  The extraction unit 23 determines whether the execution path for the function pair (f, g) and the variable r generated by the generation unit 22 includes the pattern “AUF” for the function pair (f, g) and the variable r. Determine whether. The extraction unit 23 also determines whether or not the execution paths for the same function pair (f, g) and the other variable r1 include the pattern “A-U-F” for the function pair (f, g) and the variable r1. judge. When there are a plurality of variables in which the return value of the called function f is stored, the extraction unit 23 performs the same determination for the execution paths corresponding to all the variables. Then, if there is at least one execution path including “AUF” for all variables storing the return value of the function f, the extraction unit 23 releases the function pair (f, g) as a resource capture function and a resource release. Extract as function pairs. The extraction process by the extraction unit 23 will be described in detail later.

  The storage unit 30 stores information used for processing of each unit in the program analysis device 1 and information generated by the processing of each unit. The storage unit 30 may be a storage device such as a hard disk or an optical disk. The storage unit 30 may be a semiconductor memory such as a RAM (Random Access Memory) or a flash memory.

  The storage unit 30 includes a source code storage unit 31, a subroutine expansion code storage unit 32, a function storage unit 33, an execution path storage unit 34, and a function pair set storage unit 35.

  The source code storage unit 31 stores the source code received by the input unit 10. The subroutine expansion code storage unit 32 stores the subroutine expansion code created by the analysis unit 21 from the source code. The function storage unit 33 stores the full function set F and the full function pair set F × F extracted by the analysis unit 21 from the subroutine expansion code. The execution path storage unit 34 stores the execution path generated by the generation unit 22. The function pair set storage unit 35 stores a function pair set obtained as a result of processing by the extraction unit 23, that is, a function pair determined as a resource capture function and resource release function pair.

  Details of the source code, subroutine expansion code, function, execution path, and function pair set stored in each unit of the storage unit 30 will be described later. However, the source code and subroutine expanded code stored in each part of the storage unit 30 are the same as the source code and subroutine expanded code described in Japanese Patent Application No. 2015-156945. The storage unit 30 may also be configured to store the control flow graph and analysis results described in Japanese Patent Application No. 2015-156945.

  The output unit 40 outputs information acquired as a result of processing by the program analysis apparatus 1. For example, the output unit 40 outputs the function pair extracted by the extraction unit 23 in a visually recognizable format. The output unit 40 may be configured to be connected to a display unit such as a monitor or a printer and output information to the display unit or the printer. The output unit 40 may be configured to include a display unit or a printer. Also good.

[Example of program analysis processing flow]
Next, the operation of the program analysis apparatus 1 in the present embodiment will be described.

  FIG. 4 is a flowchart showing an example of the flow of program analysis processing in the present embodiment.

  The input unit 10 receives input of the source code to be analyzed (step S1).

  The analysis unit 21 analyzes the source code (source code analysis process, step S2). The source code analysis process will be described later.

  The generation unit 22 generates an execution path based on the analysis result of the source code (execution path generation process, step S3). Details of the execution path generation processing will be described later.

  Then, the extraction unit 23 extracts a function pair that matches the appearance pattern of the resource capture function and the resource release function based on the processing result by the generation unit 22 (function pair extraction process, step S4). Details of the function pair extraction process will be described later.

  The output unit 40 outputs the result (function pair) extracted by the extraction unit 23 (step S5).

  Thus, the program analysis process by the program analysis apparatus 1 is completed.

[Example of source code analysis processing flow]
Next, source code analysis processing (corresponding to step S2 in FIG. 4) will be described. Note that the source code analysis processing in the present embodiment described below is the same as the analysis processing described in Japanese Patent Application No. 2015-156945. However, the present embodiment is different in that the analysis unit 21 creates a full function set F and a full function pair set F × F instead of the function list (similar to the full function set F).

  FIG. 5 is a flowchart showing an example of the flow of source code analysis processing. FIG. 6 is a diagram illustrating an example of source code that is an analysis target of the program analysis apparatus 1. 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 21 creates a subroutine development code from the source code input by the input unit 10 (step S21). The created subroutine development code is stored in the subroutine development code storage unit 32. FIG. 7 shows an example of a subroutine expansion code created from the source code of FIG. In the example of FIG. 7, the analysis unit 21 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 21 also 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 and 101B, and the finish function is expanded at the location indicated by reference numeral 102. The abort_program function developed at the position indicated by reference numeral 101B is called from the finish function.

  In the subroutine expansion code, the line number obtained by adding the line number of the original source code to the call source 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 indicated by reference numeral 101A is called on the ninth line of the main function, and the abort_program function is described on the 25th to 27th lines of the source code in FIG. Line numbers 9-25, 9-26, and 9-27 are assigned to the lines of the abort_program function expanded in FIG. In another example, the finish function indicated by reference numeral 102 is called on the 13th line of the main function, and the abort_program function indicated by reference numeral 101B is called on the 24th line of the finish function. Line numbers 13-24-25, 13-24-26, and 13-24-27 are assigned to each line of the abort_program function at the location indicated by reference numeral 101B. If the definition of the subroutine (function) cannot be obtained, the definition code is not added.

  Subsequently, the analysis unit 21 extracts a function from the subroutine expansion code and creates a total function set F (step S22). The created all function set F is stored in the function storage unit 33. FIG. 8A shows the entire function set F extracted from the subroutine expansion code of FIG. The analysis unit 21 assigns a function ID (Identifier) to the extracted function. FIG. 8 is a diagram showing a full function set and a full function pair set of functions extracted from the subroutine expansion code of FIG. As shown in the example of FIG. 8A, the function storage unit 33 stores each function name in association with the function ID.

  The analysis unit 21 also creates a full function pair set F × F based on the created full function set F. FIG. 8B shows an example of a total function pair set F × F created from the total function set F. As shown in FIG. 8B, the function storage unit 33 stores the function ID of the function included in the function pair in association with the pair ID assigned to each function pair.

[Example of execution path generation processing]
Next, execution path generation processing (corresponding to step S3 in FIG. 4) by the generation unit 22 will be described.

  When a loop is included in the source code, there is a problem in that an execution path is created infinitely when a possible execution path is created. This problem will be described with reference to FIG. FIG. 9 is a diagram showing a simplified structure of branches and loops included in the source code.

[Generate nondeterministic execution path]
Consider a case where a non-deterministic execution path is created from source code including a branch and loop structure as shown in FIG. When the example of FIG. 9 is expanded assuming that the inside of the loop is executed once, the following nondeterministic execution path is obtained.
(1) 1-2-3-4-11
(2) 1-2-5-6-11
(3) 1-2-7-8-11
(4) 1-2-9-10-11

Further, if it is expanded assuming that the inside of the loop is executed twice, for example, the following nondeterministic execution path is obtained.
(5) 1-2-3-4-2-3-4-11
(6) 1-2-3-4-2-5-6-11
(7) 1-2-3-4-2-7-8-11
(8) 1-2-3-4-2-9-10-11
When the inside of the loop is executed twice, in addition to the above (5) to (8), 12 further non-deterministic execution paths are obtained depending on the processing order in the branch.

  Furthermore, if the number of executions in the loop is increased to 3 times and 4 times, the number of executions in the loop can be increased infinitely, so the nondeterministic execution path increases infinitely.

[Generate label path]
However, since the program analysis apparatus 1 according to the present embodiment aims to extract a resource capture function and resource release function pair, generation of information not related to pair extraction can be omitted. For example, assume that a nondeterministic execution path shown in FIG. 10 is obtained as a result of creating a nondeterministic execution path from source code including a branch and loop structure. FIG. 10 is a diagram illustrating an example of a set of non-deterministic execution paths for explaining the execution path generation processing.

Then, it is assumed that the program analysis apparatus 1 determines whether or not the function f and the function g are a pair of a resource capture function and a resource release function based on the set of nondeterministic execution paths in FIG. In this case, the program analysis apparatus 1 determines whether or not the nondeterministic execution path includes the function f, the variable r, and the function g in the following order.
(1) r = f ()
(2) some_func (r)
(3) g (r)
Then, in order to extract a pair of a resource capture function and a resource release function based on a non-deterministic execution path, the information of (1), (2), and (3) included in the non-deterministic execution path is sufficient. .

  For example, in the example of FIG. 10, the above (1) is displayed as “A”, (2) as “U”, and (3) as “F”. The first non-deterministic execution path includes only “A”. The second non-deterministic execution path includes “A”, “F”, and “F”. Thus, by extracting only the information “A”, “U”, and “F” from each non-deterministic execution path, the label path shown in FIG. 11 can be obtained. FIG. 11 is a diagram illustrating an example of a set of label paths for explaining the execution path generation process. Since the first non-deterministic execution path in FIG. 10 includes only “A” among “A”, “U”, and “F”, the label path is “A”. Further, the second non-deterministic execution path in FIG. 10 is “A, F, F”, the third non-deterministic execution path is “A, F, F”, and the fourth non-deterministic execution path is “A, U”. , F ”and the fifth non-deterministic execution path can be expressed as“ A, F, F, F ”. By extracting only the information related to the extraction of the pair of the resource capture function and the resource release function, the non-deterministic execution path can be shortened as shown in FIG. As described above, the function (f, g) to be determined as to whether or not it is a pair of the resource capture function and the resource release function and the variable r to which the return value of the function f () is assigned are specified, and the above (1 The execution path created by extracting only the processes corresponding to (3) to (3) from the non-deterministic execution path is called a label path.

[Generate reduced execution path]
However, only by generating a label path, the nondeterministic execution path can be shortened, but the problem that the execution path to be determined increases indefinitely cannot be solved. Therefore, the generation unit 22 next reduces or shortens the label path based on a predetermined condition. In the present embodiment, the following three are defined as a predetermined condition for reduction and a reduction rule.
(1) When “F” appears three times or more, the label path after the second occurrence of “F” is deleted.
(2) When “U” appears more than once after “A”, “U” after the second time is deleted.
(3) When “U” appears more than once after “F”, “U” after the second time is deleted.

  First, the contraction rule (1) will be described. “F” corresponds to a resource release function. Resource release only needs to be performed once after the resource is captured and used, and does not need to be released many times even though the same resource is not captured. Therefore, if “F” appears many times after “A” appears once, it is estimated that “F” is not a resource capture function. The program analysis apparatus 1 determines whether or not the execution path matches the pattern “A, U, F”. For example, the program analysis apparatus 1 determines that neither “A, U, F, F” nor “A, U, F, F, F” matches “A, U, F”. Therefore, as information to be determined by the program analysis apparatus 1, the execution path “A, U, F, F, F” can be included in “A, U, F, F”. Therefore, the program analysis apparatus 1 reduces the label path “A, U, F, F, F” to the reduced execution path “A, U, F, F”. In this way, the program analysis apparatus 1 allows the label path after the second “F” (in this case, the third “F”) when “F” appears three times or more after one “A” in the label path. F ") is deleted.

  Next, the contract rule (2) will be described. If “A” is a resource capture function, the captured resource can be used any number of times until it is released after “A”. Therefore, the number of occurrences of “U” after “A” has no meaning in the determination by the program analysis apparatus 1, and “U” may appear at least once. Therefore, after “A”, if “U” appears more than once, “U” for the second and subsequent times is deleted. For example, when a label path “A, U, U” is created, the program analysis apparatus 1 contracts the label path to create a reduced execution label “A, U”.

  Next, the contract rule (3) will be described. If “F” is a resource release function, after the resource is released by F, there is no process of using the resource without capturing it. Therefore, “U” does not appear after “F”. If “U” appears, it can be estimated that “F” is not a resource release function paired with “A” regardless of the number of times. Therefore, when “U” appears twice or more after “F” in the label path, “U” for the second and subsequent times is deleted. For example, when the label path “A, U, F, U, U” is generated, the program analysis apparatus 1 deletes one of the two “U” s after “F” and reduces the contract execution path “ A, U, F, U ".

[Delete duplicate reduction execution path]
As described above, the program analysis apparatus 1 according to the embodiment generates a label path from a non-deterministic execution path and a reduced execution path from a label path. As a result of this process, redundant portions of the non-deterministic execution path are deleted, and the same reduced execution path may be generated from different non-deterministic execution paths. Therefore, if there are duplicates in the reduced execution paths created for the same function (f, g) and variable r, the redundant reduced execution paths are deleted.

[Loop limit]
Next, processing for preventing infinite expansion of the loop will be described. As described above, when the nondeterministic execution path is reduced to information necessary for extraction of the resource capturing function and the resource release function and contracted, only the same contracted execution path can be obtained after repeating the loop a predetermined number of times. For example, if the loop portion of the contracted path “A, U” is “U”, the second and subsequent “U” are deleted by the contract rule (2) no matter how many times the loop is repeated. Therefore, it becomes only “A, U”. Therefore, in the program analysis apparatus 1 according to the present embodiment, a combination of contracted execution paths obtained by removing duplicates from contracted execution paths generated by repeating a loop n times and a loop generated n-1 times are generated. When the combination of the reduced execution paths obtained by removing the duplicates from the reduced execution paths becomes the same, the loop repetition, that is, the execution path generation process is terminated.

[Example of Flow of Execution Path Generation Processing by Generation Unit 22]
Next, the execution path generation process will be described more specifically with reference to FIGS. 12 to 17 are diagrams for explaining a case where a reduced execution path is generated by executing a loop once to six times in the execution path generation process.

[When loop is executed once]
First, the program control apparatus 1 generates a nondeterministic execution path for the source code having the loop structure shown in FIG. The function pair to be processed is (f, g), and the resource storage variable is r. In FIG. 12A, the process “1” is a process (“A”) that calls the function f () and stores it in a variable (“A”), and the process “3” is a process that uses the captured resource r (“U”). The process “5” is a function g () (“F”) with the captured resource r as an argument. It is assumed that there are no processes corresponding to “A”, “U”, and “F” other than the processes “1”, “3”, and “5”.

First, the generation unit 22 generates a nondeterministic execution path when the loop is executed once ((B) of FIG. 12).
(1) 1-2-3-4-7
(2) 1-2-5-6-7

Then, the generation unit 22 converts the nondeterministic execution path into a label path. That is, the generation unit 22 replaces “1”, “3”, and “5” with “A”, “U”, and “F”, respectively, deletes other processes, and generates the following label paths ( (C) of FIG.
(1) AU
(2) AF

  Since none of the label paths matches the reduction rules (1) to (3), the reduction execution path is the same as the label path ((D) in FIG. 12).

  Furthermore, since there are no overlapping contraction execution paths, there is no contraction execution path to be deleted ((E) in FIG. 12).

[When loop is executed twice]
Next, the generation unit 22 executes the loop twice. In this case, the non-deterministic execution path is as follows:
(1) 1-2-3-4-2-3-4-7
(2) 1-2-3-4-2-5-6-7
(3) 1-2-5-6-2-3-4-7
(4) 1-2-5-6-2-5-6-7

In the actual processing of the generating unit 22, the first contracted execution path for the loop has already been generated, so the label for the second loop is added to the contracted execution path for the first loop to generate the second label path for the loop. do it. The label path for the second loop is as follows ((A) in FIG. 13).
(1) AUU
(2) AUF
(3) AFU
(4) AFF

Among the generated label paths, (1) is reduced to “AU” because it matches the reduction rule (2) ((B) of FIG. 13). Other than (1), there is no label path that matches the contract rule. Further, since there is no overlap, the contracted execution path generated by executing the loop twice is as follows ((C) of FIG. 13).
(1) AU
(2) AUF
(3) AFU
(4) AFF

  The contracted execution path when the loop is executed once is different from the contracted execution path when the loop is executed twice. For this reason, the repetition of the loop does not end, and the generation unit 22 proceeds to an execution path generation process at the time of executing the loop three times.

[When loop is executed 3 times]
Next, the generation unit 22 generates a label path when the loop is executed three times ((A) in FIG. 14).
(1) AUU
(2) AUF
(3) AUFU
(4) AUFF
(5) AFUU
(6) AFUF
(7) AFFU
(8) AFFF

Since “AUU” matches the contract rule (2) in the label path, the generation unit 22 contracts “AUU” to “AU”. Since “AFUU” matches the contract rule (3), the generation unit 22 contracts “AFUU” to “AFU”. Since “AFFF” matches the contract rule (1), the generation unit 22 contracts “AFFF” to “AFF”. As a result, the contraction execution path is as follows ((B) in FIG. 14). The contract execution path after contracting the label path is shown on the right side of the arrow.
(1) AUU → AU
(2) AUF
(3) AUFU
(4) AUFF
(5) AFUU → AFU
(6) AFUF
(7) AFFU
(8) AFFF → AFF

  There is no overlap in the contraction execution paths (1) to (8) ((C) in FIG. 14). Further, since the contracted execution path when the loop is executed twice is not the same as the contracted execution path when the loop is executed three times, the program analysis apparatus 1 proceeds to an execution path generation process when the loop is executed four times.

[When loop is executed 4 times]
Next, the generation unit 22 generates a label path when the loop is executed four times ((A) in FIG. 15).
(1) AUU (2) AUF
(3) AUFU (4) AUFF
(5) AUFUU (6) AUFUU
(7) AUFFU (8) AUFFF
(9) AFUU (10) AFUF
(11) AFUFU (12) AFUFF
(13) AFFFU (14) AFFUF
(15) AFFU (16) AFFF

Among them, “AUFFF”, “AFUFF”, “AFFUF”, “AFFF”, “F” appears three times and matches the contraction rule (1). “AUU” matches the contract rule (2). In addition, “AUFUU”, “AFUUU”, and “AFUFUU” match the contraction rule (3). For this reason, the contracted execution path when the loop is executed four times is as follows ((B) of FIG. 15).
(1) AUU → AU (2) AUF
(3) AUFU (4) AUFF
(5) AUFUU → AUFU (6) AUFUF
(7) AUFFU (8) AUFFF → AUFF
(9) AFUU → AFU (10) AFUF
(11) AFUFU (12) AFUFF → AFUF
(13) AFFUU → AFFU (14) AFFFU → AFF
(15) AFFU (16) AFFF → AFF

  (3) and (5), (4) and (8), (10) and (12), (13) and (15), and (14) and (16) overlap each other in the above reduction execution path To do. Therefore, the generation unit 22 deletes a total of five (5), (8), (12), (14), and (15) so that there is no duplication, and leaves the remaining 11 as reduced execution paths. ((C) of FIG. 15). As a result, the reduced execution path set shown in FIG. 15D is obtained.

  Since the contracted execution path when the loop is executed three times is not the same as the contracted execution path when the loop is executed four times, the program analysis apparatus 1 proceeds to an execution path generation process when the loop is executed five times.

[When loop is executed 5 times]
Next, the generation unit 22 generates a label path when the loop is executed five times ((A) in FIG. 16).
(1) AUU (2) AUF
(3) AUFU (4) AUFF
(5) AUFUU (6) AUFUU
(7) AUFFU (8) AUFFF
(9) AUFUFU (10) AUFUFF
(11) AUFFUU (12) AUFFUUF
(13) AFUU (14) AFUF
(15) AFUFU (16) AFUFF
(17) AFUFUU (18) AFUFUUF
(19) AFFFU (20) AFFUF
(21) AFFU (22) AFFF

Of these, (8) AUFFF, (10) AUFUFF, (12) AUFFUF, (16) AFUFF, (18) AFUFUUF, (20) AFFUF, and (22) AFFF match the contraction rule (1). Further, (1) AUU matches the contract rule (2). Further, (5) AUFUU, (11) AUFUFUU, (13) AFUUU, (17) AFUFUU, and (19) AFUFUU match the contract rule (3). Therefore, the generation unit 22 contracts each label path that matches the contract rule, and generates the following contract execution path (FIG. 16B).
(1) AUU → AU (2) AUF
(3) AUFU (4) AUFF
(5) AUFUU → AUFU (6) AUFUF
(7) AUFFU (8) AUFFF → AUFF
(9) AUFUFU (10) AUFUFF → AUFUFU
(11) AUFFUU → AUFFU (12) AUFFUFU → AUFF
(13) AFUU → AFU (14) AFUF
(15) AFUFU (16) AFUFF → AFUF
(17) AFUFUU → AFUFU (18) AFUFUU → AFUFU
(19) AFUFU → AFFU (20) AFFFU → AFF
(21) AFFU (22) AFFF → AFF

Of the above reduction execution paths, (3) and (5), (7) and (11), (6) and (10), (19) and (21), (4) and (8) and (12 ), (15) and (17), (14) and (16) and (18), and (20) and (22) overlap. Therefore, the generation unit 22 has a total of ten (3), (8), (10), (11), (12), (16), (17), (18), (20), and (21). Is deleted. As a result, the contracted execution paths when the loop is executed five times are as follows ((C) in FIG. 16).
(1) AU
(2) AUF
(4) AUFF
(5) AUFU
(6) AUFUF
(7) AUFFU
(9) AUFUFU
(13) AFU
(14) AFUF
(15) AFUFU
(19) AFFU
(22) AFF

  Since the contracted execution path when the loop is executed four times and the contracted execution path when the loop is executed five times ((D) in FIG. 16) are not the same, the program analyzing apparatus 1 executes the execution path when the loop is executed six times. Proceed to the generation process.

[When loop is executed 6 times]
Next, the generation unit 22 generates a label path when the loop is executed six times ((A) in FIG. 17).
(1) AUU (2) AUF
(3) AUFUU (4) AUFUU
(5) AUFUFUU (6) AUFUFUU
(7) AFUU (8) AFUF
(9) AUFU (10) AUFF
(11) AUFFU (12) AUFFF
(13) AUFUFU (14) AUFUFF
(15) AUFFUU (16) AUFFUUF
(17) AFUFU (18) AFUFF
(19) AFUFUU (20) AFUFUUF
(21) AFFFU (22) AFFUF
(23) AFFU (24) AFFF

Among the above label paths, (6) AUFUFUF, (12) AUFFF, (14) AUFUFF, (16) AUFFUF, (18) AFUFF, (20) AFUFUUF, (22) AFFUF, (24) AFFF are reduced rules ( It matches 1). Further, (1) AUU matches the contract rule (2). Further, (3) AUFUU, (5) AUFUFUU, (7) AFUU, (15) AUFUFUU, (19) AFUFUU, and (21) AFUFUU match the reduction rule (3). Therefore, the generation unit 22 contracts each label path that matches the contract rule, and generates the following contract execution path (FIG. 17B).
(1) AUU → AU (2) AUF
(3) AUFUU → AUFU (4) AUFUF
(5) AUFUFUU → AUFUFU (6) AUFUFUU → AUFUFU
(7) AFUU → AFU (8) AFUF
(9) AUFU (10) AUFF
(11) AUFFU (12) AUFFF → AUFF
(13) AUFUFU (14) AUFUFF → AUFUFU
(15) AUFFUU → AUFFU (16) AUFFUFU → AUFF
(17) AFUFU (18) AFUFF → AFUF
(19) AFUFUU → AFUFU (20) AFUFUU → AFUFU
(21) AFFUU → AFFU (22) AFFFU → AFF
(23) AFFU (24) AFFF → AFF

Among the above reduction execution paths, (3) and (9), (4) and (6) and (14), (5) and (13), (8), (18), (20), (10 ) And (12) and (16), (11) and (15), (17) and (19), (21) and (23), and (22) and (24) are the same. Therefore, the generation unit 22 (3), (4), (5), (6), (8), (10), (11), (16), (17), (18), (21), A total of 12 of (22) are deleted ((C) of FIG. 17). As a result, the contracted execution paths when the loop is executed six times are as follows ((D) in FIG. 17).
(1) AU
(2) AUF
(7) AFU
(9) AUFU
(12) AUFF
(13) AUFUFU
(14) AUFUF
(15) AUFFU
(19) AFUFU
(20) AFUF
(23) AFFU
(24) AFF

  The contracted execution path when the loop is executed five times and the contracted execution path when the loop is executed six times are the same. Therefore, the generation unit 22 ends the execution path generation process without repeating the loop seven times or more.

  FIG. 18 is a diagram for explaining the reduced execution path generated in the execution path generation process shown in FIGS. 12 to 17. In FIG. 18, labels that are deleted according to the contraction rule are marked with a double strikethrough, and contraction execution paths that are deleted due to duplication are shaded.

[Example of execution path generation processing flow]
FIG. 19 is a flowchart illustrating an example of a flow of execution path generation processing according to the embodiment. First, the generation unit 22 receives a setting of n = 1 (step S1801). Here, n is a natural number for setting the number of executions in the loop. Next, the generation unit 22 creates a nondeterministic execution path obtained by executing the inside of the loop n times (step S1802). Then, the generation unit 22 selects one function pair (f, g) from the entire function pair set F × F stored in the function storage unit 33 (step S1803). The generation unit 22 further selects r, which is a resource capture variable (step S1803). Based on the selected function pair (f, g) and variable r, the generation unit 22 extracts processing elements corresponding to the labels “A”, “U”, and “F” among the processing elements of the non-deterministic execution path, A label path is generated (step S1804). Further, the generation unit 22 applies the reduction rules (1), (2), and (3) to the generated label path to generate a reduction execution path (step S1805). Then, the generation unit 22 determines whether or not the generated contracted execution path has an overlap, and if there is an overlap, deletes the overlapping contracted execution path (step S1806). Then, the generation unit 22 determines whether or not the contraction execution path when the loop is executed n times and the contraction execution path when the loop is executed n-1 times are matched (step S1807). When it determines with matching (step S1807, Yes), the production | generation part 22 complete | finishes an execution path production | generation process. On the other hand, if it is determined that they do not match (No in step S1807), the generation unit 22 sets n = n + 1 (S1808), increases the number of loop executions, and repeats steps S1802 to S1807. Thereby, the execution path generation process for the function pair (f, g) and the variable r is completed.

  The execution path generation process is repeated for all function pairs included in the all function pair set F × F in the function storage unit 33. In addition, since the resource storage variable r is not limited to one, the execution path generation process is repeated for a plurality of resource storage variables r and each function pair. As a result, a different reduced execution path set is generated for each combination of the function pair and the variable r. FIG. 20 is a diagram illustrating an example of a configuration of information generated by the execution path generation processing according to the embodiment and stored in the execution path storage unit 34.

  As illustrated in FIG. 20, the execution path storage unit 34 stores “function pair”, “variable”, “contracted execution path”, and “flag”. “Function pair” indicates a function pair (f, g) used to generate a reduced execution path. “Variable” indicates the variable r used to generate the reduced execution path. Further, “reduced execution path” indicates a set of reduced execution paths generated as a result of the execution path generation process. The “flag” is a mark given to a contraction execution path determined to include a predetermined pattern “AUF” in a function pair extraction process described later.

[Example of function pair extraction process flow]
Next, function pair extraction processing by the extraction unit 23 will be described. FIG. 21 is a flowchart illustrating an exemplary flow of a function pair extraction process according to the embodiment. The extraction unit 23 executes the function pair extraction process when the generation of the contracted execution path by the generating unit 22 is completed and the information of the generated contracted execution path is stored in the execution path storage unit 34.

  First, the extraction unit 23 selects a function pair (f, g) and a variable r (step S2001). The extracting unit 23 then selects one of the reduced execution paths stored in association with the selected function pair (f, g) and the variable r among the reduced execution paths stored in the execution path storage unit 34. Is selected (step S2002). The extraction unit 23 determines whether or not the selected reduction execution path matches the appearance pattern of the resource capture function and the resource release function, that is, “AUF” (step S2003). At this time, the extraction unit 23 determines whether or not only “AUF” is included. In other words, the extraction unit 23 includes the appearance pattern of “AUF” such as “AUFU”, “AUFUF”, “AUFF”, etc., but the reduced execution path including the pattern other than “AUF” matches the appearance pattern of “AUF”. Judge that not.

  If the extraction unit 23 determines that it matches the appearance pattern of “AUF” (step S2003, YES), the extraction unit 23 stores a flag in the execution path storage unit 34 in association with the reduced execution path (step S2004). Then, the extraction unit 23 determines whether there is another unselected degeneration execution path stored in association with the function pair (f, g) and the variable r (step S2005). If the extraction unit 23 determines that the appearance pattern of “AUF” is not included (step S2003, NO), the extraction unit 23 proceeds to step S2005 as it is.

  When it is determined that there is an unselected reduction execution path (YES in step S2005), the extraction unit 23 selects the next unselected reduction execution path (step S2006). Then, the extraction unit 23 repeats the processing from step S2003 to S2005 for the selected contraction execution path. On the other hand, if the extraction unit 23 determines that there is no unselected contracted execution path (NO in step S2005), it is stored in the execution path storage unit 34 in association with another function pair (f, g). It is determined whether or not there is a resource storage variable r (step S2007). If it is determined that there is another resource storage variable r (step S2007, YES), the extraction unit 23 selects one of the other resource storage variables r (step S2008). And the extraction part 23 repeats the process of step S2002 to S2007. On the other hand, if it is determined that there is no other resource storage variable r (step S2007, NO), the extraction unit 23 stores the function pair (f, g) in association with each resource storage variable r in the execution path storage unit 34. It is determined whether or not at least one contracted execution path is flagged in each of the contracted execution path sets to be performed (step S2009). When the extraction unit 23 determines that all sets include at least one contracted execution path with a flag (YES in step S2009), the function pair (f, g) is determined as a resource capture function. And a resource release function candidate pair are extracted (step S2010). The extracted function pair is stored in the function pair set storage unit 35. Then, the extraction unit 23 determines whether or not there is a next unselected function pair in the all function pair set F × F stored in the function storage unit 33 (step S2011). If it is determined that there is a next function pair (step S2011, YES), the extraction unit 23 selects the next function pair and variable (step S2012), and returns to step S2002. On the other hand, when it is determined that there is no next function pair (step S2011, NO), that is, when the function pair extraction process is completed for all function pairs stored in the all function pair set F × F, the extraction unit 23 The function pair extraction process ends. On the other hand, when it is determined in step S2009 that there is a set of reduced execution paths to which no reduced execution path has a flag (NO in step S2009), the extraction unit 23 extracts the function pair. Instead, the process proceeds to step S2011.

[Effect of the embodiment]
As described above, in the program analysis device according to the present embodiment, when a loop is included in the execution path in the source code where processing may be traced from the position where the first function (function f) is called. To deal with. The program analysis device generates an execution path that the process may follow for each case where the loop is repeatedly executed from 1 to n times (n is a natural number of 2 or more). Then, the program analysis apparatus differs from the first function in the generated execution path, unlike the first function (function f), the variable (r) for storing the return value of the first function, and the first function. When the appearance pattern of the second function (function g) having a variable for storing the return value of the function as an argument matches the appearance pattern of the resource capture function and the resource release function, the first function and the second function The function is extracted as a resource capture function and resource release function pair. For this reason, the program analysis apparatus of the embodiment extracts a pair of a resource capture function and a resource release function in consideration of a case where a loop is included in the source code and is executed a predetermined number of times. Can do.

  In addition, the program analysis apparatus according to the present embodiment includes a first process for storing the return value of the first function in a variable, and a third function that uses the variable as an argument and is different from the first and second functions. An execution path indicating only the appearance order of the second process for calling the second process and the third process for calling the second function with the variable as an argument is generated. For this reason, the program analysis device can execute processing by discarding elements that do not affect the determination of whether or not the resource capture function and the resource release function are a pair. For this reason, the program analysis apparatus of the embodiment can improve the processing efficiency and the processing speed.

  In addition, the program analysis apparatus according to the present embodiment causes the resource capture function and the resource release function to appear when the first and second functions are the resource capture function and the resource release function in the generated execution path. If there is a part that does not match the pattern, the execution path is shortened by deleting the part that does not match partly. Therefore, the program analysis apparatus according to the embodiment can easily determine an execution path including a pattern that clearly does not match the appearance pattern of the resource capture function and the resource release function.

In addition, the program analysis apparatus according to the present embodiment has the generated execution path as follows:
(1) When three or more third processes are included, the processes after the appearance of the second third process are deleted,
(2) After including the second process after the first process, the second process after the second is deleted,
(3) After including the second process after the third process, the second process after the second time is deleted.
This shortens the execution path. Therefore, the program analysis apparatus according to the embodiment can easily determine an execution path including a pattern that clearly does not match the appearance pattern of the resource capture function and the resource release function.

  In addition, the program analysis apparatus according to the present embodiment has a case where the execution path obtained when the loop is executed n times is equal to the execution path obtained when the loop is executed (n−1) times. Finally, the generation of the execution path is finished. Therefore, the program analysis apparatus according to the embodiment can efficiently extract a resource capture function and resource release function pair without repeating the loop infinitely.

  In addition, the program analysis apparatus according to the present embodiment has one or more executions that can be traced from each position when there are a plurality of positions in the source code where the first function is called and the return value is stored in the variable. The first function and the second function are extracted on condition that at least one execution path that matches the appearance pattern of the resource capture function and the resource release function exists. Therefore, when the same function is called at different positions, the program analysis apparatus extracts the function after confirming that it matches the appearance pattern of the resource capture function and the resource release function at any position. be able to. For this reason, the program analysis apparatus can extract the resource capture function and the resource release function with high accuracy.

[program]
It is also possible to create a program in which processing executed by the program analysis device 1 described in the above embodiment is described in a language that can be executed by a computer. For example, a program analysis program in which processing executed by the program analysis apparatus 1 according to the embodiment is described in a language that can be executed by a computer can be created. In this case, when the computer executes the program analysis program, the same effects as in the above embodiment can be obtained. Further, the program analysis program may be recorded on a computer-readable recording medium, and the program analysis program recorded on the recording medium may be read and executed by the computer to execute the same processing as in the above embodiment. Good.

  FIG. 22 is a diagram illustrating a computer 1000 that executes a program analysis program. As illustrated in FIG. 22, the computer 1000 includes, for example, a memory 1010, a CPU 1020, a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These units are connected by a bus 1080.

  The memory 1010 includes a ROM (Read Only Memory) 1011 and a RAM 1012 as illustrated in FIG. The ROM 1011 stores a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1031 as illustrated in FIG. The disk drive interface 1040 is connected to the disk drive 1041 as illustrated in FIG. For example, a removable storage medium such as a magnetic disk or an optical disk is inserted into the disk drive 1041. The serial port interface 1050 is connected to, for example, a mouse 1051 and a keyboard 1052 as illustrated in FIG. The video adapter 1060 is connected to a display 1061, for example, as illustrated in FIG.

  Here, as illustrated in FIG. 22, the hard disk drive 1031 stores, for example, an OS 1091, an application program 1092, a program module 1093, and program data 1094. That is, the program analysis program is stored in, for example, the hard disk drive 1031 as a program module in which a command executed by the computer 1000 is described.

  The various data described in the above embodiment is stored as program data, for example, in the memory 1010 or the hard disk drive 1031. Then, the CPU 1020 reads the program module 1093 and the program data 1094 stored in the memory 1010 and the hard disk drive 1031 to the RAM 1012 as necessary, and executes various processing procedures.

  Note that the program module 1093 and the program data 1094 related to the program analysis program are not limited to being stored in the hard disk drive 1031, but are stored in, for example, a removable storage medium and read out by the CPU 1020 via the disk drive or the like. Also good. Alternatively, the program module 1093 and the program data 1094 related to the program analysis program are stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.), and the network interface 1070 is stored. Via the CPU 1020.

  Of the processes described in this embodiment, all or part of the processes described as being performed automatically can be performed manually, or the processes described as being performed manually can be performed. All or a part can be automatically performed by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-described document and drawings can be arbitrarily changed unless otherwise specified.

  The above embodiments and modifications thereof are included in the invention disclosed in the claims and equivalents thereof as well as included in the technology disclosed in the present application.

DESCRIPTION OF SYMBOLS 1 Program analyzer 10 Input part 20 Control part 21 Analysis part 22 Generation part 23 Extraction part 30 Storage part 31 Source code storage part 32 Subroutine expansion code storage part 33 Function storage part 34 Execution path storage part 35 Function pair set storage part 40 Output Part

Claims (8)

In the source code, when a loop is included in the execution path that may be traced from the position where the first function is called, the loop is repeated from 1 to n times (n is a natural number of 2 or more). For each execution, a generation unit that generates an execution path that the process may follow,
In the generated execution path, the first function, a variable that stores the return value of the first function, and the variable that stores the return value of the first function unlike the first function When the appearance pattern of the second function as an argument matches the appearance pattern of the resource capture function and the resource release function, the first function and the second function are used as the resource capture function and the resource release function. An extractor for extracting as a pair;
Equipped with a,
The generation unit stores a return value of the first function in the variable, and a second function that calls a third function different from the first and second functions using the variable as an argument. An execution path indicating only an appearance order of a process and a third process for calling the second function having the variable as an argument is generated . In the generated execution path, when the first and second functions are a resource capture function and a resource release function, the generation unit includes a portion that does not match the appearance pattern of the resource capture function and the resource release function. in some cases, by deleting leaving some portions do not match, the program analyzing device according to claim 1, characterized in that to shorten the execution path. The generation unit generates the generated execution path as follows:
(1) When three or more of the third processes are included, a process after the appearance of the third process for the second time is deleted,
(2) After the first process, when the second process includes two or more, delete the second process after the second time,
(3) After the third process, when the second process includes two or more, the second process after the second is deleted.
The program analysis apparatus according to claim 2 , wherein the execution path is shortened. In the source code, when a loop is included in the execution path that may be traced from the position where the first function is called, the loop is repeated from 1 to n times (n is a natural number of 2 or more). For each execution, a generation unit that generates an execution path that the process may follow,
In the generated execution path, the first function, a variable that stores the return value of the first function, and the variable that stores the return value of the first function unlike the first function When the appearance pattern of the second function as an argument matches the appearance pattern of the resource capture function and the resource release function, the first function and the second function are used as the resource capture function and the resource release function. An extractor for extracting as a pair;
With
When the execution path obtained when the loop is executed n times is equal to the execution path obtained when the loop is executed (n-1) times, the generation unit features and to Help program analyzer to terminate the generation. In the case where there are a plurality of positions in the source code where the first function is called and a return value is stored in a variable, the extraction unit includes the appearance among one or more execution paths that can be traced from each position. on the condition that the execution path that matches the pattern is at least one presence, according to any one of claims 1 4, characterized in that to extract said first function and said second function Program analysis device. In the source code, when a loop is included in the execution path that may be traced from the position where the first function is called, the loop is repeated from 1 to n times (n is a natural number of 2 or more). For each execution, a generation process that generates an execution path that the process may follow,
Appearance of the first function, a variable for storing a return value of the first function, and a second function having the variable as an argument unlike the first function in the generated execution path An extraction step of extracting the first function and the second function as a pair of a resource capture function and a resource release function when the pattern matches an appearance pattern of a resource capture function and a resource release function;
The computer runs ,
The generating step includes a first process for storing a return value of the first function in the variable, and a second function for calling a third function different from the first and second functions using the variable as an argument. An execution path indicating only an appearance order of the process and a third process for calling the second function having the variable as an argument is generated .   In the source code, when a loop is included in the execution path that may be traced from the position where the first function is called, the loop is repeated from 1 to n times (n is a natural number of 2 or more). For each execution, a generation process that generates an execution path that the process may follow,
  Appearance of the first function, a variable for storing a return value of the first function, and a second function having the variable as an argument unlike the first function in the generated execution path An extraction step of extracting the first function and the second function as a pair of a resource capture function and a resource release function when the pattern matches an appearance pattern of a resource capture function and a resource release function;
  The computer runs,
  In the generation step, the execution path obtained when the loop is executed n times is equal to the execution path obtained when the loop is executed (n−1) times. A program analysis method characterized by terminating generation. The program analysis program for functioning a computer as a program analysis apparatus of any one of Claims 1-5 .

Images