Fault analysis device and fault analysis method

Abstract

To efficiently analyze a defect based on a loop structure of a target program.SOLUTION: A defect analysis device 100 comprises: a storage unit 120 which stores information about each of start and end analysis, start each loop, and function call relationships in a source code of software to be analyzed; and a control unit 110 which executes symbolic execution in parallel for each variable range defined by the source code, on each loop of a series of loop group, from a loop including the start point of the analysis toward the end point of the analysis in accordance with a call source direction in the loop group having the function call relationships, to output a portion where and conditions under which a defect was detected.SELECTED DRAWING: Figure 2

Description

[Technical field]

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

[0002] In software development, behavior of software (programs, software programs) that differs from the specifications or is not anticipated by the developer is called a defect. It is advisable to fix and eliminate all such defects before releasing the software.

[0003] A common method for detecting the above defects is testing. In testing, inputs and outputs described in the specification or expected by the developer are created as test cases. These test cases are then used to check whether the target program returns the correct output for the input.

[0004] As a result, if the output differs from the input, or an exception (fault) occurs and the program does not run, it is determined that there is a malfunction (a malfunction has occurred).

[0005] When a defect is found, the developer analyzes which part of the software performed the unexpected processing, identifies the cause, and then modifies the logic of the program so that it performs appropriate input and output.

[0006] On the other hand, a large and complex program requires many test cases. More specifically, a huge number of test cases are required to cover all statements (lines / steps), branches, branch conditions, etc. of the program. It is not realistic to generate such a huge number of test cases.

[0007] However, in a control program that calculates an output from an input, most inputs are processed correctly, but in very rare conditions, incorrect processing may occur. This type of malfunction is called a non-reproducible malfunction, and it is difficult to identify the rare conditions under which the malfunction occurs.

[0008] If a non-reproducible defect is found just before shipment, it may take a very long time to analyze the defect, which may result in the shipment being postponed. Also, if a non-reproducible defect is found after shipment, there are few clues to the cause, making cause analysis very difficult.

[0009] If there is a certain probability of a defect occurring, a product recall or product modification will be necessary. Shipping delays, product recalls, and product recalls will damage user trust and incur huge costs, so it is best to avoid them as much as possible.

[0010] In response to this, for example, a method has been proposed for evaluating how a fault propagates in a software component based on the specifications of the software component (see Patent Document 1).

[0011] This method includes 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 software component is verified by the formal verification function according to the specification information in which the input interface specification in the specification information is changed to a value other than a normal value; If an example of an unsatisfactory output value is found, a fault propagation path storage step is executed to store the input that has been changed to a value other than the normal value and the output that does not satisfy the output interface specifications in association with each other. [Prior art documents] [Patent documents]

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

[0013] The above-mentioned conventional technology certainly makes it possible to evaluate the behavior of software components when abnormal input is given. However, the evaluation is only performed at the granularity of whether or not there is a constraint violation on an input / output basis. Therefore, it is difficult to deal with cases where a malfunction occurs due to multiple loops that are related to each other, such as when an argument of one loop is the output value of another loop. Even if the conventional technology is simply applied to a structure that covers such multi-layered relationships, there is a problem that the number of states explodes and the analysis does not end. Therefore, an object of the present invention is to provide a technique that enables efficient fault analysis taking into account the loop structure of a target program. [Means for solving the problem]

[0014] The defect analysis device of the present invention, which solves the above problems, is characterized by including a memory unit that retains information on the start and end of analysis, the start of each loop, and function call relationships in the source code of the software to be analyzed, and a control unit that starts from the loop that includes the start point of the analysis, and, depending on the caller direction in a series of loops in the function call relationship, processes symbolic execution in parallel for each value range of variables specified in the source code for each loop in the series of loops in the series of loops in the series, toward the end point of the analysis, and outputs the location where a defect was detected and the condition. In addition, the defect analysis method of the present invention is characterized in that an information processing device stores in a memory unit information on the start and end of analysis, the start of each loop, and function call relationships in the source code of the software to be analyzed, and starts from one of the loops that includes the start point of the analysis as a starting point, and depending on the caller direction in a series of loops in the function call relationship, performs symbolic execution in parallel for each value range of variables specified in the source code for each loop in the series of loops in the loop group, toward the end point of the analysis, and outputs the location and condition where a defect was detected. Effect of the Invention

