JP7631164B2 - Fault analysis device and fault analysis method - Google Patents

Description

The present invention relates to a defect analysis device and a defect analysis method.

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.

Testing is a common method for detecting the above defects. In testing, test cases are created based on the inputs and outputs described in the specifications or expected by the developer. These test cases are then used to verify whether the target program returns the correct output for the input.

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).

If a defect is found, the developer analyzes which part of the software is performing the unexpected processing and identifies the cause. The developer then modifies the logic of the program in question so that it performs appropriate input and output.

On the other hand, large and complex programs require 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. Generating such a huge number of test cases is not realistic.

However, in a control program that calculates output from 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.

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 delayed. Also, if a non-reproducible defect is found after shipment, there are few clues as to the cause, making cause analysis very difficult.

If there is a certain probability of a defect occurring, a product recall or product modification will be necessary. Shipping delays, product recalls, and recalls damage user trust and are extremely costly, so they should be avoided as much as possible.

For example, a method has been proposed for evaluating how faults propagate in software components based on the specifications of the software components (see Patent Document 1).

This method includes a specification information acquisition step in which a computer having a formal verification function for 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 according to 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 the output that does not satisfy the output interface specification are stored in correspondence with each other.

JP 2012-128727 A

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.

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.

The present invention enables efficient bug analysis that takes into account the loop structure of the target program.

1 is a diagram illustrating an example of the overall configuration of a defect analysis device according to an embodiment of the present invention. FIG. 2 is an explanatory diagram regarding execution paths and path conditions in the present embodiment. FIG. 2 is a diagram showing an example of a screen of the defect analysis device in the present embodiment. FIG. 13 is a diagram showing an example of an execution path display screen in the present embodiment. FIG. 13 is a diagram illustrating an example of an analysis concept based on a loop structure in this embodiment. FIG. 4 is a diagram showing an example of a flow of a defect analysis method according to the present embodiment. FIG. 2 is an explanatory diagram showing a concept of failure analysis in a loop structure in this embodiment. FIG. 4 is a diagram illustrating an example of source code according to the present embodiment. FIG. 11 is a diagram showing an example of output in this embodiment.

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 the loop containing the fault occurrence point as the analysis starting point, and performs backward symbolic execution toward the analysis end point based on the function call relationships between multiple loops, and can identify the function at the faulty point and the parameters at that time using the SMT solver.

The inputs for such defect analysis devices include the program source code, program execution logs, program specifications, etc.

Of 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 occurs during execution (e.g. division by zero), the execution log ends with the call of the function where the exception occurred (recording the program stopping).

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

The defect analysis device also queries the user (developer) and sets the maximum number of loops to be analyzed as the condition for ending the analysis, with each loop in the function call relationship starting from the above-mentioned analysis start point as the population. Alternatively, the device sets the function of a specified loop based on the function call relationship starting from the above-mentioned analysis start point as the analysis end point.

The fault analysis device starts processing from the analysis start point and performs backward symbolic execution in the opposite direction to normal program execution until it reaches the number of loops that is the analysis end condition at most. During the backward symbolic execution, the fault analysis device records the execution path and path conditions.

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. Execution paths also include function calls.

A path condition is a condition on a variable that causes an exception (for example, division by zero). Variables include local variables within a function and input parameters to the function.

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 assist the user in analyzing the fault.

The defect analysis device uses a Satisfiability Modulo Theories Solver (SMT solver) to calculate the input parameter values of the function that is the analysis end point that satisfies the path conditions. By performing a test using these values as input, 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.

The control unit 110 is a CPU (Central Processing Unit) that calls and executes a program 121 stored in the memory unit 120 and implements the necessary functions (function units 111 to 114). It also has a symbolic execution engine 115 and an SMT solver 116.

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.

The program 121 is a program for causing a computer to function as the defect analysis device 100, and includes a description of the processing procedure for the defect analysis process.

Function call relationship DB122 also stores data showing the relationships between which functions call which other functions between loops, in other words, a call relationship graph (a graph of the control flow that represents the call relationships between functions).

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

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 to the defect 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) that constitutes 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.

The program execution log 220 (execution log) contains a record of function calls made during program execution. The program execution log 220 may contain the names (identification information) of the functions called, as well as 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 (values outside the range of the specification) described in the program specification 230.
<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 a fault occurs.

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

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

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 includes a call relationship 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 .

The call relationship generation unit 111 obtains 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.

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).

