Fault analysis support device and fault analysis support method

Abstract

To effectively avoid duplication of analysis and correction for a plurality of defects in one program to enable a support of consistent correction.SOLUTION: A defect analysis support apparatus 100 comprises: a storage apparatus 101 for storing a source code of software to be processed; and a computation unit 104 for regenerating all defect occurrence paths based on the source code, merging all defect occurrence paths, generating a defect occurrence graph that integrates information about variable definitions and usage in the occurrence paths, searching for an instance corresponding to a predefined defect relation pattern regarding the relation between defects in the defect occurrence graph, and outputting the search results to a predetermined apparatus.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a malfunction analysis support device and a malfunction analysis support method. [Background technology]

[0002] Among various types of software, for example, embedded control software controls industrial equipment, and the occurrence of defects in the software directly affects manufacturing quality, such as yield and recalls. Therefore, when developing the software, testing is carried out to identify and correct defects before release. In this testing, inputs and outputs of the software are created in advance as test cases, and it is confirmed whether the software returns the correct output expected for the input of the test cases.

[0003] If such testing reveals a defect, the developer analyzes which part of the software performed the unexpected processing, identifies the cause, and modifies the program logic so that it performs appropriate input and output.

[0004] As a conventional technique related to verifying such defects, a technique for evaluating how a fault propagates in a software component based on the specifications of the software component (see Patent Document 1) has been proposed.

[0005] This technology is a method for evaluating the reliability of a software component, which executes the following steps: a specification information acquisition step in which a computer having a formal verification function of a model acquires specification information including an input interface specification, an output interface specification, and an internal specification of a software component; a verification step in which the formal verification function verifies the software component in accordance with specification information in which the input interface specification in the specification information has been changed to a value other than a normal value; and, if an example of an output value that does not satisfy the output interface specification is discovered in the verification step, a fault propagation path storage step in which the input that has been changed to a value other than the normal value and an output that does not satisfy the output interface specification are stored in association with each other. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2012-128727 A Summary of the Invention [Problem to be solved by the invention]

[0007] In a control program that calculates an output from an input, the program may process most inputs correctly, but may perform incorrect processing under very rare conditions. This type of failure is called a non-reproducible failure, and it is difficult to identify the rare conditions under which the failure occurs. The conventional techniques are expected to effectively avoid such a situation and make the failure analysis more efficient. However, there remains a problem in dealing with a case where the log used for the failure analysis contains information on many failures, that is, a case where many failures occur simultaneously.

[0008] For example, defects are analyzed one by one in sequence, so only one defect is analyzed at a time. In that case, for example, even if analysis and correction are performed to address a defect A in a certain function, another analysis and correction will be required for a defect B in the same function, resulting in duplicate analysis and correction for the defect. There is a possibility that.

[0009] In addition, in a situation where different functions are linked together, if the bugs in each function are also linked, and a fix for one bug is implemented with a contradictory fix for the other bug, the other bug may reappear. This problem becomes more serious when each person in charge analyzes and fixes a bug without being aware of the bugs other than his or her own, their analysis results, and their fixes.

[0010] Therefore, an object of the present invention is to provide a technique that can effectively avoid duplication of analysis and correction for multiple defects contained in a single program and can support consistent correction. [Means for solving the problem]