[0015] According to the present invention, efficient fault analysis can be performed in consideration of the loop structure of a target program. [Brief description of the drawings]

[0016] [Figure 1] 1 is a diagram illustrating an example of the overall configuration of a defect analysis device according to an embodiment of the present invention. [Diagram 2] FIG. 2 is an explanatory diagram regarding execution paths and path conditions in the present embodiment. [Diagram 3] FIG. 2 is a diagram showing an example of a screen of the defect analysis device in the present embodiment. [Figure 4] FIG. 13 is a diagram showing an example of an execution path display screen in the present embodiment. [Diagram 5] FIG. 13 is a diagram illustrating an example of an analysis concept based on a loop structure in this embodiment. [Figure 6] FIG. 4 is a diagram showing an example of a flow of a defect analysis method according to the present embodiment. [Figure 7] FIG. 2 is an explanatory diagram showing a concept of failure analysis in a loop structure in this embodiment. [Figure 8] FIG. 4 is a diagram illustrating an example of source code according to the present embodiment. [Figure 9] FIG. 11 is a diagram showing an example of output in this embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] The defect analysis device according to the present embodiment is an information processing device that enables efficient defect analysis in consideration of the loop structure of a target program. Furthermore, the fault analysis device of this embodiment is particularly equipped with a symbolic execution engine and an SMT solver, and sets a loop including the location where the fault occurs as the analysis starting point, and performs backward symbolic execution toward the analysis end point based on the function call relationships between multiple loops, thereby identifying the function at the faulty location and the parameters at that time using the SMT solver.

[0018] The inputs to such a defect analysis device include the source code of the program, the program's execution log, the program specifications, and so on.

[0019] Among these, the source code is that of the program that is the subject of bug analysis. The execution log also contains the functions (methods) that were called during the execution of the program. If an exception (e.g. division by zero) occurs during execution, the execution log ends with the call of the function where the exception occurred (recording the program stopping).

[0020] The fault analysis device presents to the user from the execution log the program statement (line / step of source code) in the function where the exception occurred (e.g., a division operation by zero) and accepts the user's specification of the starting point for analysis.

[0021] The defect analysis device also queries the user (developer) and sets the maximum number of loops to be analyzed as a population of each loop in the function call relationship starting from the above-mentioned analysis start point as the analysis end point, or sets a function of a predetermined loop based on the function call relationship starting from the above-mentioned analysis start point as the analysis end point.

[0022] The fault analysis device executes backward symbolic execution in the opposite direction to normal program execution, starting from the analysis start point and ending at the maximum loop count of the analysis end condition. During the backward symbolic execution, the fault analysis device records the execution path and the path condition.

[0023] An execution path is a path (a sequence of statements / lines / steps) in a program that connects the end point of analysis to the start point of analysis, and processing proceeds along the execution path. The execution path includes function calls.

[0024] A path condition is a condition on a variable that causes an exception (such as division by zero). The variables include local variables within a function and input parameters of the function.

[0025] By referring to the execution path and path conditions, the user can understand how the exception (fault) occurs and can use this information to consider how to fix the fault. As a result, the fault analysis device can support the user in analyzing faults.

[0026] The failure analysis device uses the SMT solver (Satisfiability Modulo Theories Solver). The input parameter values ​​of the function that are the analysis end points that satisfy the path conditions are calculated using the input values. By performing tests using these values ​​as inputs, the user can check whether the modified program works correctly. <Configuration of defect analysis device> 1 is a diagram showing the input, output, and overall configuration of a failure analysis device 100 according to this embodiment. The failure analysis device 100 includes a control unit 110, a storage unit 120, and an input / output unit 180.