The analysis end point acquisition unit 113 receives from the developer the maximum number of loops to be analyzed, based on the population of each loop in the function call relationship starting from the above-mentioned analysis start point, as a condition for ending the analysis.

Alternatively, a function of a specified loop based on the function call relationship is set as the analysis end point, taking the above-mentioned analysis start point as the base 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).

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

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) that allow 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.

The symbolic execution engine 115 starts from the loop that includes the analysis start point among the loops included in the source code 210, and performs parallel symbolic execution for each range of the common variable for each loop in the series of loops in the loop group toward the analysis end point according to the caller direction in the series of loops 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.

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".

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.

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

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. Because line 3 of function foo is the only statement/line that contains 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 occurred from the execution log as the analysis starting point.

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".

The symbolic execution engine 115 starts from 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, the symbolic execution engine 115 searches until it reaches one of the entry points.

In the case of FIG. 2, the symbol execution engine 115 starts the search from line 3 of function foo30 and reaches line 1 (the first line). The execution path at this point is line 3 to line 1 of function foo30. The path condition 31 on line 1 remains "b=0".

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

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

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.

The 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 in line 1 is "a=b", which is equivalent to path condition 22 "a-b=0".

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

The execution path at this point is line 3 to line 1 of function foo30, line 3 to line 1 of function bar20, and line 3 of function baz10. In addition, the path conditions at this point are "b=0" in function foo30, "a-b=0" in function bar20, and "a=b" in function baz10.

The symbolic execution engine 115 starts the search from line 3 of function baz10 and reaches line 1. Because function baz10 is the end point of the analysis, the search ends here. The execution paths at this point are lines 3 to 1 of function foo30, lines 3 to 1 of function bar20, and lines 3 to 1 of function baz10. In addition, the path conditions at this point are "b=0" in function foo30, "a-b=0" in function bar20, and "a=b" in function baz10.

The path conditions include conditions for the input parameter values of the entry point (end point of analysis). The SMT solver 116 solves the path conditions and calculates the input parameter values 250 of the entry point function baz10 that satisfy the path conditions, for example a=0 and b=0.

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 in the program progresses and why a defect occurs. This allows the user to find the problem and correct the program.

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

In the above explanation, function foo30 and function bar20 each had one caller statement. If there are multiple callers, the search continues from each caller.

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

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

When multiple callers are searched and each of them reaches the entry point, the symbol 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 (the starting point of analysis) under different conditions.

If a conditional branch occurs during the search, the symbol 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".

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 path and path conditions.

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

When the analysis start point acquisition unit 112 sets an analysis start point, the analysis start point information display area 411 displays the name of the function containing the analysis start point, the line number of the analysis start point, the conditions under which an exception occurs, and the like. 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, the information display area 411 displays a message urging the user to select one of the multiple analysis start point candidates. The user presses the "Specify" button 421 to select one analysis start point from a screen (not shown) that displays the analysis start point candidates. The analysis start point acquisition unit 112 sets the selected analysis start point candidate as the analysis start point.

Immediately after the failure analysis device 100 is started, a message prompting the user to select an analysis end point (entry point) is displayed in the analysis end point information display area 412. The user presses the "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 an entry point, and functions that directly or indirectly call the function). The analysis end point acquisition unit 113 sets the selected analysis end point candidate as the analysis end point and displays it in the information display area 412. If multiple analysis end points are selected, multiple analysis end points are displayed in the information display area 412.

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 multiple analysis end points and path conditions are displayed in the information display area 413.

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 the functions baz10, bar20, and foo30 through which the execution path passes.

In the source code for functions baz10, bar20, and foo30, the statements that are execution paths 431, 432, and 433, respectively, 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.

In addition, the path conditions corresponding to each statement are displayed as program comments. By checking the execution path, which shows the flow of the program, and the path conditions, which are the conditions under which a defect will occur along 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.

In Figure 4, the start point, end point, and path conditions are displayed in the form of program comments, but other formats are acceptable as long as the correspondence with statements/lines can be understood.

<Example based on the concept of loop>
The above "Execution Paths and Path Conditions: Basic Concepts" does not show any concept that takes into consideration so-called loop structures, which execute the same process cyclically. However, embedded control software often has loop structures.

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 such cases, 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).

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 malfunction is likely to be near the part of the source code 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 at the loop start point where the variable specifications are satisfied. Additionally, a maximum number of loops is specified in case the analysis does not end.

<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 according to this embodiment.