[0011] The problem analysis support device of the present invention, which solves the above-mentioned problems, comprises a storage device that stores source code of software to be processed, Function call relationships in Based on a symbolic execution analysis route that passes through all target functions that are functions including a fault location is calculated, a fault condition is integrated into the target function in the symbolic execution analysis route, and then symbolic execution is performed from the function in the symbolic execution analysis route that has the smallest execution order, thereby acquiring information including an execution path and constraints for all functions in the symbolic execution analysis route, and acquiring a fault occurrence path that is an execution path that ends at the fault location after the integration; A process to regenerate all the fault paths; Definition information of variables of the fault occurrence path is set in the nodes, a usage method of the variables set in the nodes is set as a data flow, and the nodes are connected with edges in the order described in the fault occurrence path, A process of generating a defect occurrence graph, and a process of calculating a relationship between defects in the defect occurrence graph. A pattern of defect relationships that specifies mutual dependencies based on the presence or absence of shared nodes or edges. and a calculation device that executes a process of searching for an instance corresponding to the object, and a process of outputting a result of the search to a predetermined device. Further, the defect analysis support method of the present invention includes the steps of: an information processing device storing source code of software to be processed in a storage device; Function call relationships in Based on a symbolic execution analysis route that passes through all target functions that are functions including a fault location is calculated, a fault condition is integrated into the target function in the symbolic execution analysis route, and then symbolic execution is performed from the function in the symbolic execution analysis route that has the smallest execution order, thereby acquiring information including an execution path and constraints for all functions in the symbolic execution analysis route, and acquiring a fault occurrence path that is an execution path that ends at the fault location after the integration; A process to regenerate all the fault paths; Definition information of variables of the fault occurrence path is set in the nodes, a usage method of the variables set in the nodes is set as a data flow, and the nodes are connected with edges in the order described in the fault occurrence path, A process of generating a defect occurrence graph, and a process of calculating a relationship between defects in the defect occurrence graph. A pattern of defect relationships that specifies mutual dependencies based on the presence or absence of shared nodes or edges.and outputting the results of the search to a predetermined device. Effect of the Invention

[0012] According to the present invention, it is possible to effectively avoid duplication of analysis and correction for multiple defects contained in one program, and to support consistent correction. [Brief description of the drawings]

[0013] [Figure 1] 1 is a diagram showing a system configuration including a defect analysis support device according to an embodiment of the present invention; [Diagram 2] FIG. 2 is a diagram illustrating an example of a hardware configuration of the defect analysis support device according to the present embodiment. [Diagram 3] FIG. 2 is a diagram showing an example of a flow of a defect analysis support method according to the present embodiment. [Figure 4] FIG. 4 is a diagram illustrating an example of source code according to the present embodiment. [Diagram 5] FIG. 13 is a diagram illustrating a conceptual example of regenerating a defective path according to the present embodiment. [Figure 6] FIG. 2 is a diagram showing an example of a flow of a defect analysis support method according to the present embodiment. [Figure 7A] FIG. 2 is a diagram showing an example of a flow of a defect analysis support method according to the present embodiment. [Figure 7B] FIG. 2 is a diagram illustrating an example of a symbolic execution analysis route according to the present embodiment. [Figure 8] FIG. 2 is a diagram illustrating an example of a symbolic execution analysis route in the present embodiment. [Figure 9] 11 is a diagram showing an example of integrating defect information into a target function in the present embodiment; FIG. [Figure 10] FIG. 4 is a diagram illustrating an example of an execution path in the present embodiment. [Figure 11] FIG. 13 is a diagram illustrating an example of a defect occurrence path in this embodiment. [Figure 12] FIG. 2 is a diagram showing an example of a flow of a defect analysis support method according to the present embodiment. [Figure 13]FIG. 11 is a diagram illustrating an example of code according to the present embodiment. [Figure 14] 11 is a diagram illustrating an example of extraction of a defect occurrence path in this embodiment. FIG. [Figure 15] FIG. 11 is a diagram showing an example of a defect occurrence graph in the present embodiment. [Figure 16] FIG. 2 is a diagram showing an example of a flow of a defect analysis support method according to the present embodiment. [Figure 17] FIG. 2 is a diagram showing an example of a flow of a defect analysis support method according to the present embodiment. [Figure 18] FIG. 13 is a diagram showing an example of a defect occurrence graph according to the present embodiment. [Figure 19A] FIG. 4 is a diagram showing an example of a defect-related pattern in the present embodiment. [Figure 19B] FIG. 4 is a diagram showing an example of a defect-related pattern in the present embodiment. [Figure 19C] FIG. 4 is a diagram showing an example of a defect-related pattern in the present embodiment. [Figure 20] FIG. 11 is a diagram illustrating an example of calculation of data correlation in the present embodiment. [Figure 21] FIG. 13 is a diagram showing an example of a result display in this embodiment. [Figure 22] FIG. 13 is a diagram showing an example of a result display in this embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] <Configuration including failure analysis support device> Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Fig. 1 is a configuration diagram of a system including a defect analysis support device 100 of this embodiment. The defect analysis support device 100 shown in Fig. 1 is a computer that can effectively avoid duplication of analysis and correction for multiple defects contained in one program and can support consistent correction.