[0027] Of these, the control unit 110 is a CPU (Central Processing Unit) that calls and executes a program 121 held in the storage unit 120 and implements necessary functions (functional units 111 to 114). It also has a symbolic execution engine 115 and an SMT solver .

[0028] The storage unit 120 is composed of a RAM (Random Access Memory), a ROM (Read Only Memory), an SSD (Solid State Drive), etc. A function call relationship DB 122, analysis start / end point information 123, loop start point information 124, etc. are stored.

[0029] The program 121 is a program for causing a computer to function as the failure analysis device 100, and includes a description of the processing procedure for failure analysis processing.

[0030] The function call relationship DB 122 also stores data indicating the relationship between loops as to which function calls which other function, in other words, a call relationship graph (a graph of a control flow expressing the call relationship between functions).

[0031] The input / output unit 180 is a user interface such as a display, a keyboard, a mouse, etc. The input / output unit 180 may further include a communication interface and a device for reading and writing data from and to a recording medium.

[0032] Before describing the control unit 110, the inputs and outputs of the failure analysis device 100 will be described. <Failure analysis device input> The inputs of the fault analysis device 100 include source code 210, a program execution log 220, and a program specification 230. The source code 210 is the source code of a function (method) constituting the software program to be analyzed. The program specification 230 describes the name of the function, and the names, types, and ranges of the input parameter values ​​and return values ​​of the function.

[0033] The program execution log 220 (execution log) contains a record of function calls made during program execution. In addition to the names (identification information) of the functions called, the program execution log 220 may also contain input parameter values ​​at the time of the call and return values ​​upon return from the call. The program execution log 220 may also contain exceptions that occurred during program execution. Exceptions include division by zero and violations of input parameter values ​​or return values ​​described in the program specification 230 (values ​​outside the range of the specification). <Output from defect analysis device> The output of the fault analysis apparatus 100 includes an execution path 240 and input parameter values ​​250. The execution path 240 is the path through the program (a series of statements / lines / steps that are processed sequentially in the source code 210) where the fault occurs.

[0034] One end of the execution path 240 is a statement / line / step where an exception (fault) related to the defect occurs, and is referred to as an analysis start point or simply a start point. The analysis start point is, for example, a statement including a division operation in which division by zero occurs.

[0035] The other end of the execution path 240 is a loop function that directly or indirectly calls the function containing the analysis start point, and is referred to as the analysis end point, or entry point.

[0036] An input parameter value 250 is an input parameter value of the entry point function when a malfunction occurs. <Configuration of the control unit of the defect analysis device> The control unit 110 includes a CPU (Central Processing Unit) and controls the call relationship. The system includes a generation unit 111, an analysis start point acquisition unit 112, an analysis end point acquisition unit 113, a loop start point acquisition unit 114, a symbolic execution engine 115, and an SMT solver .

[0037] The call relationship generation unit 111 acquires the function call relationships between each of the multiple loops from the source code 210 and stores them in the function call relationship DB 122 .

[0038] The analysis start point acquisition unit 112 may accept a specification of an analysis start point from the developer based on the location of the defect indicated in the execution log 220, or may analyze the program execution log 220 to acquire the analysis start point (the procedure for acquiring the analysis start point in this case will be described in detail later).

[0039] The analysis end point acquisition unit 113 receives from the developer, as a condition for ending the analysis, the maximum number of loops to be analyzed, with a population of each of a series of loops linked in function call relationships starting from the above-mentioned analysis start point.

[0040] Alternatively, a function of a predetermined loop based on the function call relationship is set as the analysis end point, starting from the above-mentioned analysis start point. In this case, functions that call the function including the analysis start point are obtained from the function call relationship DB 122, and displayed as entry point candidates on a display provided in the input / output unit 180. The user (developer) selects one or more entry points from the candidates. The analysis end point acquisition unit 113 sets the selected function as the analysis end point (entry point).

[0041] The loop start point acquisition unit 114 searches for and identifies the start point of each loop included in the source code 210, for example, by receiving a designation from a developer or by using a predetermined code as a key.

