WO2022196219A1 - プログラム分析装置、プログラム分析方法およびトレース処理追加装置 - Google Patents
プログラム分析装置、プログラム分析方法およびトレース処理追加装置 Download PDFInfo
- Publication number
- WO2022196219A1 WO2022196219A1 PCT/JP2022/005804 JP2022005804W WO2022196219A1 WO 2022196219 A1 WO2022196219 A1 WO 2022196219A1 JP 2022005804 W JP2022005804 W JP 2022005804W WO 2022196219 A1 WO2022196219 A1 WO 2022196219A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- execution
- function
- program
- trace
- execution path
- Prior art date
Links
- 238000000034 method Methods 0.000 title description 12
- 230000008569 process Effects 0.000 title description 5
- 230000009467 reduction Effects 0.000 claims abstract description 15
- 230000006870 function Effects 0.000 claims description 142
- 238000012545 processing Methods 0.000 claims description 93
- 238000001514 detection method Methods 0.000 claims description 17
- 238000004458 analytical method Methods 0.000 abstract description 59
- 230000007547 defect Effects 0.000 description 48
- 238000003780 insertion Methods 0.000 description 23
- 230000037431 insertion Effects 0.000 description 23
- 238000012360 testing method Methods 0.000 description 14
- 238000010586 diagram Methods 0.000 description 10
- 238000012986 modification Methods 0.000 description 8
- 230000004048 modification Effects 0.000 description 8
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000005856 abnormality Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 238000011144 upstream manufacturing Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000007257 malfunction Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/443—Optimisation
- G06F8/4434—Reducing the memory space required by the program code
- G06F8/4435—Detection or removal of dead or redundant code
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/445—Exploiting fine grain parallelism, i.e. parallelism at instruction level
- G06F8/4451—Avoiding pipeline stalls
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
Definitions
- the present invention relates to a program analysis device, program analysis method, and trace processing addition device that support software program analysis.
- test As a general technique for detecting defects. In testing, the developer defines the expected inputs and outputs and checks if the software behaves as expected, and if it doesn't, it's a defect. When a problem occurs, the developer analyzes which part of the software performed the unexpected processing, identifies the cause, and then corrects the software logic so that the appropriate processing is performed.
- Patent Document 1 in a software component whose input specifications and output specifications are defined, fault propagation when a software component fails is determined by determining which output fails to satisfy the specifications for an input that violates the specifications. The evaluation method is described.
- Patent Literature 1 can evaluate the behavior of a software component when given an abnormal input, but cannot analyze the cause of a defect that causes an abnormal output in response to a normal input.
- analysis using symbolic execution can be performed.
- Symbolic execution is a technique for comprehensively extracting the order of processes (execution paths) that target software can execute, and determining inputs for executing each path. By using symbolic execution, it is possible to generate data to be input during testing and to derive input data when a problem occurs, so that testing can be performed efficiently.
- symbolic execution exhaustively evaluates execution paths, requiring computational resources and computational time.
- the number of execution paths becomes enormous, and the calculation processing time becomes long, and failure analysis may not be completed within the planned development period.
- the program analysis apparatus provides all execution paths, which are all possible execution paths for execution paths, which are sequences of statements executed in order in a program. , an execution path reduction unit that removes an execution path that is not executed by referring to information related to the branch destination of the conditional branch included in the program.
- the trace processing addition device prioritizes a conditional branch that satisfies a predetermined condition included in a program, and writes the values of the variables included in the statement of the conditional branch to the execution log immediately before the statement of the conditional branch.
- condition that it is in a function a condition that it is included in a plurality of said execution paths among execution paths that are sequences of statements executed in order in said program, a condition that it is in a function in which a problem occurred in the past, and It is characterized by any of the conditions that the test is included in an unexecuted execution path.
- FIG. 1 is an overall configuration diagram of a failure analysis support system according to this embodiment;
- FIG. It is a source code before trace processing insertion according to the present embodiment. It is the source code after trace processing insertion according to the present embodiment.
- 4 is a directed graph for explaining an execution path according to the embodiment; 3 is a functional block diagram of a trace processing addition device according to the embodiment;
- FIG. 6 is a flowchart of trace processing addition processing according to the present embodiment;
- 1 is a functional block diagram of a failure analysis device according to this embodiment;
- FIG. FIG. 5 is a diagram for explaining defect analysis processing according to the embodiment; 4 is a flowchart of failure analysis processing according to the embodiment;
- It is a screen configuration diagram of a failure analysis result screen according to the present embodiment.
- It is a data configuration of a defect history database according to a modification of the present embodiment.
- It is a data configuration of a test history database according to a modification of the present embodiment.
- the fault analysis system identifies (the range of) fault locations in a program (source code, software) using a symbolic execution technique.
- Symbolic execution is a technique for simulating program execution while setting constraints on variables and updating the constraints instead of executing the program by substituting specific values for variables (advancing program processing). be.
- argument values problem occurrence conditions
- return values which can be used for fault analysis (identification of fault locations).
- An execution path can also be thought of as the sequence of operations that a program may perform. If symbolic execution is used for all execution paths that may be executed, the amount of calculation becomes enormous, which is not realistic as a failure analysis method.
- the failure analysis support system acquires the values of variables referenced in conditional branches from the execution log, identifies which branch is to be executed, and reduces the execution paths subject to symbolic execution. By using the execution log when a failure occurs, symbolic execution can be used for the execution path where the failure occurs, and the time required for failure analysis can be shortened.
- FIG. 1 is an overall configuration diagram of a failure analysis support system 10 according to this embodiment.
- the configuration of the failure analysis support system 10 and the flow of failure analysis will be described with reference to FIG.
- the failure analysis support system 10 includes a trace processing addition device 200 and a failure analysis device 100 (program analysis device).
- the trace processing addition device 200 receives the source code 410, the execution path information 420, and the trace specification 430, and outputs the source code 440 with trace processing.
- the trace processing addition device 200 embeds in the source code 410 trace processing (Trace statement) for outputting the value of the variable at the time of execution to the execution log 460 . Details of the trace processing addition device 200 will be described later.
- the execution form generation device 300 compiles the source code 440 with trace processing, links it with a necessary library program, and outputs the execution form code 450 with trace processing (executable program).
- the executable code 450 with trace processing is installed (embedded) in the actual device 350 (for example, vehicle-mounted device) in which the executable code is actually executed and an abnormality occurs.
- the source code with trace processing 440 and the executable code with trace processing 450 are also simply referred to as programs unless there is a particular risk of confusion.
- the program "execute the program” is the executable code 450 with trace processing, and the program “steps included in the program” is the source code 440 with trace processing.
- the real machine 350 runs by executing the installed program (executable code 450 with trace processing), and the execution log 460 is generated.
- the execution log 460 values of variables during execution are recorded by trace processing.
- functions that have been called and anomalies may be recorded.
- the fault analysis device 100 receives the source code 440 with trace processing, the execution path information 420, the function specification 470, and the execution log 460, and outputs a fault analysis result 480.
- the fault analysis apparatus 100 refers to the execution log 460 and removes execution paths that have not been executed from the entire execution paths of the program (source code 440 with trace processing).
- the fault analysis apparatus 100 identifies the fault occurrence location by performing symbolic execution processing on the remaining execution paths, and outputs fault occurrence conditions as a fault analysis result 480 . Details of the failure analysis device 100 will be described later.
- the trace processing addition device 200 receives the source code 410, the execution path information 420, and the trace specification 430, and outputs the source code 440 with trace processing.
- Trace processing is processing for recording the values of program variables in the execution log 460 .
- a source code 410 is a source code to be analyzed, and is an embedding target of trace processing.
- FIG. 2 is the source code 412 before trace processing insertion according to this embodiment.
- Source code 412 is part of source code 410 .
- FIG. 3 shows the source code 442 after the trace processing insertion according to this embodiment.
- the source code 442 is part of the traced source code 440 .
- Source code 442 is the result of inserting (embedding) a trace processing (Trace statement) step before the conditional branch statement (if statement) on line 2 included in source code 412 .
- trace processing Trace statement
- if statement conditional branch statement
- the execution path information 420 is information on all possible execution paths included in the source code 410 .
- FIG. 4 is a directed graph 500 for explaining execution paths according to this embodiment.
- the nodes of the directed graph 500 indicate source code steps (statements, sentences, lines), and the edges indicate the execution order of the steps.
- the program starts from the step indicated by the node 501, and the execution path is divided into two at the conditional branch step (conditional branch statement) indicated by the node 502.
- Each path of the directed graph 500 starting from the starting node 501 to the ending nodes (for example, nodes 521, 522, and 523) is an execution path.
- the directed graph 500 shows the entire execution path.
- a partial path of an execution path is also called an execution path.
- the execution path information 420 includes both a step execution path (also referred to as a step execution path) and a function execution path (also referred to as a function execution path).
- the trace specification 430 is a specification relating to insertion processing of trace processing, and includes, for example, information relating to the upper limit of trace processing (Trace statements) that can be inserted.
- the upper limit depends on the storage capacity of the real machine 350 in which the execution log 460 is stored, the number of Trace statements to be inserted, the number of variables to be traced, the type (size) of variables, and the like.
- the upper limit is determined by the number of Trace statements inserted, and the trace specification 430 includes the upper limit of Trace statements.
- FIG. 5 is a functional block diagram of the trace processing addition device 200 according to this embodiment.
- the trace processing addition device 200 is a computer and includes a control section 210 , a storage section 220 and an input/output section 280 .
- User interface devices such as a display, a keyboard, and a mouse are connected to the input/output unit 280 .
- the input/output unit 280 also has an interface function with a recording medium and a communication function with other devices.
- the storage unit 220 is composed of ROM (Read Only Memory), RAM (Random Access Memory), SSD (Solid State Drive), and the like.
- the storage unit 220 stores a program 221 and a function execution path database 230 (referred to as function execution path DB (Database) in FIG. 5).
- the program 221 includes a description of trace insertion processing (see FIG. 6 described later).
- the function execution path database 230 stores execution path information of the source code 410 .
- the control unit 210 includes a CPU (Central Processing Unit) and includes a source code input/output unit 211 , a trace location determination unit 212 and a trace processing addition unit 213 .
- the source code input/output unit 211 acquires the source code 410 (see FIG. 1), the execution path information 420, and the trace specification 430 via the input/output unit 280, stores them in the storage unit 220, and outputs the source code 440 with trace processing. output.
- the source code input/output unit 211 stores the function execution path included in the execution path information 420 in the function execution path database 230.
- FIG. 1 Central Processing Unit
- the trace location determination unit 212 determines the insertion location of the Trace statement in the source code 410 . More specifically, the trace location determining unit 212 corresponds to a node on which many execution paths pass from the starting node 501 to the ending node in the directed graph 500 (see FIG. 4) regarded as function execution paths (function calling relationships).
- the function is a candidate for inserting the Trace statement in order from the function that In other words, the trace location determining unit 212 refers to the function execution path database 230, and assumes that a node (function) having a larger number of execution paths has a higher trace statement insertion order.
- the nodes 501 and 502 pass through all the execution paths, so they have the highest order of Trace statement insertion.
- the node 511 is upstream of the node 513, and the execution path passing through the node 511 passes through the node 513, so the node 513 has a higher insertion order than the node 511.
- FIG. Assuming that the directed graph 500 is a function calling relationship, the function corresponding to the nodes 501 and 502 has the highest Trace statement insertion order. Also, the function corresponding to node 513 has a higher insertion order than the function corresponding to node 511 .
- the trace processing adding unit 213 inserts a Trace statement for outputting to the execution log 460 the value of the variable referred to in determining the conditional branch before the conditional branch statement (if statement) of the source code.
- FIG. 6 is a flowchart of trace processing addition processing according to the present embodiment.
- the source code input/output unit 211 acquires the source code 410 (see FIG. 1), the execution path information 420 and the trace specification 430 and stores them in the storage unit 220 .
- step S12 the trace location determining unit 212 determines the order of functions into which the Trace statements are inserted.
- the trace location determination unit 212 assumes that the more nodes (functions) have more execution paths (refer to the directed graph 500 regarded as the function calling relationship shown in FIG. 4), the higher the order of Trace statement insertion.
- step S13 the trace location determination unit 212 starts repeating steps S14 and S15 in descending order of the insertion order determined in step S12.
- step S14 the trace location determining unit 212 determines whether or not the upper limit will be exceeded when the Trace statement is inserted into the function. If the upper limit is exceeded (step S14 ⁇ YES), the trace location determining unit 212 ends the repetition process and proceeds to step S16, and if not (step S14 ⁇ NO), proceeds to step S15.
- the upper limit is the maximum number of Trace statements included in the trace specification 430 that can be inserted.
- step S15 the trace processing addition unit 213 inserts a Trace statement before the conditional branch statement of the function (see FIGS. 2 and 3).
- step S16 the source code input/output unit 211 outputs the source code in which the Trace statement is inserted (the source code with trace processing 440 shown in FIG. 1).
- the fault analysis apparatus 100 receives the source code 440 with trace processing, the execution path information 420, the function specification 470, and the execution log 460, and outputs a fault analysis result 480 (see FIG. 1).
- the function specification 470 is a specification of the function included in the source code 410, and includes types and ranges of arguments and return values (see function specification 479 shown in FIG. 8 to be described later).
- FIG. 7 is a functional block diagram of the defect analysis device 100 according to this embodiment.
- the failure analysis apparatus 100 is a computer and includes a control section 110 , a storage section 120 and an input/output section 180 .
- User interface devices such as a display, a keyboard, and a mouse are connected to the input/output unit 180 .
- the input/output unit 180 also has an interface function with a recording medium and a communication function with other devices.
- the storage unit 120 is composed of ROM, RAM, SSD, and the like.
- the storage unit 120 stores a program 121 , a function execution path database 130 , an execution path database 140 , a function specification database 150 and an execution log database 160 .
- the function execution path database 130 is referred to as the function execution path DB
- the execution path database 140 as the execution path DB
- the function specification database 150 as the function specification DB
- the execution log database 160 as the execution log DB.
- the program 121 includes a description of failure analysis processing (see FIG. 9 described later).
- the control unit 110 includes a CPU, and includes a function specification acquisition unit 111, an execution path reduction unit 112, a defect location detection unit 113, and a symbol execution engine 114.
- the function specification acquisition unit 111 acquires the source code 440 with trace processing, the execution path information 420 , the function specification 470 and the execution log 460 via the input/output unit 180 .
- the function specification acquisition unit 111 stores the step execution path included in the execution path information 420 in the execution path database 140, the function execution path included in the execution path information 420 in the function execution path database 130, and the function specification 470 in the function specification database.
- the execution logs 460 are stored in the execution log database 160, respectively.
- the execution path database 140 contains all possible step execution paths (all execution paths).
- the execution path reduction unit 112 reduces step execution paths.
- the execution path reduction unit 112 determines which execution path has passed. can be determined. Specifically, the execution path reducing unit 112 can identify which execution path the real machine 350 has passed through (executed) when the program is executed on the real machine 350 (see FIG. 1).
- the execution path reduction unit 112 identifies an execution path that is not passed (not executed or reached) among the execution paths divided into a plurality of conditional branches, and deletes it from the execution path database 140 . In this manner, the execution path reduction unit 112 reduces execution paths that have not been executed from all possible execution paths (all execution paths).
- the defect location detection unit 113 uses the symbolic execution engine 114 to detect a function with a defect from among the functions included in the execution paths remaining in the execution path database 140 . More specifically, the fault location detection unit 113 performs symbolic execution through the remaining execution paths, and calculates conditions (values of arguments and return values) under which faults occur.
- FIG. 8 is a diagram for explaining the defect analysis processing according to this embodiment.
- the defect location detection unit 113 detects arguments and return values that satisfy the logical product of the logical expression indicating the range of the arguments of the function shown in the function specification 470 (see FIG. 1) and the logical expression indicating the outside of the range of the return value. and are calculated as failure occurrence conditions.
- a symbolic execution technique is used for the calculation.
- the function bar will be described below as an example.
- the specifications of the function bar are as shown in the function specification 479, and the logical expression (1) indicating the range of the argument and the logical expression (2) indicating the out of range of the return value are as follows.
- Logical expression (2) is also the negation of the logical expression indicating the range of return values. "&” is a logical product (AND), and "
- the first execution path is line 2, line 3 of source code 411 , line 2, line 3, line 4 of source code 442 , line 3, line 4 of source code 411 .
- the second execution path is line 2, line 3 of source code 411, line 2, line 3, line 6 of source code 442, line 3, line 4 of source code 411.
- These two execution paths branch according to the condition (x ⁇ y) shown in the if statement on line 3 of source code 442 .
- line 3 of source code 411 is included in the execution path twice before and after calling function foo.
- the defect location detection unit 113 detects ((1) & (2) & (3))
- the defect location detection unit 113 performs symbolic execution on the execution paths remaining after the execution path reduction unit 112 has reduced them, and obtains the function in which the defect occurs and the defect occurrence condition.
- the function to be symbolically executed may start from the function that is the end point of the function execution path and move upstream in the execution path, or in the opposite direction.
- FIG. 9 is a flowchart of failure analysis processing according to this embodiment.
- the function specification acquisition unit 111 acquires the execution path information 420 (see FIG. 1), the function specification 470, the source code with trace processing 440, and the execution log 460.
- FIG. The function specification acquisition unit 111 stores the acquired function specification 470 and execution log 460 in the function specification database 150 and the execution log database 160, respectively.
- the function specification acquisition unit 111 also stores the function execution path and step execution path included in the execution path information 420 in the function execution path database 130 and the execution path database 140, respectively.
- step S ⁇ b>22 the execution path reduction unit 112 acquires trace results included in the execution log database 160 .
- step S23 the execution path reduction unit 112 starts processing to repeat step S24 for each trace result acquired in step S22.
- step S24 the execution path reduction unit 112 refers to the variable result included in the trace result, and selects a step execution path that is not passed (not executed, not reached) among a plurality of execution paths divided by conditional branching. is identified and deleted from the execution path database 140 .
- step S ⁇ b>25 the defect location detection unit 113 performs symbolic execution on the remaining execution paths after the execution path reduction unit 112 has reduced them, and calculates a function in which a defect occurs and a defect occurrence condition. The calculated failure occurrence conditions are output as failure analysis results 480 .
- FIG. 10 is a screen configuration diagram of the defect analysis result screen 710 according to this embodiment.
- a source code display area 711 for the function bar and a source code display area 712 for the function foo are arranged on the left side of the failure analysis result screen 710 .
- Arranged on the right side are a specification display area 715 for arguments of the function bar, a specification display area 717 for return values, a display area 716 for failure occurrence conditions, and a display area 718 for details of failure occurrence.
- execution paths are highlighted. Warning marks are displayed in the vicinity of the left side of the trouble occurrence condition display area 716 and the trouble occurrence content display area 718 to attract attention.
- the developer can see the details of the defect (see the defect occurrence content display area 718), the conditions under which the defect occurs (see the defect occurrence condition display area 716), and the progress of the defect occurrence (inverted (Refer to the displayed execution path) can be easily grasped. Ultimately, the developer will be able to efficiently proceed with countermeasures against defects.
- the trace processing adding device 200 adds trace processing (Trace statement) to the source code 410 .
- the defect analysis apparatus 100 refers to the trace result output by the trace process, reduces the execution paths included in the source code 410, and performs the symbolic execution process on the remaining execution paths (residual execution paths) to determine the defect occurrence condition. calculate.
- the failure analysis device 100 can reduce execution paths by referring to the trace results.
- the number of execution paths doubles with each conditional branch. Therefore, the number of execution paths is in the order of the power of the number of conditional branches included in a function (including functions directly/indirectly called by the function), and increases exponentially according to the number of conditional branches.
- the failure analysis apparatus 100 can greatly reduce execution paths by referring to the trace result and specifying which branch to follow in the conditional branch. Subsequently, the failure analysis apparatus 100 calculates a failure occurrence condition (failure condition) inconsistent with the specifications regarding the ranges of the arguments and return values of the functions included in the remaining execution paths.
- the defect analysis device 100 can efficiently calculate the defect condition, and the developer can identify and correct the defect by referring to the defect condition.
- the trace processing addition device 200 Since the trace processing addition device 200 has many execution paths and many calls, it inserts trace statements in descending order of the frequency of failure occurrence. By doing so, it becomes possible to efficiently acquire variable information when a problem occurs while suppressing the size of the execution log. As a result, the storage capacity of the actual machine 350 for the execution log can be suppressed, and the cost can be suppressed.
- the trace location determination unit 212 of the trace processing addition device 200 assigns a higher trace statement insertion order to nodes (functions) that have more execution paths (see step S12 in FIG. 6).
- the trace location determining unit 212 may increase the order of insertion of the Trace statement in a function in which more failures occur. Also, the trace location determining unit 212 may increase the insertion order of the Trace statement to the execution path that has not been tested.
- FIG. 11 shows the data configuration of the defect history database 610 according to the modified example of this embodiment.
- the defect history database 610 is stored in the storage unit 220 of the trace processing addition device 200 .
- the defect history database 610 is tabular data, and one row (record) indicates the occurrence of one defect.
- the record includes columns (attributes) of an identification number 611 (indicated by # in FIG. 11), a failure occurrence date and time 612, and an occurrence location 613.
- the identification number 611 is identification information of occurrence of a problem.
- the trouble occurrence date and time 612 is the date and time when the trouble occurred.
- An occurrence location 613 is a function with a problem.
- the trace location determining unit 212 may increase the insertion order of the Trace statement to the function in which the defect occurred.
- the trace location determination unit 212 may increase the order of insertion of the Trace statement for a function with a higher number of failure occurrences.
- FIG. 12 shows the data structure of the test history database 620 according to the modified example of this embodiment.
- the test history database 620 is stored in the storage unit 220 of the trace processing addition device 200 .
- the test history database 620 is tabular data, and one row (record) indicates one test.
- the record includes columns (attributes) of an identification number 621 (described as # in FIG. 12), a test date and time 622, and an execution path 623.
- the identification number 621 is test identification information.
- the test date and time 622 is the date and time when the test was performed.
- Execution path 623 is the tested execution path.
- the trace location determining unit 212 may increase the execution path that is not tested as to the insertion order of the Trace statement. By determining the insertion order of the Trace statements in this way, it is possible to reduce execution paths that share partial paths with execution paths that are likely to cause many problems.
- the trace location determining unit 212 selects functions as candidates for inserting a Trace statement in descending order of function execution paths, which are function calling relationships included in the execution path information 420 (step S12 in FIG. 6). reference).
- the trace location determining unit 212 may refer to the step execution paths, and may select a candidate for inserting a trace statement (before the conditional statement) in descending order of conditional branch statements that pass through the most execution paths.
- the order of insertion of Trace statements can be determined at a finer granularity than in units of functions, more useful trace results are recorded in the execution log, and the efficiency of defect analysis is improved.
- the trace processing (trace statement) in the above embodiment outputs the values of the variables included in the conditional branch statement to the execution log.
- the failure analysis device 100 refers to this value to determine which branch destination the branch has taken.
- information indicating to which branch destination the branch was taken may be output. For example, the value of the conditional expression of the conditional branch statement (true/false value of the condition) may be recorded.
- the failure analysis device 100 satisfies the logical product of the logical expression indicating the range of the argument of the function and the logical product indicating the outside of the range of the return value (argument value ) is calculated (see FIG. 8).
- the failure analysis device 100 may obtain other failure conditions that contradict (conflict with) the function specifications. For example, a condition satisfying a logical AND between a logical expression indicating the range of arguments of a function and a logical expression indicating outside the range of arguments of functions directly or indirectly called by the function in the execution path may be calculated. For example, in FIG.
- the target function for searching for failure conditions using symbolic execution is a function included in the execution path. It is also possible to search for fault conditions in order from the functions that are included in the execution path and in which many faults occur (see FIG. 11). Alternatively, the fault condition may be searched for in order from the function including the untested execution path (see FIG. 12). If the execution log 460 contains information on a function or step in which an error has occurred, the failure analysis apparatus 100 may search for failure conditions in order from the function or the function including the step. Alternatively, a failure condition may be searched for a function specified by the user (developer) of the failure analysis apparatus 100 . In this way, by prioritizing and finding failure conditions, failure conditions can be calculated more efficiently.
- the defect location detection unit 113 may search for defect conditions using the specifications of variables (variable types). For example, for addition, the defect location detection unit 113 may search for a defect condition on the condition that the addition result is within the specification range of the variable and overflow does not occur. In addition, the defect location detection unit 113 may search for a defect condition for a variable or expression that serves as an array index on the condition that the value corresponds to the length of the array.
- the execution path information 420 including all execution path information is provided as an input to the trace processing addition device 200 and the fault analysis device 100 .
- the trace processing addition device 200 and the fault analysis device 100 may analyze the source code 410 or the source code with trace processing 440 to extract the execution path and eliminate the execution path information 420 .
- the failure analysis support system 10 includes the failure analysis device 100 and the trace processing addition device 200, but the two devices may be integrated into one device. Also, some of the functional units may be integrated. For example, the trace location determination unit 212 and the trace processing addition unit 213 may be integrated to form a trace processing addition unit, or the failure location detection unit 113 and the symbol execution engine 114 may be integrated to form a failure location detection unit. may be
- Trouble analysis support system 100 Trouble analysis device (program analysis device) 111 function specification acquisition unit (execution path acquisition unit) 112 Execution path reduction unit 113 Fault location detection unit 114 Symbol execution engine 200 Trace processing addition device 211 Source code input/output unit 212 Trace location determination unit (trace processing addition unit) 213 Trace processing addition unit 410 Source code 420 Execution path information 430 Trace specification 440 Source code with trace processing 460 Execution log 470 Function specification 480 Failure analysis result (failure condition) 500 directed graph (execution path)
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Software Systems (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
Description
非再現不具合の解消のアプローチとして、記号実行を用いた分析を行うことができる。記号実行は、対象のソフトウェアが実行し得る処理の順序(実行パス)を網羅的に抽出し、それぞれのパスを実行する入力を決定する技術である。記号実行を用いることで、テスト時に入力するデータの生成や、不具合が発生する場合の入力データの導出が可能となり、テストを効率的に実施することができる。
以下に本発明を実施するための形態(実施形態)における不具合分析支援システムについて説明する。不具合分析システムは、プログラム(ソースコード、ソフトウェア)に対して記号実行の技術を用いて不具合箇所(の範囲)を特定する。記号実行とは、変数に具体的な値を代入してプログラムを実行する(プログラムの処理を進める)替わりに、変数に制約条件を設けて制約条件を更新しながらプログラムの実行をシミュレーションする技術である。後記するように、記号実行を用いることで関数の引数と戻り値の仕様に矛盾する引数の値(不具合発生条件)を算出することができ、不具合分析(不具合箇所の特定)に利用することができる。
図1は、本実施形態に係る不具合分析支援システム10の全体構成図である。図1を参照しながら不具合分析支援システム10の構成、および不具合分析の流れを説明する。
不具合分析支援システム10は、トレース処理追加装置200と不具合分析装置100(プログラム分析装置)とを含んで構成される。トレース処理追加装置200は、ソースコード410、実行パス情報420、およびトレース仕様430を入力とし、トレース処理付きソースコード440を出力する。トレース処理追加装置200は、実行時における変数の値を実行ログ460に出力するトレース処理(Trace文)をソースコード410に埋め込む。トレース処理追加装置200の詳細については後記する。
トレース処理追加装置200は、ソースコード410、実行パス情報420、およびトレース仕様430を入力とし、トレース処理付きソースコード440を出力する。トレース処理とは、実行ログ460にプログラムの変数の値を記録する処理である。ソースコード410は分析対象となるソースコードであって、トレース処理の埋め込み対象である。
図4は、本実施形態に係る実行パスを説明するための有向グラフ500である。有向グラフ500のノードはソースコードのステップ(ステートメント、文、行)を示し、エッジはステップの実行順序を示す。有向グラフ500では、ノード501が示すステップからプログラムが開始し、ノード502が示す条件分岐のステップ(条件分岐文)で実行パスが2つに分かれることを示す。始点となるノード501から始まり、終点(例えばノード521,522,523)となるノードまでのそれぞれの有向グラフ500のパスが実行パスである。有向グラフ500は実行パス全体を示していることになる。なお、実行パスの部分パスもまた実行パスと呼ぶ。
実行パス情報420は、ステップの実行パス(ステップ実行パスとも記す)および関数の実行パス(関数実行パスとも記す)の双方を含むものとする。
図5は、本実施形態に係るトレース処理追加装置200の機能ブロック図である。トレース処理追加装置200は、コンピュータであって、制御部210、記憶部220、および入出力部280を含んで構成される。入出力部280には、ディスプレイやキーボード、マウスなどのユーザインターフェイス機器が接続される。また入出力部280は、記録媒体とのインターフェイス機能や他の装置との通信機能を備える。
トレース処理追加部213は、ソースコードの条件分岐文(if文)の前に、当該条件分岐の判定に参照される変数の値を実行ログ460に出力するTrace文を挿入する。
図6は、本実施形態に係るトレース処理追加処理のフローチャートである。
ステップS11においてソースコード入出力部211は、ソースコード410(図1参照)、実行パス情報420、およびトレース仕様430を取得して記憶部220に格納する。
ステップS13においてトレース箇所決定部212は、ステップS12で決定した挿入順位の高い関数から順にステップS14~S15を繰り返す処理を開始する。
ステップS16においてソースコード入出力部211は、Trace文が挿入されたソースコード(図1記載のトレース処理付きソースコード440)を出力する。
不具合分析装置100は、トレース処理付きソースコード440、実行パス情報420、関数仕様書470、および実行ログ460を入力とし、不具合分析結果480を出力する(図1参照)。関数仕様書470は、ソースコード410に含まれる関数の仕様書であって、引数および戻り値の型や範囲を含む(後記する図8記載の関数仕様479参照)。
c<1 | 10<=c (2)
a+b >= a-b & c=a+b (4)
例えばトレース結果169は、プログラム実行時に変数xと変数yとがともに5であったことを示しており、第1の実行パスが削除され第2の実行パスが残るため、(1)&(2)&(4)から不具合発生条件を算出すればよい。
図9は、本実施形態に係る不具合分析処理のフローチャートである。
ステップS21において関数仕様取得部111は、実行パス情報420(図1参照)、関数仕様書470、トレース処理付きソースコード440、および実行ログ460を取得する。関数仕様取得部111は、取得した関数仕様書470と実行ログ460とを関数仕様データベース150と実行ログデータベース160とにそれぞれ格納する。また、関数仕様取得部111は、実行パス情報420に含まれる関数実行パスおよびステップ実行パスを関数実行パスデータベース130および実行パスデータベース140にそれぞれ格納する。
ステップS23において実行パス削減部112は、ステップS22で取得したトレース結果ごとにステップS24を繰り返す処理を開始する。
ステップS25において不具合箇所検出部113は、実行パス削減部112が削減して残った実行パスについて記号実行を行い、不具合が発生する関数と不具合発生条件とを算出する。算出された不具合発生条件は、不具合分析結果480として出力される。
トレース処理追加装置200はソースコード410にトレース処理(Trace文)を追加する。不具合分析装置100は、トレース処理が出力したトレース結果を参照してソースコード410に含まれる実行パスを削減し、残った実行パス(残存実行パス)について記号実行処理を行って、不具合発生条件を算出する。
不具合分析装置100は不具合条件を効率よく算出でき、開発者は不具合条件を参照することで不具合を特定して修正することができる。
上記した実施形態においてトレース処理追加装置200のトレース箇所決定部212は、通る実行パスが多いノード(関数)ほどTrace文の挿入順位が高いとしている(図6記載のステップS12参照)。トレース箇所決定部212は、不具合発生が多い関数ほどTrace文の挿入順位を高くするようにしてもよい。また、トレース箇所決定部212は、テストを行っていない実行パスへのTrace文の挿入順位を高くするようにしてもよい。
上記の実施形態におけるトレース処理(Trace文)は、条件分岐文に含まれる変数の値を実行ログに出力している。不具合分析装置100は、この値を参照して何れの分岐先に分岐したかを判断している。トレース処理は、変数の値を出力する替わりに何れの分岐先に分岐したかを示す情報を出力するようにしてもよい。例えば、条件分岐文の条件式の値(条件の真偽値)を記録するようにしてもよい。
上記した実施形態では不具合条件(不具合発生条件)として、不具合分析装置100は関数の引数の範囲を示す論理式と、戻り値の範囲外を示す論理積との論理積を満たす条件(引数の値)を算出している(図8参照)。不具合分析装置100は関数仕様と矛盾(相反)する他の不具合条件を求めてもよい。例えば、関数の引数の範囲を示す論理式と、実行パスのなかで当該関数が直接または間接に呼び出す関数の引数の範囲外を示す論理式との論理積を満たす条件を算出してもよい。例えば図8において、関数barの引数の仕様から求まる関数fooの引数(a+b、a-b)の範囲を示す論理式と、関数fooの引数の仕様で示される論理式の否定との論理積を満たす条件を算出してもよい。
以上、本発明のいくつかの実施形態について説明したが、これらの実施形態は、例示に過ぎず、本発明の技術的範囲を限定するものではない。例えば、上記した実施形態では、トレース処理追加装置200、および不具合分析装置100の入力として、全ての実行パス情報を含む実行パス情報420がある。トレース処理追加装置200および不具合分析装置100は、ソースコード410またはトレース処理付きソースコード440を分析して実行パスを抽出して、実行パス情報420を不要としてもよい。
100 不具合分析装置(プログラム分析装置)
111 関数仕様取得部(実行パス取得部)
112 実行パス削減部
113 不具合箇所検出部
114 記号実行エンジン
200 トレース処理追加装置
211 ソースコード入出力部
212 トレース箇所決定部(トレース処理追加部)
213 トレース処理追加部
410 ソースコード
420 実行パス情報
430 トレース仕様
440 トレース処理付きソースコード
460 実行ログ
470 関数仕様書
480 不具合分析結果(不具合条件)
500 有向グラフ(実行パス)
Claims (9)
- プログラムのなかで順に実行されるステートメントの列である実行パスについて、実行される可能性のある全ての実行パスである全実行パスから、前記プログラムに含まれる条件分岐の分岐先に係る情報を参照して実行されない実行パスを削除する実行パス削減部を備える
ことを特徴とするプログラム分析装置。 - 前記条件分岐の分岐先に係る情報は、前記プログラムの実行時に生成される実行ログに含まれる当該条件分岐で参照される変数の値、および当該条件分岐に含まれる条件式の値の何れかである
ことを特徴とする請求項1に記載のプログラム分析装置。 - 前記プログラムに含まれる関数の引数および戻り値の範囲の仕様を取得する関数仕様取得部と、
前記実行パス削減部が削除した後の残存実行パスに含まれる関数のなかで、前記仕様と矛盾する前記引数の値である不具合条件を算出する不具合箇所検出部とをさらに備える
ことを特徴とする請求項1に記載のプログラム分析装置。 - 前記不具合条件は、
前記残存実行パスに含まれる関数のなかで、前記引数の範囲を示す論理式と、前記戻り値の範囲を示す論理式の否定となる論理式との論理積を満足する前記引数および前記戻り値の値である不具合条件、および
前記残存実行パスに含まれる関数のなかで、前記引数の範囲を示す論理式と、前記残存実行パスのなかで当該関数が直接または間接に呼び出す被呼び出し関数の引数の範囲を示す論理式の否定となる論理式との論理積を満足する当該関数の引数の値である不具合条件、の何れかである
ことを特徴とする請求項3に記載のプログラム分析装置。 - 前記不具合箇所検出部は、前記プログラムの実行時にエラーが発生したステートメントを含む前記残存実行パスを特定して、前記不具合条件を算出する
ことを特徴とする請求項3に記載のプログラム分析装置。 - 前記不具合箇所検出部は、不具合条件を算出する関数として過去に不具合が発生した関数を優先して不具合条件を算出する
ことを特徴とする請求項3に記載のプログラム分析装置。 - 前記不具合箇所検出部は、不具合条件を算出する関数としてテストが未実施である実行パスを含む関数を優先して不具合条件を算出する
ことを特徴とする請求項3に記載のプログラム分析装置。 - プログラム分析装置のプログラム分析方法であって、
前記プログラム分析装置は、
プログラムのなかで順に実行されるステートメントの列である実行パスについて、実行される可能性のある全ての実行パスである全実行パスから、前記プログラムに含まれる条件分岐の分岐先に係る情報を参照して実行されない実行パスを削除するステップを実行する
ことを特徴とするプログラム分析方法。 - プログラムに含まれる所定の条件を満たす条件分岐を優先して当該条件分岐のステートメントの直前に、当該条件分岐のステートメントに含まれる変数の値を実行ログに出力するトレース処理を挿入するトレース処理追加部を備え、
前記所定の条件は、
前記プログラムのなかで順に実行される関数の列である関数実行パスのなかで、複数の前記関数実行パスに含まれる関数にあるという条件、
前記プログラムのなかで順に実行されるステートメントの列である実行パスのなかで、複数の前記実行パスに含まれるという条件、
過去に不具合が発生した関数にあるという条件、および
テストが未実施である実行パスに含まれるという条件の何れかである
ことを特徴とするトレース処理追加装置。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP22770978.9A EP4310682A1 (en) | 2021-03-18 | 2022-02-15 | Program analysis device, program analysis method, and tracing process addition device |
US18/547,873 US20240143300A1 (en) | 2021-03-18 | 2022-02-15 | Program analyzing apparatus, program analyzing method, and trace processing addition apparatus |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2021-044926 | 2021-03-18 | ||
JP2021044926A JP7447044B2 (ja) | 2021-03-18 | 2021-03-18 | プログラム分析装置、プログラム分析方法およびトレース処理追加装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2022196219A1 true WO2022196219A1 (ja) | 2022-09-22 |
Family
ID=83322252
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2022/005804 WO2022196219A1 (ja) | 2021-03-18 | 2022-02-15 | プログラム分析装置、プログラム分析方法およびトレース処理追加装置 |
Country Status (4)
Country | Link |
---|---|
US (1) | US20240143300A1 (ja) |
EP (1) | EP4310682A1 (ja) |
JP (1) | JP7447044B2 (ja) |
WO (1) | WO2022196219A1 (ja) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013149164A (ja) * | 2012-01-20 | 2013-08-01 | Hitachi Automotive Systems Ltd | ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム |
US20180114026A1 (en) * | 2016-10-25 | 2018-04-26 | Nanjing University | Method and system automatic buffer overflow warning inspection and bug repair |
-
2021
- 2021-03-18 JP JP2021044926A patent/JP7447044B2/ja active Active
-
2022
- 2022-02-15 US US18/547,873 patent/US20240143300A1/en active Pending
- 2022-02-15 WO PCT/JP2022/005804 patent/WO2022196219A1/ja active Application Filing
- 2022-02-15 EP EP22770978.9A patent/EP4310682A1/en active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2013149164A (ja) * | 2012-01-20 | 2013-08-01 | Hitachi Automotive Systems Ltd | ソフトウェア検証支援装置、ソフトウェア検証支援方法、ソフトウェア検証支援プログラム |
US20180114026A1 (en) * | 2016-10-25 | 2018-04-26 | Nanjing University | Method and system automatic buffer overflow warning inspection and bug repair |
Also Published As
Publication number | Publication date |
---|---|
JP2022144078A (ja) | 2022-10-03 |
EP4310682A1 (en) | 2024-01-24 |
JP7447044B2 (ja) | 2024-03-11 |
US20240143300A1 (en) | 2024-05-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10586053B2 (en) | Method for automatically detecting security vulnerability based on hybrid fuzzing, and apparatus thereof | |
Korel et al. | Dynamic program slicing methods | |
US8645761B2 (en) | Precise fault localization | |
US20160321586A1 (en) | Selecting tests for execution on a software product | |
JP6469730B2 (ja) | ソフトウェア検査装置 | |
CN102567164A (zh) | 用于处理器的指令集批量测试装置与方法 | |
WO2019055378A1 (en) | METHOD AND APPARATUS FOR FINDING LONG PROCESSES IN A CODE | |
Ribeiro et al. | Evaluating data-flow coverage in spectrum-based fault localization | |
Najafi et al. | Bisecting commits and modeling commit risk during testing | |
US11249888B1 (en) | System and method for generating counterexample tests of incidental invariants | |
US8479169B1 (en) | Code analysis via ranged values | |
WO2019142266A1 (ja) | テストケース生成装置、テストケース生成方法およびテストケース生成プログラム | |
Manthey et al. | Spybug: Automated bug detection in the configuration space of SAT solvers | |
WO2022196219A1 (ja) | プログラム分析装置、プログラム分析方法およびトレース処理追加装置 | |
US10642716B1 (en) | Automated software program repair | |
US20200257613A1 (en) | Automated software program repair | |
JP2017041196A (ja) | スタブ化対象判定装置、方法、及びプログラム | |
JP2015197868A (ja) | コンピュータ・プログラムの検査装置 | |
Bernardi et al. | Facilitating fault-simulation comprehension through a fault-lists analysis tool | |
JP7549992B2 (ja) | 不具合解析装置、プログラムおよび不具合解析方法 | |
CN114153750B (zh) | 代码检查方法及装置、代码编写方法、电子设备 | |
Fabarisov et al. | The efficiency comparison of the prism and storm probabilistic model checkers for error propagation analysis tasks | |
CN116860628A (zh) | 静态分析器测试方法及装置 | |
Mohammadian et al. | Using program slicing technique to reduce the cost of software testing | |
WO2023058609A1 (ja) | 不具合解析装置及び不具合解析方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 22770978 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 18547873 Country of ref document: US |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2022770978 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2022770978 Country of ref document: EP Effective date: 20231018 |