[0015] 1, the malfunction analysis support device 100 of this embodiment is communicably connected to a terminal 5 connected via an appropriate interface 1 (or a communication line). Therefore, these may be collectively referred to as a malfunction analysis support system 10.

[0016] The failure analysis support device 100 can also be said to be a server that provides a failure analysis support service and is operated, for example, by a company responsible for system development or a vendor that supports the company.

[0017] This fault analysis support device 100 acquires information on source code 125, fault log 136, and fault relationship pattern definition 127 from terminal 5, and stores various information 130-134 generated based on these in its own storage device 101. The various information 130-134 are, for example, a fault occurrence path 130, a fault occurrence graph 131, a fault variable definition 132, a fault relationship pattern definition 133, and a fault relationship pattern instance 134. These will be described later.

[0018] The defect analysis support device 100 also includes functional units such as a defect occurrence path regeneration unit 110, a defect occurrence graph generation unit 111, a defect variable definition extraction unit 112, a defect-related pattern instance search unit 113, and an analysis result display unit 114.

[0019] Among these, the defect occurrence path regeneration unit 110 is a functional unit that regenerates all defect occurrence paths 130 based on the source code 125 obtained from the terminal 5. The defect occurrence paths 130 thus regenerated are temporarily stored in the memory 103.

[0020] Furthermore, the defect occurrence graph generating unit 111 is a functional unit that merges all defect occurrence paths 130 generated by the defect occurrence path regenerating unit 110 described above, and generates a defect occurrence graph 131 that integrates information on variable definitions and usage in the defect occurrence paths 130. The defect occurrence graph 131 thus generated is temporarily stored in the memory 103. Note that the defect occurrence graph generating unit 111 uses variable definitions 132 and usage information in the defect data extracted by the defect variable definition extracting unit 112 for the above-mentioned integration.

[0021] The defect-related pattern instance search unit 113 is a functional unit that searches for an instance corresponding to the defect-related pattern definition 133 in the defect occurrence graph 131. The defect relationship pattern definition 133 is a defect relationship pattern 127 obtained from the terminal 5 and stored in the memory 103, and is a definition regarding the relationship between defects.

[0022] The analysis result display unit 114 is a functional unit that outputs the results of the search performed by the defect-related pattern instance search unit 113 to the terminal 5 or a predetermined output interface.

[0023] On the other hand, the terminal 5 is a terminal used by the company personnel who use the above-mentioned defect analysis support service. Specifically, it can be a personal computer, a smartphone, a tablet terminal, or the like. <Hardware configuration> The hardware configuration of the failure analysis support device 100 of this embodiment is as shown in FIG.

[0024] That is, the failure analysis support device 100 includes a storage device 101 , a memory 103 , a calculation device 104 , and a communication device 105 .

[0025] Of these, the storage device 101 is configured with an appropriate non-volatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

[0026] The memory 103 is composed of a volatile storage element such as a RAM.

[0027] The calculation device 104 is a CPU that executes the program 102 stored in the storage device 101 by reading it into the memory 103, etc., to generally control the device itself, and also performs various judgments, calculations, and control processes. The functional units obtained by executing the program 102 are the above-mentioned defect occurrence path regeneration unit 110, defect occurrence graph generation unit 111, defect variable definition extraction unit 112, defect-related pattern instance search unit 113, and analysis result display unit 114.

[0028] The communication device 105 is assumed to be a network interface card or the like that is connected to the network 1 and handles communication processing with the terminal 5 .

[0029] When the failure analysis support device 100 is a stand-alone machine, it is preferable that it further comprises an input device for accepting key input or voice input from the user, and an output device such as a display for displaying processed data.

[0030] In addition to the program 102 for implementing the functions required for the defect analysis support device of this embodiment, the memory device 101 also stores at least a source code 125, a defect log 126, and a defect-related pattern definition 127 obtained from the terminal 5. <Flow example: Main flow> The actual procedure of the method for supporting fault analysis in this embodiment will be described below with reference to the drawings. The various operations corresponding to the method for supporting fault analysis described below are realized by a program that is read into a memory or the like and executed by the device for supporting fault analysis 100. This program is composed of codes for performing the various operations described below.

[0031] 3 is a diagram showing an example of a flow of the fault analysis support method in this embodiment. In this case, the fault analysis support device 100 regenerates all fault occurrence paths 130 based on the source code 125 (see FIG. 4) (s1).