[0042] The symbolic execution engine 115 generates an execution path 240 and path conditions. The path conditions are conditions for variables (local variables and input parameters) for the execution of the program to be analyzed to pass through the execution path 240. Details of the execution path 240 and the path conditions will be described later.

[0043] The symbolic execution engine 115 starts from the loop including the analysis start point among the loops included in the source code 210, and parallelly processes symbolic execution for each range of a common variable for each loop of the loop group toward the analysis end point according to the caller direction in the series of loop group based on the call relationship indicated by the function call relationship DB 122. As a result, the above-mentioned execution path 240 and path condition are generated.

[0044] The symbolic execution engine is described in detail in the following paper: Peter Dinges and Gul Agha, "Targeted Test Input GenerationUsing Symbolic Concrete Backward Execution".

[0045] The SMT solver 116 (solver) generates input parameter values ​​250 that satisfy the path conditions generated by the above-mentioned symbolic execution engine 115. The SMT solver is described in the following literature: Leonardo deMoura and Nikolaj Bjorner, "Z3: An Efficient SMT Solver". <<Execution paths and path conditions: Basic concepts>> Fig. 2 is a diagram for explaining execution paths and path conditions according to this embodiment. Fig. 2 includes source code 210 for three functions: function baz10, function bar20, and function foo30. Function baz10 calls function bar20, which calls function foo30. The explanation will continue on the assumption that a divide-by-zero exception occurs in function foo30, and function baz10 is specified as the entry point.

[0046] In this case, the program execution log 220 includes a record of the call to the function baz10, a record of the call to the function bar20, and a record of the call to the function foo30, and ends with a record of the occurrence of division by zero.

[0047] By analyzing the program execution log 220, the analysis starting point acquisition unit 112 detects that a division by zero exception has occurred in function foo30. Since line 3 of function foo is the only statement / line that includes a division operation, the analysis starting point acquisition unit 112 sets the start point to line 3 of function foo30. In other words, the analysis starting point acquisition unit 112 acquires the statement of the program where the exception has occurred from the execution log as the analysis starting point.

[0048] A path condition is a condition / constraint under which an exception occurs. The path condition 32 on line 3 of function foo30, which is the starting point of the analysis, is "b=0".

[0049] Symbolic execution engine 115 starts at a starting point and searches through the program (source code 210) in the opposite direction to normal (forward) execution (also referred to as reverse symbolic execution) until it reaches an entry point. If there are multiple entry points, symbolic execution engine 115 searches until it reaches one of the entry points.

[0050] 2, the symbolic execution engine 115 starts searching from line 3 of function foo30 and reaches line 1 (the first line). The execution path at this point is from line 3 to line 1 of function foo30. The path condition 31 on line 1 remains "b=0".

[0051] Symbolic execution engine 115 determines that function foo30 has been called with the second input parameter b set to 0, and searches for a statement that calls function foo30. In the case of FIG. 2, the statement that calls function foo30 is line 3 of function bar20, and symbolic execution engine 115 continues searching from that line.

[0052] The path condition 22 on this line is "ab=0" which means that the second input parameter is 0. The execution path at this point is line 3 to line 1 of function foo30, and line 3 of function bar20. Also, the path conditions at this point are "b=0" in function foo30, and "ab=0" in function bar20.

[0053] Note that functions baz10, bar20, and foo30 each have variables with the same names, a, b, and c, but these are local variables of each function and are different variables.

[0054] Symbolic execution engine 115 starts searching from line 3 of function bar20 and reaches line 1. The execution path at this point is line 3 to line 1 of function foo30 and line 3 to line 1 of function bar20. Path condition 21 on line 1 is "a=b", which is equivalent to path condition 22 "ab=0".

[0055] Symbolic execution engine 115 determines that function bar20 has been called with the same value for the first and second input parameters, and searches for a statement that calls function bar20. In the case of Fig. 2, the statement that calls function bar20 is line 3 of function baz10, and symbolic execution engine 115 continues searching from that line. Path condition 12 in this line is "a=b".

