WO2022196219A1 - プログラム分析装置、プログラム分析方法およびトレース処理追加装置 - Google Patents

プログラム分析装置、プログラム分析方法およびトレース処理追加装置 Download PDF

Info

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
Application number
PCT/JP2022/005804
Other languages
English (en)
French (fr)
Inventor
洋渡 加賀
真澄 川上
康文 鈴木
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to EP22770978.9A priority Critical patent/EP4310682A1/en
Priority to US18/547,873 priority patent/US20240143300A1/en
Publication of WO2022196219A1 publication Critical patent/WO2022196219A1/ja

Links

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

プログラム分析装置、プログラム分析方法およびトレース処理追加装置
　本発明は、ソフトウェアプログラムの分析を支援するプログラム分析装置、プログラム分析方法およびトレース処理追加装置に関する。
　ソフトウェア（プログラム）開発において、開発者が想定していないソフトウェアの動作を不具合と呼び、ソフトウェアをリリースする前に不具合を修正してなくすことが望ましい。不具合を検出する一般的な手法としてテストがある。テストでは、開発者が期待する入力と出力とを定義してソフトウェアがそのとおりに動作するかを確認し、動作しない場合を不具合とする。不具合が発生した場合、開発者はソフトウェアのどの部位で想定外の処理をしたかを分析し、原因箇所を特定したのち、適切な処理を行うようにソフトウェアのロジックを修正する。
　入力値に基づいて何らかの計算を行って出力値を決定する組み込みソフトウェアの場合、殆どの入力に対しては正常に動作するが、極めてまれな条件下においてのみ異常が発生することがある。この種の不具合は、不具合が発生する条件を突き止めることが難しく、非再現不具合と呼ばれる。
　特許文献１には、入力仕様と出力仕様とが定義されたソフトウェアコンポーネントにおいて、仕様に違反した入力に対してどの出力が仕様を満たせなくなるかを求めることにより、ソフトウェアコンポーネントの故障時の故障伝搬を評価する手法が記載されている。
特開２０１２－１２８７２７号公報
　特許文献１に記載の手法では、異常な入力を与えた場合のソフトウェアコンポーネントの挙動を評価できるが、通常の入力に対して異常な出力が起こる不具合の原因を分析することはできない。
　非再現不具合の解消のアプローチとして、記号実行を用いた分析を行うことができる。記号実行は、対象のソフトウェアが実行し得る処理の順序（実行パス）を網羅的に抽出し、それぞれのパスを実行する入力を決定する技術である。記号実行を用いることで、テスト時に入力するデータの生成や、不具合が発生する場合の入力データの導出が可能となり、テストを効率的に実施することができる。
　一方で記号実行は、実行パスを網羅的に評価するため、計算リソースと計算時間とを要する。記号実行を複雑で大規模なソフトウェアに適用すると実行パスが膨大となるため計算処理時間が大きくなり、予定された開発期間内で不具合分析を完了することができないことがある。
　本発明は、このような背景を鑑みてなされたものであり、不具合を解消するためのプログラム分析時間の短縮を可能とするプログラム分析装置、プログラム分析方法およびトレース処理追加装置を提供することを課題とする。
　上記した課題を解決するため、本発明に係るプログラム分析装置は、プログラムのなかで順に実行されるステートメントの列である実行パスについて、実行される可能性のある全ての実行パスである全実行パスから、前記プログラムに含まれる条件分岐の分岐先に係る情報を参照して実行されない実行パスを削除する実行パス削減部を備える。
　また本発明に係るトレース処理追加装置は、プログラムに含まれる所定の条件を満たす条件分岐を優先して当該条件分岐のステートメントの直前に、当該条件分岐のステートメントに含まれる変数の値を実行ログに出力するトレース処理を挿入するトレース処理追加部を備え、前記所定の条件は、前記プログラムのなかで順に実行される関数の列である関数実行パスのなかで、複数の前記関数実行パスに含まれる関数にあるという条件、前記プログラムのなかで順に実行されるステートメントの列である実行パスのなかで、複数の前記実行パスに含まれるという条件、過去に不具合が発生した関数にあるという条件、およびテストが未実施である実行パスに含まれるという条件の何れかであることを特徴とする。
　本発明によれば、不具合を解消するためのプログラム分析時間の短縮を可能とするプログラム分析装置、プログラム分析方法およびトレース処理追加装置を提供することができる。
本実施形態に係る不具合分析支援システムの全体構成図である。 本実施形態に係るトレース処理挿入前のソースコードである。 本実施形態に係るトレース処理挿入後のソースコードである。 本実施形態に係る実行パスを説明するための有向グラフである。 本実施形態に係るトレース処理追加装置の機能ブロック図である。 本実施形態に係るトレース処理追加処理のフローチャートである。 本実施形態に係る不具合分析装置の機能ブロック図である。 本実施形態に係る不具合分析処理を説明するための図である。 本実施形態に係る不具合分析処理のフローチャートである。 本実施形態に係る不具合分析結果画面の画面構成図である。 本実施形態の変形例に係る不具合履歴データベースのデータ構成である。 本実施形態の変形例に係るテスト履歴データベースのデータ構成である。
≪不具合分析支援システムの概要≫
　以下に本発明を実施するための形態（実施形態）における不具合分析支援システムについて説明する。不具合分析システムは、プログラム（ソースコード、ソフトウェア）に対して記号実行の技術を用いて不具合箇所（の範囲）を特定する。記号実行とは、変数に具体的な値を代入してプログラムを実行する（プログラムの処理を進める）替わりに、変数に制約条件を設けて制約条件を更新しながらプログラムの実行をシミュレーションする技術である。後記するように、記号実行を用いることで関数の引数と戻り値の仕様に矛盾する引数の値（不具合発生条件）を算出することができ、不具合分析（不具合箇所の特定）に利用することができる。
　プログラムのなかで実行されるステップ（ステートメント）の並びは、実行パスと呼ばれる。実行パスはプログラムが実行する可能性のある処理の順序とも捉えられる。実行される可能性のある全て実行パスに対して記号実行を用いると計算量が膨大になり、不具合分析手法として現実的ではない。
　不具合分析支援システムでは、条件分岐で参照される変数の値を実行ログから取得し、どの分岐が実行されるかを特定して、記号実行の対象となる実行パスを削減する。不具合が発生したときの実行ログを用いることで、不具合が発生する実行パスに対して記号実行を用いることができ、不具合分析に要する時間を短縮することができるようになる。
≪不具合分析支援システムの構成≫
　図１は、本実施形態に係る不具合分析支援システム１０の全体構成図である。図１を参照しながら不具合分析支援システム１０の構成、および不具合分析の流れを説明する。
　不具合分析支援システム１０は、トレース処理追加装置２００と不具合分析装置１００（プログラム分析装置）とを含んで構成される。トレース処理追加装置２００は、ソースコード４１０、実行パス情報４２０、およびトレース仕様４３０を入力とし、トレース処理付きソースコード４４０を出力する。トレース処理追加装置２００は、実行時における変数の値を実行ログ４６０に出力するトレース処理（Ｔｒａｃｅ文）をソースコード４１０に埋め込む。トレース処理追加装置２００の詳細については後記する。
　実行形式生成装置３００は、トレース処理付きソースコード４４０をコンパイルし、必要なライブラリプログラムとリンクして、トレース処理付き実行形式コード４５０（実行形式プログラム）を出力する。トレース処理付き実行形式コード４５０は、実際に実行形式のコードが実行され、異常が発生する実機３５０（例えば車載器）にインストールされる（組み込まれる）。
　なお、特に混同するおそれがない場合には、トレース処理付きソースコード４４０、およびトレース処理付き実行形式コード４５０を単にプログラムとも記す。「プログラムを実行する」のプログラムはトレース処理付き実行形式コード４５０のことであり、「プログラムに含まれるステップ」のプログラムはトレース処理付きソースコード４４０のことである。
　実機３５０がインストール済みのプログラム（トレース処理付き実行形式コード４５０）を実行することで実機３５０が稼働し、実行ログ４６０が生成される。実行ログ４６０には、トレース処理により実行時の変数の値が記録される。他に、呼び出された関数や異常（異常の内容や発生した関数など）が記録されてもよい。
　不具合分析装置１００は、トレース処理付きソースコード４４０、実行パス情報４２０、関数仕様書４７０、および実行ログ４６０を入力とし、不具合分析結果４８０を出力する。不具合分析装置１００は実行ログ４６０を参照して、プログラム（トレース処理付きソースコード４４０）の実行パス全体から実行されていない実行パスを除く。不具合分析装置１００は残った実行パスに対して記号実行処理を行うことで不具合発生個所を特定し、不具合発生条件を不具合分析結果４８０として出力する。不具合分析装置１００の詳細については後記する。
≪トレース処理追加装置の概要≫
　トレース処理追加装置２００は、ソースコード４１０、実行パス情報４２０、およびトレース仕様４３０を入力とし、トレース処理付きソースコード４４０を出力する。トレース処理とは、実行ログ４６０にプログラムの変数の値を記録する処理である。ソースコード４１０は分析対象となるソースコードであって、トレース処理の埋め込み対象である。
　図２は、本実施形態に係るトレース処理挿入前のソースコード４１２である。ソースコード４１２は、ソースコード４１０の一部である。図３は、本実施形態に係るトレース処理挿入後のソースコード４４２である。ソースコード４４２は、トレース処理付きソースコード４４０の一部である。
　ソースコード４１２に含まれる行２の条件分岐文（ｉｆ文）の前にトレース処理（Ｔｒａｃｅ文）のステップが挿入された（埋め込まれた）結果が、ソースコード４４２である。関数ｆｏｏが呼び出されてソースコード４４２の行２が実行（処理）されると、トレース処理の引数となっている変数ｘと変数ｙとの実行時点の値が実行ログ４６０（図１参照）に記録される。
　実行パス情報４２０は、ソースコード４１０に含まれる実行可能性のある全ての実行パスの情報である。
　図４は、本実施形態に係る実行パスを説明するための有向グラフ５００である。有向グラフ５００のノードはソースコードのステップ（ステートメント、文、行）を示し、エッジはステップの実行順序を示す。有向グラフ５００では、ノード５０１が示すステップからプログラムが開始し、ノード５０２が示す条件分岐のステップ（条件分岐文）で実行パスが２つに分かれることを示す。始点となるノード５０１から始まり、終点（例えばノード５２１，５２２，５２３）となるノードまでのそれぞれの有向グラフ５００のパスが実行パスである。有向グラフ５００は実行パス全体を示していることになる。なお、実行パスの部分パスもまた実行パスと呼ぶ。
　上記の説明では有向グラフ５００のノードをソースコードのステップと見なしたが、ソースコードに含まれる関数と見なしてもよい。この場合には、エッジは関数の呼び出し関係と見なされ、実行パスは呼び出される関数の並びとなり、有向グラフ５００は関数の呼び出し関係を示すと見なせる。
　実行パス情報４２０は、ステップの実行パス（ステップ実行パスとも記す）および関数の実行パス（関数実行パスとも記す）の双方を含むものとする。
　図１に戻ってトレース仕様４３０は、トレース処理の挿入処理に係る仕様であって、例えば、挿入可能なトレース処理（Ｔｒａｃｅ文）の上限に係る情報を含む。上限は、実行ログ４６０が記憶される実機３５０の記憶容量、挿入されるＴｒａｃｅ文の数、トレース処理の対象となる変数の数、変数の型（サイズ）などに依存する。説明を簡単にするために本実施形態では、上限は挿入されるＴｒａｃｅ文の数によって決まり、トレース仕様４３０はＴｒａｃｅ文の上限を含むものとする。
≪トレース処理追加装置の構成≫
　図５は、本実施形態に係るトレース処理追加装置２００の機能ブロック図である。トレース処理追加装置２００は、コンピュータであって、制御部２１０、記憶部２２０、および入出力部２８０を含んで構成される。入出力部２８０には、ディスプレイやキーボード、マウスなどのユーザインターフェイス機器が接続される。また入出力部２８０は、記録媒体とのインターフェイス機能や他の装置との通信機能を備える。
　記憶部２２０は、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）、ＳＳＤ（Solid State Drive）などから構成される。記憶部２２０には、プログラム２２１、および関数実行パスデータベース２３０（図５では関数実行パスＤＢ（Database）と記載）が記憶される。プログラム２２１は、トレース挿入処理（後記する図６参照）の記述を含む。関数実行パスデータベース２３０には、ソースコード４１０の実行パス情報が格納される。
　制御部２１０はＣＰＵ（Central Processing Unit）を含んで構成され、ソースコード入出力部２１１、トレース箇所決定部２１２、およびトレース処理追加部２１３を備える。ソースコード入出力部２１１は入出力部２８０を介してソースコード４１０（図１参照）や実行パス情報４２０、トレース仕様４３０を取得して記憶部２２０に記憶したり、トレース処理付きソースコード４４０を出力したりする。なお、ソースコード入出力部２１１は実行パス情報４２０に含まれる関数実行パスを関数実行パスデータベース２３０に格納する。
　トレース箇所決定部２１２は、ソースコード４１０のなかでＴｒａｃｅ文の挿入箇所を決定する。詳しくは、トレース箇所決定部２１２は関数実行パス（関数の呼び出し関係）と見なした有向グラフ５００（図４参照）における始点となるノード５０１から終点までのノードまでの実行パスが多く通るノードに対応する関数から順にＴｒａｃｅ文を挿入する候補の関数とする。換言すれば、トレース箇所決定部２１２は関数実行パスデータベース２３０を参照して通る実行パスが多いノード（関数）ほどＴｒａｃｅ文の挿入順位が高いとする。
　例えば、ノード５０１，５０２（図４参照）は全ての実行パスが通るため、Ｔｒａｃｅ文挿入の最高順位となる。また、ノード５１３の上流にはノード５１１があり、ノード５１１を通る実行パスはノード５１３を通るので、ノード５１３はノード５１１より挿入順位が高くなる。有向グラフ５００を関数の呼び出し関係と見なすと、ノード５０１，５０２に対応する関数が、Ｔｒａｃｅ文挿入順位が最高の関数となる。また、ノード５１３に対応する関数はノード５１１に対応する関数より挿入順位が高くなる。
　トレース処理追加部２１３は、ソースコードの条件分岐文（ｉｆ文）の前に、当該条件分岐の判定に参照される変数の値を実行ログ４６０に出力するＴｒａｃｅ文を挿入する。
≪トレース処理追加処理≫
　図６は、本実施形態に係るトレース処理追加処理のフローチャートである。
　ステップＳ１１においてソースコード入出力部２１１は、ソースコード４１０（図１参照）、実行パス情報４２０、およびトレース仕様４３０を取得して記憶部２２０に格納する。
　ステップＳ１２においてトレース箇所決定部２１２は、Ｔｒａｃｅ文を挿入する関数の順位を決定する。トレース箇所決定部２１２は通る実行パス（図４記載の関数の呼び出し関係と見なす有向グラフ５００参照）が多いノード（関数）ほどＴｒａｃｅ文の挿入順位が高いとする。
　ステップＳ１３においてトレース箇所決定部２１２は、ステップＳ１２で決定した挿入順位の高い関数から順にステップＳ１４～Ｓ１５を繰り返す処理を開始する。
　ステップＳ１４においてトレース箇所決定部２１２は、関数にＴｒａｃｅ文を挿入すると上限を超えるか否かを判断する。トレース箇所決定部２１２は上限を超えるならば（ステップＳ１４→ＹＥＳ）繰り返し処理を終えてステップＳ１６に進み、超えないならば（ステップＳ１４→ＮＯ）ステップＳ１５に進む。なお上限は、トレース仕様４３０に含まれるＴｒａｃｅ文の挿入可能な上限数である。
　ステップＳ１５においてトレース処理追加部２１３は、関数の条件分岐文の前にＴｒａｃｅ文を挿入する（図２、図３参照）。
　ステップＳ１６においてソースコード入出力部２１１は、Ｔｒａｃｅ文が挿入されたソースコード（図１記載のトレース処理付きソースコード４４０）を出力する。
≪不具合分析装置の構成≫
　不具合分析装置１００は、トレース処理付きソースコード４４０、実行パス情報４２０、関数仕様書４７０、および実行ログ４６０を入力とし、不具合分析結果４８０を出力する（図１参照）。関数仕様書４７０は、ソースコード４１０に含まれる関数の仕様書であって、引数および戻り値の型や範囲を含む（後記する図８記載の関数仕様４７９参照）。
　図７は、本実施形態に係る不具合分析装置１００の機能ブロック図である。不具合分析装置１００はコンピュータであって、制御部１１０、記憶部１２０、および入出力部１８０を備える。入出力部１８０には、ディスプレイやキーボード、マウスなどのユーザインターフェイス機器が接続される。また入出力部１８０は、記録媒体とのインターフェイス機能や他の装置との通信機能を備える。
　記憶部１２０は、ＲＯＭやＲＡＭ、ＳＳＤなどから構成される。記憶部１２０には、プログラム１２１、関数実行パスデータベース１３０、実行パスデータベース１４０、関数仕様データベース１５０、および実行ログデータベース１６０が記憶される。図７では、関数実行パスデータベース１３０を関数実行パスＤＢと、実行パスデータベース１４０を実行パスＤＢと、関数仕様データベース１５０を関数仕様ＤＢと、実行ログデータベース１６０を実行ログＤＢと記載している。プログラム１２１は、不具合分析処理（後記する図９参照）の記述を含む。
　制御部１１０はＣＰＵを含んで構成され、関数仕様取得部１１１、実行パス削減部１１２、不具合箇所検出部１１３、および記号実行エンジン１１４を備える。関数仕様取得部１１１は、入出力部１８０を介してトレース処理付きソースコード４４０、実行パス情報４２０、関数仕様書４７０、および実行ログ４６０を取得する。関数仕様取得部１１１は、実行パス情報４２０に含まれるステップ実行パスを実行パスデータベース１４０に、実行パス情報４２０に含まれる関数実行パスを関数実行パスデータベース１３０に、関数仕様書４７０を関数仕様データベース１５０に、実行ログ４６０を実行ログデータベース１６０にそれぞれ格納する。実行パス情報４２０に含まれるステップの実行パス情報が格納された時点で実行パスデータベース１４０には、全ての可能性のあるステップ実行パス（全実行パス）が含まれている。
　実行パス削減部１１２は、ステップ実行パスを削減する。図３に示す関数ｆｏｏのソースコード４４２において、関数ｆｏｏ内の実行パスとして、行２、行３、行４と進む実行パスと、行２、行３、行６と進む実行パスとがある。実行ログデータベース１６０に含まれる行２のＴｒａｃｅ文の出力結果である変数ｘと変数ｙの値（トレース結果とも記す）を参照することで、実行パス削減部１１２は何れの実行パスを通ったのかが判定できる。詳しくは、実行パス削減部１１２は実機３５０（図１参照）におけるプログラム実行時に、実機３５０が何れの実行パスを通った（実行した）のかが特定できる。実行パス削減部１１２は、条件分岐で複数に分かれた実行パスのなかで通っていない（実行されなかった、到達していない）実行パスを特定して、実行パスデータベース１４０から削除する。このようにして実行パス削減部１１２は、全ての可能性のある実行パス（全実行パス）から実行されなかった実行パスを削減する。
　不具合箇所検出部１１３は、実行パスデータベース１４０に残存している実行パスに含まれる関数のなかから不具合が発生している関数を、記号実行エンジン１１４を用いて検出する。詳しくは、不具合箇所検出部１１３は残存している実行パスを通る記号実行を行い、不具合が発生する条件（引数と戻り値の値）を算出する。
　図８は、本実施形態に係る不具合分析処理を説明するための図である。不具合箇所検出部１１３は、関数仕様書４７０（図１参照）に示された関数の引数の範囲を示す論理式と、戻り値の範囲外を示す論理式との論理積を満たす引数と戻り値とを不具合発生条件として算出する。算出には記号実行技術を用いる。以下では関数ｂａｒを例に説明する。
　関数ｂａｒの仕様は、関数仕様４７９に示すとおりであって、引数の範囲を示す論理式（１）および戻り値の範囲外を示す論理式（２）は以下のとおりである。論理式（２）は戻り値の範囲を示す論理式の否定でもある。なお、「＆」は論理積（ＡＮＤ）であり「｜」は論理和（ＯＲ）である。
　０＜＝ａ　＆　ａ＜＝５　＆　０＜＝ｂ　＆　ｂ＜＝５　　　　　（１）
　ｃ＜１　｜　１０＜＝ｃ　　　　　　　　　　　　　　　　　　　（２）
　関数ｂａｒを起点とする（ステップ）実行パスは２つある。第１の実行パスは、ソースコード４１１の行２、行３、ソースコード４４２の行２、行３、行４、ソースコード４１１の行３、行４である。第２の実行パスは、ソースコード４１１の行２、行３、ソースコード４４２の行２、行３、行６、ソースコード４１１の行３、行４である。この２つの実行パスは、ソースコード４４２の行３にあるｉｆ文に示される条件（ｘ＜ｙ）に応じて分岐している。ここで、ソースコード４１１の行３については、関数ｆｏｏの呼び出し前後で２回実行パスに含めている。
　関数ｆｏｏの第１引数ｘはａ＋ｂ、第２引数ｙはａ－ｂであるので、第１の実行パスの場合には論理式（３）が成り立ち、第２の実行パスの場合には論理式（４）が成り立つ。
　ａ＋ｂ　＜　ａ－ｂ　＆　ｃ＝ａ－ｂ　　　　　　　　　　　　　（３）
　ａ＋ｂ　＞＝　ａ－ｂ　＆　ｃ＝ａ＋ｂ　　　　　　　　　　　　（４）
　ソースコード４４２の行３の条件分岐（ｉｆ文）で何れの分岐に進むか不明の場合には、不具合箇所検出部１１３は（（１）＆（２）＆（３））｜（（１）＆（２）＆（４））という論理式から不具合発生条件を算出する必要がある。しかしながら、当該条件分岐で何れの実行パスに進むかが解れば分岐先となる実行パスに応じて、（１）＆（２）＆（３）または（１）＆（２）＆（４）を解けばよく、不具合発生条件の算出が効率化できる。
　例えばトレース結果１６９は、プログラム実行時に変数ｘと変数ｙとがともに５であったことを示しており、第１の実行パスが削除され第２の実行パスが残るため、（１）＆（２）＆（４）から不具合発生条件を算出すればよい。
　不具合箇所検出部１１３は、実行パス削減部１１２が削減して残った実行パスについて記号実行を行い、不具合が発生する関数と不具合発生条件とを求める。記号実行の対象となる関数は、関数実行パスの終点となる関数から始めて実行パスの上流に向かってもよいし、逆向きでもよい。
≪不具合分析処理≫
　図９は、本実施形態に係る不具合分析処理のフローチャートである。
　ステップＳ２１において関数仕様取得部１１１は、実行パス情報４２０（図１参照）、関数仕様書４７０、トレース処理付きソースコード４４０、および実行ログ４６０を取得する。関数仕様取得部１１１は、取得した関数仕様書４７０と実行ログ４６０とを関数仕様データベース１５０と実行ログデータベース１６０とにそれぞれ格納する。また、関数仕様取得部１１１は、実行パス情報４２０に含まれる関数実行パスおよびステップ実行パスを関数実行パスデータベース１３０および実行パスデータベース１４０にそれぞれ格納する。
　ステップＳ２２において実行パス削減部１１２は、実行ログデータベース１６０に含まれるトレース結果を取得する。
　ステップＳ２３において実行パス削減部１１２は、ステップＳ２２で取得したトレース結果ごとにステップＳ２４を繰り返す処理を開始する。
　ステップＳ２４において実行パス削減部１１２は、トレース結果に含まれる変数結果を参照して条件分岐で複数に分かれた実行パスのなかで通っていない（実行されなかった、到達していない）ステップ実行パスを特定して、実行パスデータベース１４０から削除する。
　ステップＳ２５において不具合箇所検出部１１３は、実行パス削減部１１２が削減して残った実行パスについて記号実行を行い、不具合が発生する関数と不具合発生条件とを算出する。算出された不具合発生条件は、不具合分析結果４８０として出力される。
　図１０は、本実施形態に係る不具合分析結果画面７１０の画面構成図である。不具合分析結果画面７１０の左側には、関数ｂａｒのソースコード表示領域７１１、および関数ｆｏｏのソースコード表示領域７１２が配置されている。右側には、関数ｂａｒの引数の仕様表示領域７１５、戻り値の仕様表示領域７１７、不具合発生条件の表示領域７１６、および不具合発生内容の表示領域７１８が配置されている。ソースコード表示領域７１１，７１２では、実行パスが反転表示されている。不具合発生条件の表示領域７１６、および不具合発生内容の表示領域７１８の左近傍には警告マークが表示されており、注目を促すようになっている。
　不具合分析結果画面７１０を参照することで、開発者は不具合の内容（不具合発生内容の表示領域７１８参照）、不具合が発生する条件（不具合発生条件の表示領域７１６参照）、不具合発生の経過（反転表示された実行パス参照）を容易に把握することができる。延いては、開発者は不具合対策を効率よく進めることができるようになる。
≪不具合分析システムの特徴≫
　トレース処理追加装置２００はソースコード４１０にトレース処理（Ｔｒａｃｅ文）を追加する。不具合分析装置１００は、トレース処理が出力したトレース結果を参照してソースコード４１０に含まれる実行パスを削減し、残った実行パス（残存実行パス）について記号実行処理を行って、不具合発生条件を算出する。
　不具合分析装置１００はトレース結果を参照することで、実行パスを削減することができる。実行パスの数は、条件分岐があるごとに倍になる。このため実行パスの数は、関数に含まれる（当該関数が直接／間接に呼び出す関数も含む）条件分岐数のべき乗のオーダーであり、条件分岐数に応じて指数関数的に増える。不具合分析装置１００はトレース結果を参照して条件分岐でどちらに分岐に進むかを特定することで、実行パスを大きく削減することができる。続いて不具合分析装置１００は、残った実行パスに含まれる関数について引数と戻り値の範囲について仕様と矛盾する不具合発生条件（不具合条件）を算出する。
　不具合分析装置１００は不具合条件を効率よく算出でき、開発者は不具合条件を参照することで不具合を特定して修正することができる。
　トレース処理追加装置２００は、通る実行パスが多く呼び出し回数が多いため、不具合発生の頻度が高いと考えられる関数から順にＴｒａｃｅ文を挿入する。このようにすることで実行ログのサイズを抑えつつ効率よく不具合発生時の変数情報を取得できるようになる。延いては実行ログのための実機３５０の記憶容量を抑えることができ、コストを抑制することができる。
≪変形例：トレース処理追加≫
　上記した実施形態においてトレース処理追加装置２００のトレース箇所決定部２１２は、通る実行パスが多いノード（関数）ほどＴｒａｃｅ文の挿入順位が高いとしている（図６記載のステップＳ１２参照）。トレース箇所決定部２１２は、不具合発生が多い関数ほどＴｒａｃｅ文の挿入順位を高くするようにしてもよい。また、トレース箇所決定部２１２は、テストを行っていない実行パスへのＴｒａｃｅ文の挿入順位を高くするようにしてもよい。
　図１１は、本実施形態の変形例に係る不具合履歴データベース６１０のデータ構成である。不具合履歴データベース６１０は、トレース処理追加装置２００の記憶部２２０に記憶される。不具合履歴データベース６１０は表形式のデータであって、１つの行（レコード）は１つの不具合発生を示す。レコードは、識別番号６１１（図１１では＃と記載）、不具合発生日時６１２、および発生箇所６１３の列（属性）を含む。識別番号６１１は、不具合発生の識別情報である。不具合発生日時６１２は、不具合が発生した日時である。発生箇所６１３は、不具合があった関数である。
　図１１記載の不具合履歴データベース６１０によると、関数Ａで３件、関数Ｂで２件の不具合が発生している。このため、関数Ａおよび関数Ｂには、まだ見つかっていない不具合がある可能性が高いと推定される。このような推定に基づいてトレース箇所決定部２１２は、Ｔｒａｃｅ文の挿入順位について、不具合発生が発生した関数を高くするようにしてもよい。トレース箇所決定部２１２は、不具合発生の回数が多い関数ほど、Ｔｒａｃｅ文の挿入順位を高くするようにしてもよい。このようにしてＴｒａｃｅ文の挿入順位を決めることで、不具合発生が多いと思われる関数を通る実行パスを削減できるようになる。
　図１２は、本実施形態の変形例に係るテスト履歴データベース６２０のデータ構成である。テスト履歴データベース６２０は、トレース処理追加装置２００の記憶部２２０に記憶される。テスト履歴データベース６２０は表形式のデータであって、１つの行（レコード）は１つのテストを示す。レコードは、識別番号６２１（図１２では＃と記載）、テスト日時６２２、および実行パス６２３の列（属性）を含む。識別番号６２１は、テストの識別情報である。テスト日時６２２は、テストを行った日時である。実行パス６２３は、テストした実行パスである。
　テスト済みの実行パスに不具合が含まれている可能性は低く、テストをしていない実行パスに、まだ見つかっていない不具合がある可能性が高いと推定される。このような推定に基づいてトレース箇所決定部２１２は、Ｔｒａｃｅ文の挿入順位について、テストしていない実行パスを高くするようにしてもよい。このようにしてＴｒａｃｅ文の挿入順位を決めることで、不具合発生が多いと思われる実行パスと部分パスを共有する実行パスを削減できるようになる。
　上記した実施形態ではトレース箇所決定部２１２は、実行パス情報４２０に含まれる関数の呼び出し関係である関数実行パスが多く通る関数から順にＴｒａｃｅ文を挿入する候補の関数とする（図６のステップＳ１２参照）。トレース箇所決定部２１２はステップ実行パスを参照して、実行パスが多く通る条件分岐文から順にＴｒａｃｅ文を（当該条件文に前に）挿入する候補としてもよい。関数単位に比べて、より細かい粒度でＴｒａｃｅ文の挿入順位を決めることができるようになり、より有用なトレース結果が実行ログに記録され、不具合分析の効率が向上するようになる。
≪変形例：トレース処理≫
　上記の実施形態におけるトレース処理（Ｔｒａｃｅ文）は、条件分岐文に含まれる変数の値を実行ログに出力している。不具合分析装置１００は、この値を参照して何れの分岐先に分岐したかを判断している。トレース処理は、変数の値を出力する替わりに何れの分岐先に分岐したかを示す情報を出力するようにしてもよい。例えば、条件分岐文の条件式の値（条件の真偽値）を記録するようにしてもよい。
≪変形例：不具合条件≫
　上記した実施形態では不具合条件（不具合発生条件）として、不具合分析装置１００は関数の引数の範囲を示す論理式と、戻り値の範囲外を示す論理積との論理積を満たす条件（引数の値）を算出している（図８参照）。不具合分析装置１００は関数仕様と矛盾（相反）する他の不具合条件を求めてもよい。例えば、関数の引数の範囲を示す論理式と、実行パスのなかで当該関数が直接または間接に呼び出す関数の引数の範囲外を示す論理式との論理積を満たす条件を算出してもよい。例えば図８において、関数ｂａｒの引数の仕様から求まる関数ｆｏｏの引数（ａ＋ｂ、ａ－ｂ）の範囲を示す論理式と、関数ｆｏｏの引数の仕様で示される論理式の否定との論理積を満たす条件を算出してもよい。
　上記した実施形態において記号実行を用いて不具合条件を探す対象の関数は、実行パスに含まれる関数である。実行パスに含まれる関数であって、不具合が多く発生している関数（図１１参照）から順に不具合条件を探すようにしてもよい。また、テストをしていない実行パスを含む（図１２参照）関数から順に不具合条件を探すようにしてもよい。実行ログ４６０に異常（エラー）が発生した関数やステップの情報が含まれていれば、不具合分析装置１００は当該関数、または当該ステップを含む関数から順に不具合条件を探すようにしてもよい。または、不具合分析装置１００の利用者（開発者）が指定した関数について不具合条件を探すようにしてもよい。このように、優先順位を付けて不具合条件を求めることで、より効率的に不具合条件を算出することができる。
　前記不具合条件を探す対象は残存実行パスに含まれる関数（メソッド）であったが、加減乗除やインクリメントなどの演算を関数と見なして含めてもよい。例えば不具合箇所検出部１１３は、変数（変数の型）の仕様を利用して不具合条件を探してもよい。例えば加算について不具合箇所検出部１１３は、加算の結果が変数の仕様の範囲内であって、桁あふれが発生しないことを条件に不具合条件を探してもよい。また、配列のインデックスとなる変数や式について不具合箇所検出部１１３は、その値が当該配列の長さに対応していることを条件に不具合条件を探してもよい。
≪その他変形例≫
　以上、本発明のいくつかの実施形態について説明したが、これらの実施形態は、例示に過ぎず、本発明の技術的範囲を限定するものではない。例えば、上記した実施形態では、トレース処理追加装置２００、および不具合分析装置１００の入力として、全ての実行パス情報を含む実行パス情報４２０がある。トレース処理追加装置２００および不具合分析装置１００は、ソースコード４１０またはトレース処理付きソースコード４４０を分析して実行パスを抽出して、実行パス情報４２０を不要としてもよい。
　不具合分析支援システム１０は不具合分析装置１００およびトレース処理追加装置２００を含んで構成されるが、２つの装置は一体となって１つの装置であってもよい。また、一部の機能部が一体となってもよい。例えば、トレース箇所決定部２１２とトレース処理追加部２１３とが一体となってトレース処理追加部となってもよいし、不具合箇所検出部１１３と記号実行エンジン１１４とが一体となって不具合箇所検出部となってもよい。
　本発明はその他の様々な実施形態を取ることが可能であり、さらに、本発明の要旨を逸脱しない範囲で、省略や置換等種々の変更を行うことができる。これら実施形態やその変形は、本明細書等に記載された発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
１０　　不具合分析支援システム
１００　不具合分析装置（プログラム分析装置）
１１１　関数仕様取得部（実行パス取得部）
１１２　実行パス削減部
１１３　不具合箇所検出部
１１４　記号実行エンジン
２００　トレース処理追加装置
２１１　ソースコード入出力部
２１２　トレース箇所決定部（トレース処理追加部）
２１３　トレース処理追加部
４１０　ソースコード
４２０　実行パス情報
４３０　トレース仕様
４４０　トレース処理付きソースコード
４６０　実行ログ
４７０　関数仕様書
４８０　不具合分析結果（不具合条件）
５００　有向グラフ（実行パス）