[0032] Next, the defect analysis support device 100 merges all the defect occurrence paths 130 obtained in s1, and generates a defect analysis result in which the variable definitions 132 and information on usage in the defect occurrence paths 130 are integrated. An occurrence graph 131 is generated (s2).

[0033] Furthermore, the defect analysis support device 100 searches for an instance corresponding to the defect relationship pattern definition 133 in the defect occurrence graph 131 (s3).

[0034] Furthermore, the failure analysis support device 100 outputs the results of the search in s3 to a device such as the terminal 5 (s4), and ends the process. <Flow example: Regenerating the path where the problem occurs by executing symbols> Next, the defect occurrence path regeneration process by symbolic execution, which constitutes the defect occurrence path regeneration (s1) in the above-mentioned main flow, will be described with reference to Figures 5 to 11. Note that here, the generation (s2) of the defect occurrence graph 131 will also be described.

[0035] In this case, the fault-occurring path regeneration unit 110 uses the function call relationships in the target source code 125 to calculate a symbolic execution analysis route that passes through all target functions that are functions including the fault location (s21).

[0036] Details of this s21 are shown in the flow of Fig. 7A and an example of a symbolic execution analysis route of Fig. 7B. In the flow of Fig. 7A, the faulty path regeneration unit 110 acquires a list of target functions which are functions including fault locations (s211).

[0037] Furthermore, the failure-occurring path regeneration unit 110 analyzes the function call relationship (relationship between the caller and the callee) between the target functions (s212).

[0038] Next, the failure-occurring path regeneration unit 110 searches for the shortest route connecting the target functions that are connected by function call relationships (s213).

[0039] Furthermore, for each route obtained in s213, the failure-occurring path regeneration unit 110 assigns an execution order to each function in the route through the order of the call destination and the caller (s214), and ends the process.

[0040] Returning now to the explanation of the flow in Fig. 6, in this case, the failure-occurring path regeneration unit 110 adds, for example, the code "assert(!failure condition)" before the statement at the failure position. Then, we add code to the target function (see FIG. 9) and integrate the fault conditions into the target function that contains them (s22). The location of the added code is called the integrated fault location.

[0041] Furthermore, the faulty path regeneration unit 110 performs symbolic execution starting from the function of the symbolic execution analysis route with the smallest execution order (s23). Note that it is assumed that functions of different subroutes can be executed in parallel. Next, the faulty path regeneration unit 110 stores information such as the execution path and constraints in the storage device 101 (s24). Note that an example of the execution path obtained by such symbolic execution is shown in FIG. 10.

[0042] Furthermore, the faulty path regeneration unit 110 determines whether all the functions in the symbolic execution analysis route have been executed (s25).

[0043] If it is determined that not all functions have been executed (s25: No), the failure-occurring path regeneration unit 110 continues symbolic execution of subsequent functions in the execution order (s26).

[0044] On the other hand, if the result of the above-mentioned judgment is that all functions are being executed (s25: Yes), the defect-occurrence path regeneration unit 110 acquires the defect-occurrence path 130, which is an execution path that ends at the integrated defect position (see FIG. 11) (s27), and terminates the processing. <Flow example: Regenerating a path where a problem occurs by analyzing logs> Next, the process of regenerating a faulty path by log analysis, which constitutes the regeneration of a faulty path (s1) in the above-mentioned main flow, will be described with reference to Fig. 12 to Fig. 15. Note that the generation of the faulty graph 131 (s2) will also be described here.

[0045] In this case, the fault occurrence path regeneration unit 110 searches for an input value that is causing the fault in the target function from the fault log 126 (s32). It is assumed that the original source code 125 has a log function that outputs the input value of the function to a log.

[0046] Furthermore, the faulty path regeneration unit 110 instruments the target function (see FIG. 13) to record an execution trace including information on executed statements and their execution order (s32).

[0047] Next, the fault-causing path regeneration unit 110 executes the above-mentioned target function using the input value that is the fault cause found in s31 (s33).

[0048] Furthermore, the fault occurrence path regeneration unit 110 extracts the fault occurrence path (see FIG. 14) from the log of the execution trace obtained in s33 (s34), and ends the process.