[0056] At this point, the execution path is from line 3 to line 1 of function foo30, line 3 to line 1 of function bar20, and line 3 of function baz10. Also, the path condition at this point is "b=0" in function bar20, "ab=0" in function baz10, and "a=b" in function baz10.

[0057] Symbolic execution engine 115 starts the search from line 3 of function baz10 and reaches line 1. Since function baz10 is the analysis end point, the search ends here. The execution paths at this point are line 3 to line 1 of function foo30, line 3 to line 1 of function bar20, and line 3 to line 1 of function baz10. Also, the path conditions at this point are "b=0" in function foo30, "ab=0" in function bar20, and "a=b" in function baz10.

[0058] The path condition includes a condition for the input parameter value of the entry point (analysis end point). The SMT solver 116 solves the path condition and calculates the input parameter value 250 of the function baz10, which is the entry point, that satisfies the path condition, for example, a=0 and b=0.

[0059] Finally, the symbol execution engine 115 displays the execution path on a display provided in the input / output unit 180 (outputs the execution path). The user can understand how and under what conditions the processing progresses in the program and why a problem occurs. This allows the user to find the problem and correct the program.

[0060] The SMT solver 116 provides input parameter values ​​250 (input values ​​of entry points (analysis end points) that satisfy path conditions), and the user can use these values ​​to test the modified program.

[0061] In the above explanation, there is one caller statement for each of the functions foo30 and bar20. If there are multiple callers, the search continues from each caller.

[0062] For example, assume that function bazA (not shown) calls bar(d+1, d-2) and function bar20 on line 5. Symbolic execution engine 115 searches up to line 5 of function bazA to determine the path condition.

[0063] In this case, the first and second parameters, which are path conditions of function bar20, are equal, so "d+1=d-2" becomes the path condition. However, since such a condition is never satisfied, symbolic execution engine 115 stops searching from line 5 of function bazA and continues searching for other callers.

[0064] If multiple callers are searched and each of them reaches the entry point, the symbolic execution engine 115 may record the execution path and path condition of each. In such a case, there will be multiple execution paths and path conditions. In other words, it will be found that an exception occurs at the same location (analysis start point) under different conditions.

[0065] If a conditional branch occurs during the search, the symbolic execution engine 115 adds the branch condition to the path conditions. For example, assume that line 3 of function foo30 is "if (x<=y) c=a / b;". In this case, the path conditions are "b=0" and "x<=y".

[0066] When multiple analysis end points are specified, when there are multiple callers of a function, or when there are conditional branches, the search may reach multiple analysis end points, execution paths, and path conditions. In this way, the symbol execution engine 115 calculates and identifies the execution paths and path conditions.

[0067] <User Interface> 3 is a configuration diagram of a screen 400 of the failure analysis device 100 according to this embodiment. Arranged in the center of the left and right of the screen 400, from top to bottom, are an analysis start point information display area 411, an analysis end point information display area 412, and an analysis result information display area 413.

[0068] When analysis start point acquisition unit 112 sets an analysis start point, the name of the function including the analysis start point, the line number of the analysis start point, the condition under which an exception occurs, and the like are displayed in analysis start point information display area 411. For example, if a division by zero exception occurs and there are multiple division operations, there will be multiple candidates for the analysis start point. In such a case, information display area 411 displays a message urging the user to select one of the multiple analysis start point candidates. The user presses "Specify" button 421 to select one analysis start point from a screen (not shown) that displays the analysis start point candidates. Analysis start point acquisition unit 112 sets the selected analysis start point candidate as the analysis start point.

[0069] Immediately after startup of failure analysis device 100, a message prompting the selection of an analysis end point (entry point) is displayed in analysis end point information display area 412. The user presses "Specify" button 422 to select one or more analysis end points from a screen (not shown) that displays analysis end point candidates (functions that include a start point, and functions that directly or indirectly call said functions). Analysis end point acquisition unit 113 sets the selected analysis end point candidate as the analysis end point and displays it in information display area 412. If multiple analysis end points are selected, multiple analysis end points are displayed in information display area 412.