Claims (9)

  1. 　プログラムのなかで順に実行されるステートメントの列である実行パスについて、実行される可能性のある全ての実行パスである全実行パスから、前記プログラムに含まれる条件分岐の分岐先に係る情報を参照して実行されない実行パスを削除する実行パス削減部を備える
    　ことを特徴とするプログラム分析装置。
  2. 　前記条件分岐の分岐先に係る情報は、前記プログラムの実行時に生成される実行ログに含まれる当該条件分岐で参照される変数の値、および当該条件分岐に含まれる条件式の値の何れかである
    　ことを特徴とする請求項１に記載のプログラム分析装置。
  3. 　前記プログラムに含まれる関数の引数および戻り値の範囲の仕様を取得する関数仕様取得部と、
    　前記実行パス削減部が削除した後の残存実行パスに含まれる関数のなかで、前記仕様と矛盾する前記引数の値である不具合条件を算出する不具合箇所検出部とをさらに備える
    　ことを特徴とする請求項１に記載のプログラム分析装置。
  4. 　前記不具合条件は、
    　前記残存実行パスに含まれる関数のなかで、前記引数の範囲を示す論理式と、前記戻り値の範囲を示す論理式の否定となる論理式との論理積を満足する前記引数および前記戻り値の値である不具合条件、および
    　前記残存実行パスに含まれる関数のなかで、前記引数の範囲を示す論理式と、前記残存実行パスのなかで当該関数が直接または間接に呼び出す被呼び出し関数の引数の範囲を示す論理式の否定となる論理式との論理積を満足する当該関数の引数の値である不具合条件、の何れかである
    　ことを特徴とする請求項３に記載のプログラム分析装置。
  5. 　前記不具合箇所検出部は、前記プログラムの実行時にエラーが発生したステートメントを含む前記残存実行パスを特定して、前記不具合条件を算出する
    　ことを特徴とする請求項３に記載のプログラム分析装置。
  6. 　前記不具合箇所検出部は、不具合条件を算出する関数として過去に不具合が発生した関数を優先して不具合条件を算出する
    　ことを特徴とする請求項３に記載のプログラム分析装置。
  7. 　前記不具合箇所検出部は、不具合条件を算出する関数としてテストが未実施である実行パスを含む関数を優先して不具合条件を算出する
    　ことを特徴とする請求項３に記載のプログラム分析装置。
  8. 　プログラム分析装置のプログラム分析方法であって、
    　前記プログラム分析装置は、
    　プログラムのなかで順に実行されるステートメントの列である実行パスについて、実行される可能性のある全ての実行パスである全実行パスから、前記プログラムに含まれる条件分岐の分岐先に係る情報を参照して実行されない実行パスを削除するステップを実行する
    　ことを特徴とするプログラム分析方法。
  9. 　プログラムに含まれる所定の条件を満たす条件分岐を優先して当該条件分岐のステートメントの直前に、当該条件分岐のステートメントに含まれる変数の値を実行ログに出力するトレース処理を挿入するトレース処理追加部を備え、
    　前記所定の条件は、
    　前記プログラムのなかで順に実行される関数の列である関数実行パスのなかで、複数の前記関数実行パスに含まれる関数にあるという条件、
    　前記プログラムのなかで順に実行されるステートメントの列である実行パスのなかで、複数の前記実行パスに含まれるという条件、
    　過去に不具合が発生した関数にあるという条件、および
    　テストが未実施である実行パスに含まれるという条件の何れかである
    　ことを特徴とするトレース処理追加装置。
PCT/JP2022/005804 2021-03-18 2022-02-15 プログラム分析装置、プログラム分析方法およびトレース処理追加装置 WO2022196219A1 (ja)

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)

* Cited by examiner, † Cited by third party
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

Patent Citations (2)

* Cited by examiner, † Cited by third party
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