[0049] After regenerating the defect occurrence paths as described above, the defect analysis support device 100 merges all the defect occurrence paths 130 obtained in s1, and generates a defect occurrence graph 131 (see FIG. 15) that integrates the variable definitions 132 and information on usage on the defect occurrence paths 130.

[0050] The basic structure of this fault occurrence graph 131 is composed of a node that sets the definition information (statement) of the fault occurrence path, information on the fault occurrence path that passes through this node (fault ID, path ID, etc.), data flow information that is information on the variable definition and usage (predicate, calculation) at each node, and edges that connect the nodes in the order described in the fault occurrence path. Note that the above-mentioned variables receive new values ​​(initialization or value change) (def = {v}) and are used to calculate the predicate (p-use = {v}). Also, a variable can be used to calculate the value of another variable. (c-use= {v}). <Flow example: Search for an instance> Next, the instance search (s3) process in the above-mentioned main flow will be described with reference to FIGS.

[0051] In this case, the defect-related pattern instance search unit 113 extracts defect data for each defect from the defect occurrence graph 131 (s50). An example of such a defect occurrence graph 131 is shown in Fig. 18. Details of s50 are shown in the flow of Fig. 17.

[0052] In this case, the defect-related pattern instance search section 113 adds a corresponding node to the integrated defect occurrence path (s501).

[0053] Moreover, the defect-related pattern instance search unit 113 acquires variable use information, c-use or p-use, of the current node (s502).

[0054] Next, the defect-related pattern instance search unit 113 determines whether the node has a plurality of pieces of variable use information and is the first node of the defect occurrence path (s503).

[0055] If the result of the above determination is that it is the first node (s503: No), the malfunction related pattern instance searching section 113 transitions the process to s506.

[0056] On the other hand, if the result of the above determination is that the node is not the first node (s503: Yes), the defect-related pattern instance search unit 113 searches for the closest variable definition X in the defect occurrence path of defect A that defines x for each unprocessed variable x in the variable usage information of the current node ( s504).

[0057] Next, the failure-related pattern instance searching unit 113 adds X and an edge labeled with x from X to the current node as a new node and a new vertex of the graph (s505).

[0058] Furthermore, the defect-related pattern instance search unit 113 determines whether there is a node in the list of nodes under consideration (s506).

[0059] If the result of the above determination is that a node is present (s506: Yes), the malfunction-related pattern instance search unit 113 selects a node from the list of nodes under consideration, sets it as the current node to be investigated (s507), and returns the process to s502.

[0060] On the other hand, if the result of the above determination is that there is no node (s506: No), the malfunction-related pattern instance searching section 113 ends the process. Returning now to the explanation of the flow in Fig. 16, the defect relation pattern instance search section 113 acquires unprocessed defect pairs (s51).

[0061] Next, the defect-related pattern instance search unit 113 checks the merged defect variable definitions of the defect pairs against the defect-related pattern definition 127 to identify the pattern (s52).

[0062] Furthermore, the defect-related pattern instance search unit 113 determines whether the pair of defects has a shared edge (s53).

[0063] As a result of the above-mentioned determination, if the pair has a shared edge (s53: Yes), the defect relationship pattern instance search unit 113 identifies the pair as a data-dependent defect relationship pattern (FIG. 19A) (s54), and transitions the process to s59. Note that, for the pair, the data correlation between the defects is calculated based on, for example, the data correlation calculation formula 201 (FIG. 20).

[0064] On the other hand, if the result of the above-mentioned determination is that there is no shared edge (s53: No), the defect-related pattern instance search unit 113 compares the defect occurrence paths of the defect of the pair (s55).

[0065] Next, the defect-related pattern instance search unit 113 determines whether or not there is a shared node in the defect occurrence path (s56).

[0066] If the result of the above determination is that the defect occurrence path has a shared node (s56: Yes), the defect relationship pattern instance search unit 113 identifies the pair as a control-dependent defect relationship pattern (FIG. 19C) (s57) and transitions the process to s59. On the other hand, if the result of the above determination is that there is no shared node in the defect occurrence path (s56: No), the defect relationship pattern instance search section 113 identifies the pair as a defect relationship pattern having an independent relationship (s58).

[0067] In addition, the defect-related pattern instance search unit 113 processes all pairs. Make a judgment (s59).