[0070] When the "Start analysis" button 423 is pressed, the symbol execution engine 115 searches for an execution path, and the analysis end point reached and the path conditions related to the input parameters of the analysis end point are displayed in the analysis result information display area 413. If there are multiple analysis end points or path conditions related to multiple input parameters, the information display area 413 displays the multiple analysis end points and path conditions.

[0071] When the "Display execution path" button 424 is pressed, an execution path display screen 430 (see FIG. 4 described later) is displayed on the display of the input / output unit 180. Fig. 4 is a configuration diagram of the execution path display screen 430 according to this embodiment. The execution path display screen 430 displays the source code of functions baz10, bar20, and foo30 through which the execution path passes.

[0072] In the source code of functions baz10, bar20, and foo30, the statements that are execution paths 431, 432, and 433 are displayed in reverse video. In addition, the statement at the start of the analysis is marked with "start point," and the statement with the entry point function name is marked with "end point" as a program comment.

[0073] In addition, the path conditions corresponding to each statement are displayed as program comments. By checking the execution path that shows the flow of the program and the path conditions that are the conditions under which a defect occurs on that execution path, users (developers) can understand the cause of the defect, which in turn makes it easier to consider how to modify the source code.

[0074] In FIG. 4, the start point, end point, and path conditions are displayed in the form of program comments, but other formats may be used as long as the correspondence with statements / lines can be understood.

[0075] <Example based on the concept of loop> The above "Execution Path and Path Condition: Basic Concept" does not show any concept that takes into consideration so-called loop structures that execute the same process periodically. Software often has a loop structure.

[0076] In programs with such loop structures, problems often occur in loops that are several cycles away from the first loop, as shown in the example in Figure 5. In this case, there is a variable that is used in common between the loops in each cycle, that is, a common variable S, and the value of the common variable S is transmitted between the loops (via a function).

[0077] If this value is not within the range of values ​​expected for common variable S at the time the error occurs, the cause of the defect is likely to be near the source code part where the value range first deviated. Therefore, at each loop start point, symbolic execution is divided into parallel processes for multiple variable ranges (e.g., for each path branched by an if statement), and analysis is terminated when a point is detected that satisfies the variable specification at the loop start point. In addition, a maximum number of loops is specified in case the analysis does not end.

[0078] <Failure analysis processing> Fig. 6 is a flowchart of the defect analysis process according to this embodiment, and Fig. 7 is an explanatory diagram showing the concept of defect analysis in a loop structure in this embodiment.

[0079] In step s10, the control unit 110 reads the source code 210 (FIG. 8), the program execution log 220, and the program specification 230, which are input.

[0080] In step s11, the call relationship generation unit 111 extracts function call relationships from the read source code 210 (FIG. 8) and stores them in the function call relationship DB 122.

[0081] In step s12, the analysis starting point acquisition unit 112 acquires and sets an analysis starting point from the program execution log 220.

[0082] For example, according to the program specifications 230, the value range of the common variable s is either "0" or "1", but at the point where the error occurred in the execution log 220, the value of the common variable S was "-100." That is, in the source code sample in Fig. 8, the function "y=s / (s+100)" is the point where the division by zero error occurred, and the loop containing this code becomes the starting point of the analysis.

[0083] If there are multiple candidates for the analysis start point, the user is queried to obtain them (see "Specify" button 421 in FIG. 3). In step s12, the analysis end point obtaining unit 113 also queries the user to obtain and set the analysis end condition. FIG. 7 shows an example in which the user sets the maximum number of loops to be the processing upper limit to "200" and this is accepted.

[0084] In step s13, the symbolic execution engine 115 starts a search (backward symbolic execution) for each of a series of loops according to the function call relationships from the loop at the analysis start point. The flow of such backward symbolic execution itself is almost the same as that of Figures 2 to 4, except that the target is the source code of Figure 8. However, it is distinctive in that a search is performed to check whether the value of the common variable S exceeds a specified value range every time the source code shown in Figure 8 is repeatedly executed, that is, every time a loop is executed.