In step s10, the control unit 110 reads the input source code 210 (Figure 8), program execution log 220, and program specification 230.

In step s11, the call relationship generation unit 111 extracts function call relationships from the loaded source code 210 (Figure 8) and stores them in the function call relationship DB 122.

In step S12, the analysis start point acquisition unit 112 acquires and sets the analysis start point from the program execution log 220.

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 problem occurred in the execution log 220, the value of the common variable S was "-100". In other words, in the source code sample in Figure 8, the function "y = s / (s + 100)" is where the division by zero error occurred, and the loop containing this code becomes the starting point of the analysis.

If there are multiple candidates for the analysis start point, the user is queried to obtain them (see the "Specify" button 421 in FIG. 3). In step s12, the analysis end point acquisition 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.

In step s13, the symbolic execution engine 115 starts a search (backward symbolic execution) for each of the series of loops according to the function call relationships, starting from the loop at the analysis start point. The flow of this backward symbolic execution is almost the same as that shown in Figures 2 to 4, except that the target is the source code in 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 each time the source code shown in Figure 8 is repeatedly executed, that is, each time a loop is executed.

In step s14, the symbolic execution engine 115 determines whether the analysis end condition is 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), in step s15, the symbolic execution engine 115 determines whether the value of the common variable S in the loop conforms to a specified value range.

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

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 path conditions, and returns the process to s13.

As described above, in each loop, the determination of the value of the common variable and the recording of the execution path and path conditions are repeated until it is determined in step S14 that the analysis end condition has been reached.

In step S17, the symbolic execution engine 115 displays, as a result of the search (reverse symbolic execution), for example, the 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 Figure 9).

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 a specified specification of a variable at the start point of each loop during symbolic execution and defect detection, the analysis of 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 are possible without departing from the spirit and scope of the present invention.

This embodiment enables efficient bug analysis that takes into account the loop structure of the target program.

The description in this specification makes clear at least the following. That is, in the defect analysis device of this embodiment, the control unit may be configured to end the analysis of a loop when it detects that a predetermined specification of the variable is satisfied at the start point of the loop during the symbolic execution and defect detection for each loop from the start point to the caller direction toward the end point of the analysis.

This allows processing to be avoided/terminated for loops where no bugs occur, leading to greater efficiency overall. Ultimately, this enables more efficient bug analysis that takes into account the loop structure of the target program.

In addition, in the defect analysis device of this embodiment, the storage unit may hold information on the maximum number of loops to be processed as information on the end of the analysis, and the control unit may end the processing when the loop for which the analysis has ended reaches the maximum number of loops when executing the symbols and detecting the defects for each loop toward the end point of the analysis according to the direction from the starting point to the caller.

This effectively avoids situations where the analysis itself is left incomplete. Ultimately, it enables more efficient bug analysis that takes into account the loop structure of the target program.

Furthermore, in the defect analysis device of this embodiment, the control unit may calculate a path condition, which is the condition for a defect 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 location and condition of the defect, use a specified solver to output the condition of 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.

This allows for efficient identification of defect locations and conditions. Ultimately, this enables more efficient defect analysis that takes into account the loop structure of the target program.

In addition, in the defect analysis method of this embodiment, the information processing device may terminate the analysis of a loop when it detects that a predetermined specification of the variable is satisfied at the start point of the loop during the symbolic execution and defect detection for each loop from the start point to the caller direction toward the end point of the analysis.

In addition, in the defect 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 defect for each loop from the starting point toward the caller, end the processing when the loop for which the analysis has ended reaches the maximum number of loops.

In addition, 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 under which a defect occurs, and when detecting and outputting the defect location and condition, may use a specified solver to output the condition of 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.

100: Fault analysis device 110: Control unit 111: Call relationship generation unit 112: Analysis start point acquisition unit 113: Analysis end point acquisition unit 114: Loop start point acquisition unit 115: Symbolic execution engine 116: SMT solver (solver)
120 Storage unit 121 Program 122 Function call relationship DB
123 Analysis start/end point information 124 Loop start point information 180 Input/output section 210 Source code (program)
220 Program execution log (execution log)
230 Program specification 240 Execution path 250 Input parameter value

Claims (8)

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: 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, 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. 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, 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 of the loops in the series of loops in the function call relationship toward the end point of the analysis for each of the loops in the series of loops, for each range of variables defined in the source code, and outputting the location and condition where a defect is detected;
A defect analysis method comprising: 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. 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. 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