[0068] If the result of the above determination is that all pairs have not been processed (s59: No), the malfunction relationship pattern instance search unit 113 returns the process to s51. On the other hand, if the result of the above determination is that all pairs have been processed (s56: Yes), the malfunction relationship pattern instance search unit 113 ends the process.

[0069] It is preferable that the analysis result display unit 114 in the defect analysis support device 100 of this embodiment distributes the data of the defect occurrence graph 131 obtained up to this point to, for example, the terminal 5 and displays it (FIG. 21). Similarly, the source code (FIG. 22) in which all defect occurrence paths are merged as described above may be distributed to the terminal 5 and displayed.

[0070] Although the best mode for carrying out the present invention has been specifically described above, the present invention is not limited to this, and various modifications are possible without departing from the spirit and scope of the present invention.

[0071] According to this embodiment, it is possible to effectively avoid duplication of analysis and correction for multiple defects contained in one program, and to support consistent correction.

[0072] The description of this specification makes at least the following clear: That is, in the malfunction analysis support device of this embodiment, the arithmetic device may generate the malfunction occurrence graph by setting definition information of variables of a malfunction occurrence path in a node, setting a usage method of the variables set in the node as a data flow, and connecting the nodes with edges in the order described in the occurrence path.

[0073] This makes it possible to efficiently generate paths that indicate the occurrence status of a defect, and therefore to more effectively avoid duplication of analysis and correction for multiple defects in a single program, enabling support for consistent correction.

[0074] In the failure analysis support device of this embodiment, when searching for the instance, the calculation device may execute the following processes: extracting, for each failure, information from the failure occurrence graph, including the definition of the variable of the failure, graph elements used to explain the definition of the variable, and usage of all variables appearing in the failure state; identifying an unprocessed failure pair, comparing the merged definition of the variable of the failure in the failure pair and the graph elements with the failure relationship pattern, and determining whether the corresponding failure relationship pattern exists; determining whether the definition of the variable and the graph elements of the failure pair include a shared edge; if the result of the determination regarding the shared edge shows that the shared edge is not included, comparing the occurrence paths of each failure of the failure pair, determining whether the occurrence path includes a shared node, and identifying the failures as being independent of each other if the shared node is not included; calculating a data correlation between each failure of the failure pair if the result of the determination regarding the shared edge shows that the shared edge is included; and if the result of the determination regarding the shared node shows that the shared node is included, identifying a control-dependent failure relationship.

[0075] This makes it possible to efficiently identify the target of analysis and investigation based on the relationship between the factors that cause defects. As a result, it becomes possible to more effectively avoid duplication of analysis and correction for multiple defects in a single program, and to support consistent correction.

[0076] In the defect analysis support method of the present embodiment, the information processing device sets definition information of variables of a defect occurrence path to a node when generating the defect occurrence graph, The failure occurrence graph may be generated by setting a usage method of the specified variables as a data flow and connecting the nodes with edges in the order described in the occurrence path.

[0077] In the defect analysis support method of this embodiment, when searching for the instance, the information processing device may execute the following processes: extracting, for each defect, information from the defect occurrence graph, including the definition of the variable of the defect, graph elements used to explain the definition of the variable, and usage of all variables that appear in the defect state; identifying an unprocessed defect pair, comparing the merged definition of the variable of the defect in the defect pair and the graph elements with the defect relationship pattern, and determining whether the corresponding defect relationship pattern exists; determining whether the definition of the variable and the graph elements of the defect pair include a shared edge; if the result of the determination regarding the shared edge shows that the shared edge is not included, comparing the occurrence paths of each defect of the defect pair, determining whether the occurrence path includes a shared node, and if the shared node is not included, identifying the defects as being independent of each other; if the result of the determination regarding the shared edge shows that the shared edge is included, calculating a data correlation between each defect of the defect pair; and if the result of the determination regarding the shared node shows that the shared node is included, identifying a control-dependent defect relationship. [Explanation of symbols]

[0078] 1 Network (Interface) 5. Terminal 10. Defect analysis support system 100 Defect analysis support device 101 Storage device 102 Programs 103 Memory 104 Arithmetic unit 105 Communication equipment 110 Regeneration of defective path 111 Fault occurrence graph generation unit 112 Fault variable definition extraction section 113 Defect-related pattern instance search unit 114 Analysis result display section 125 Source Code 126 Bug Log 127 Defect-related pattern definition 130 Malfunctioning path 131 Malfunction occurrence graph 132 Defect variable definition 133 Defect-related pattern definition 134 Defect-related pattern instances