[0085] In step s14, the symbol execution engine 115 determines whether an analysis end condition has been reached. In other words, it determines whether the number of times the loop has been processed has exceeded the upper limit of "200". If the result of this determination is that the number of times the loop has been processed has not exceeded the upper limit of "200" (s14:N), then in step s15, the symbol execution engine 115 determines whether the value of the common variable S in the loop is equal to or greater than a specified value. Determine whether it complies with the area.

[0086] If the result of this determination is that the value of the common variable S fits the specified range (step s15: Y), the process proceeds to s13.

[0087] On the other hand, if the result of the above determination is that the value of the common variable S does not fit the specified range (step s15: N), in step s16, the symbol execution engine 115 records the execution path and the path condition, and returns the process to s13.

[0088] As described above, until it is determined in step s14 that the analysis end condition is reached, the determination of the value of the common variable and the recording of the execution path and path condition are repeated in each loop.

[0089] In step S17, the symbolic execution engine 115 displays, as a result of the search (reverse symbolic execution), for example, parameters of the calling variables: x=53, y=1.1, s=1 for the function: main, which is the source of the problem associated with the execution of multiple loops (see FIG. 9).

[0090] The symbolic execution engine 115 performs parallel symbolic execution for each range of variables defined in the source code, and outputs the location and condition where a defect is detected. In addition, when detecting symbolic execution and defects for each loop, if it is detected that the variable satisfies a predetermined specification at the start point of the loop, the analysis for the loop is terminated. 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 can be made without departing from the spirit and scope of the present invention.

[0091] According to this embodiment, it is possible to perform efficient defect analysis taking into account the loop structure of the target program.

[0092] The description of this specification makes at least the following clear: That is, in the fault analysis device of this embodiment, the control unit may be configured to terminate the analysis of a loop when detecting, in the symbolic execution and the fault detection for each loop from the starting point toward the end point of the analysis in accordance with the caller direction from the starting point, that a predetermined specification of the variable is satisfied at the start point of the loop.

[0093] This allows the process to be avoided or terminated for loops that are not bug-prone, improving efficiency overall. Ultimately, this enables more efficient bug analysis based on the loop structure of the target program.

[0094] Furthermore, in the fault analysis device of this embodiment, the memory unit may hold information on a maximum number of loops to be processed as information on the end of the analysis, and the control unit may terminate processing when the loop for which the analysis has been terminated reaches the maximum number of loops when executing the symbols and detecting the fault for each loop toward the end point of the analysis in accordance with the direction from the starting point to the caller.

[0095] This makes it possible to effectively prevent the analysis from being left incomplete, and ultimately enables more efficient fault analysis based on the loop structure of the target program.

[0096] In the fault analysis device of this embodiment, the control unit calculates a path condition, which is a condition for a fault to occur, using a symbolic execution engine that outputs an execution path by performing symbolic execution in the reverse direction from the start point to the end point of the analysis, and when detecting and outputting the fault location and condition, uses a predetermined solver to calculate the condition of an input parameter value of a function that is the end point of the analysis that satisfies the path condition, or the condition of a function that is the end point of the analysis that satisfies the path condition. The input parameter value may be a number.

[0097] This allows efficient identification of defect locations and conditions, which in turn allows for more efficient defect analysis based on the loop structure of the target program.

[0098] In addition, in the defect analysis method of this embodiment, the information processing device may terminate the analysis for a loop when it detects that a predetermined specification of the variable is satisfied at the start point of the loop when executing the symbols and detecting the defect for each loop toward the end point of the analysis in accordance with the caller direction from the starting point.

[0099] In addition, in the fault analysis method of this embodiment, the information processing device may store information on the maximum number of loops to be processed in the memory unit as information on the end of the analysis, and when performing the symbolic execution and detecting the fault for each loop from the starting point toward the caller, the processing may be terminated when the loop for which the analysis has been terminated reaches the maximum number of loops.