Claims

1. A storage device that stores source code of the software to be processed; a processing unit for executing a processing for calculating a symbolic execution analysis route that passes through all target functions that are functions including a fault location based on function call relationships in the source code, integrating a fault condition into the target function in the symbolic execution analysis route, and then performing symbolic execution from the function in the symbolic execution analysis route that has the smallest execution order, thereby acquiring information including an execution path and a constraint, for all functions in the symbolic execution analysis route, and acquiring a fault occurrence path that is an execution path that ends at the fault location after the integration, thereby regenerating all fault occurrence paths; a processing for generating a fault occurrence graph by setting definition information of variables in the fault occurrence path to nodes, setting a usage method of the variables set in the nodes as a data flow, and connecting the nodes with edges in the order described in the fault occurrence path; a processing unit for searching for an instance corresponding to a fault relationship pattern that specifies mutual dependency by the presence or absence of a shared node or a shared edge as a relationship between faults in the fault occurrence graph, and a processing for outputting a result of the searching to a predetermined device; A defect analysis support device comprising:

2. The computing device includes: When searching for said instances, extracting, for each of the faults, from the fault occurrence graph, the following information: definitions of the variables of the fault, the graph elements used to explain the definitions of the variables, and the usage of all variables appearing in the fault condition; A process of identifying an unprocessed failure pair, comparing the definition of the variables of the failures in the failure pair and a merge of the graph elements with the failure relationship pattern, and determining whether the failure relationship pattern corresponds to the failure pair; determining whether the variable definitions and the graph elements of the fault pair contain a shared edge; a process of comparing occurrence paths of the respective defects of the defect pair to determine whether the occurrence paths include a shared node when the result of the determination regarding the shared edge indicates that the respective defects do not include the shared edge, and if the occurrence paths do not include the shared node, identifying the defects as being independent of each other; determining a data correlation between each failure of the failure pair if the determination of the shared edge indicates that the failure pair includes the shared edge; a process of identifying a control-dependent malfunction relationship when the shared node is included as a result of the determination regarding the shared node; The present invention is directed to 2. The defect analysis support device according to claim 1.

3. An information processing device, storing the source code of the software to be processed in a storage device; a process of calculating a symbolic execution analysis route that passes through all target functions that are functions including a fault location based on function call relationships in the source code, integrating a fault condition into the target function in the symbolic execution analysis route, and then performing symbolic execution from the function in the symbolic execution analysis route that has the smallest execution order, thereby acquiring information including an execution path and a constraint, for all functions in the symbolic execution analysis route, and regenerating all fault occurrence paths by acquiring a fault occurrence path that is an execution path that ends at the fault location after the integration; a process of generating a fault occurrence graph by setting definition information of variables in the fault occurrence path to nodes, setting a usage method of the variables set in the nodes as a data flow, and connecting the nodes with edges in the order described in the fault occurrence path; a process of searching for an instance corresponding to a fault relationship pattern that specifies mutual dependency by the presence or absence of a shared node or a shared edge as a relationship between faults in the fault occurrence graph; and a process of outputting the search result to a predetermined device. A defect analysis support method comprising:

4. The information processing device, When searching for said instances, extracting, for each of the faults, from the fault occurrence graph, the following information: definitions of the variables of the fault, the graph elements used to explain the definitions of the variables, and the usage of all variables appearing in the fault condition; A process of identifying an unprocessed failure pair, comparing the definition of the variables of the failures in the failure pair and a merge of the graph elements with the failure relationship pattern, and determining whether the failure relationship pattern corresponds to the failure pair; determining whether the variable definitions and the graph elements of the fault pair contain a shared edge; a process of comparing occurrence paths of the respective defects of the defect pair to determine whether the occurrence paths include a shared node when the result of the determination regarding the shared edge indicates that the respective defects do not include the shared edge, and if the occurrence paths do not include the shared node, identifying the defects as being independent of each other; determining a data correlation between each failure of the failure pair if the determination of the shared edge indicates that the failure pair includes the shared edge; a process of identifying a control-dependent malfunction relationship when the shared node is included as a result of the determination regarding the shared node; 4. The method for supporting failure analysis according to claim 3, further comprising the steps of:

Images