[0100] Furthermore, in the defect analysis method of this embodiment, the information processing device may use a symbolic execution engine that outputs an execution path by performing symbolic execution in the reverse direction from the start point to the end point of the analysis to calculate a path condition that is the condition for a defect to occur, and when detecting and outputting the defect location and condition, may use a specified solver to output the condition for the input parameter value of the function that is the end point of the analysis that satisfies the path condition, or the input parameter value of the function that is the end point of the analysis that satisfies the path condition. [Explanation of symbols]

[0101] 100 Failure analysis equipment 110 Control section 111 Call relationship generation unit 112 Analysis starting point acquisition part 113 Analysis end point acquisition part 114 Loop start point acquisition section 115 Symbolic Execution Engine 116 SMT Solver (Solver) 120 Storage section 121 Programs 122 Function call relationship DB 123 Analysis start / end point information 124 Loop start information 180 Input / output section 210 Source Code (Program) 220 Program Execution Log (Execution Log) 230 Program Specifications 240 Execution Path 250 Input Parameter Values

Claims

1. a storage unit for storing information on the start and end of analysis, the start of each loop, and function call relationships in the source code of the software to be analyzed; a control unit that performs symbolic execution in parallel for each of the loops in the series of loops in the loop group, starting from one of the loops that includes the start point of the analysis and corresponding to a caller direction in the series of loops in the function call relationship, toward the end point of the analysis, and outputs a location and a condition where a malfunction has been detected; A failure analysis device comprising:

2. The control unit is when detecting the symbolic execution and the fault detection for each of the loops from the starting point toward the caller, if it is detected that the variable satisfies a predetermined specification at the starting point of the loop, the analysis for the loop is terminated.

2. The failure analysis device according to claim 1,

3. The storage unit is As information on the end of the analysis, information on the maximum number of loops to be processed is stored; The control unit is When the symbolic execution and the detection of the fault are performed for each of the loops from the starting point toward the caller, the processing is terminated when the number of loops for which the analysis has been completed reaches the maximum number of loops.

3. The failure analysis device according to claim 2.

4. The control unit is Calculating a path condition that is a condition under which a defect occurs using a symbolic execution engine that outputs an execution path by performing symbolic execution backward from the start point to the end point of the analysis; When detecting and outputting the defective location and condition, a predetermined solver is used to output a condition of an input parameter value of a function that is an end point of the analysis that satisfies the path condition, or an input parameter value of a function that is an end point of the analysis that satisfies the path condition.

2. The failure analysis device according to claim 1,

5. An information processing device, A storage unit stores information on the start and end of analysis, the start of each loop, and function call relationships in the source code of the software to be analyzed; starting from one of the loops including the start point of the analysis as a starting point, and processing symbolic execution in parallel for each value range of variables defined in the source code for each loop of the series of loops having the function call relationship toward the end point of the analysis, in accordance with a caller direction in the series of loops having the function call relationship, and outputting the location and condition where a defect is detected; A defect analysis method comprising:

6. The information processing device, when detecting, in the symbolic execution and the detection of the fault for each of the loops from the starting point toward the caller, that a predetermined specification of the variable is satisfied at the starting point of the loop, the analysis for the loop is terminated; 6. The method for analyzing a defect according to claim 5.

7. The information processing device, The storage unit stores information on a maximum number of loops to be processed as information on the end of the analysis, when the symbolic execution and the detection of the fault are performed for each of the loops from the starting point toward the caller, the processing is terminated when the number of loops for which the analysis has been completed reaches the maximum number of loops.

7. The method for analyzing a defect according to claim 6.

8. The information processing device, Calculating a path condition that is a condition under which a defect occurs using a symbolic execution engine that outputs an execution path by performing symbolic execution backward from the start point to the end point of the analysis; When detecting and outputting the defective location and condition, a predetermined solver is used to output a condition of an input parameter value of a function that is an end point of the analysis that satisfies the path condition, or an input parameter value of a function that is an end point of the analysis that satisfies the path condition.

6. The method for analyzing a defect according to claim 5.

Images