JP6416588B2 - Source code verification system - Google Patents

Description

  The present invention relates to an apparatus and a tool for inspecting software source code.

  In the information control system, there may be a problem that occurs depending on the execution timing of the program processing. As an example of a defect, there is a plurality of execution units (process, thread, task, etc.) executed in parallel or in parallel to a program for one variable of the program, and there is data contention in which reading and writing overlap. Such defects are difficult to find and often difficult to find out due to lack of reproducibility even if they occur.

  One of the methods for finding such a defect depending on the processing timing is static analysis of the source code. Analyzes the possibility of defects in the program through analysis. For example, the possibility of data conflict is detected by searching for writing to the same variable on the execution path of different execution units.

  However, since timing-dependent defects also occur for causes other than data competition, the types of timing-dependent defects that can be detected by static analysis are limited. In addition, the possibility of a failure detected by static analysis does not necessarily cause a failure, and conversely, a non-failure (false positive) may be detected in many cases. To solve these problems, model checking, which is one of formal methods, can be applied. In model checking, false abstraction does not occur if the abstraction is appropriate in the representation of the design in the model description language. In addition, since the behavior of the program is comprehensively examined, it is possible to detect problems that depend on timing. In Patent Document 1, a failure caused by an interrupt is detected using model checking.

  On the other hand, the model check also has problems for performing a comprehensive check. This is a problem that the amount of calculation becomes large, so that resources such as a memory of a computer are insufficient, the calculation time becomes long, and verification is not completed. As measures against this, the above-described abstraction and narrowing of the inspection range are taken. In Patent Document 2, by analyzing a dependency relationship (variable dependency relationship) between variables in a source code of a program to be inspected, codes related to the focused variable are narrowed down. In addition, variable dependency is displayed, and a range can be specified for further narrowing down the code to be converted by the user into the verification model.

  However, when narrowing down the verification range, it is necessary to divide the program and execute a plurality of verifications in order to verify the program widely. This division and execution of multiple verifications increase the labor and time required for verification. For this reason, under limited manpower and time, there are cases where it is necessary to perform verification preferentially from places where there is a high possibility of malfunction. In particular, when a non-reproducible defect is found and the cause is searched, unlike the case where the entire program is verified to indicate that there is no defect, it is possible to detect one defect at an early stage and analyze the cause. Therefore, the idea of prioritizing the verification targets is important. Therefore, the possibility of a defect for each part to be verified is evaluated, and information indicating the priority of the verification target based on the evaluation, or information that can be used to give priority by the verifier is provided to the verifier. That information is useful.

  As a technique for evaluating the possibility of a defect for each part to be verified, in Patent Document 3, a variable a belonging to an execution unit A on a variable dependency relationship is different from a variable b belonging to a different execution unit B. When there is a dependency relationship with the variable c belonging to, the execution priorities of the execution units A, B, and C are compared to evaluate the consistency. For example, it is evaluated that there is no consistency when the priorities of the execution units B and C are different, and it is evaluated that there is consistency when the priorities match.

JP 2011-191843 A JP2013-156786A JP 2013-254371 A

  However, problems that depend on the timing can occur even when the execution priority of execution units is consistent. For this reason, in the above prior art, when the execution priority order of execution units is the same, the possibility of a failure cannot be detected, and useful information cannot be appropriately provided to the verifier. There is.

  Accordingly, an object of the present invention is to provide a source code verification system that can appropriately provide useful information to a verifier.

  The present invention, based on variable dependency relationship data relating to the dependency relationship of variables included in a program, a failure factor detection means for detecting a location having a variable dependency across different execution units as a possible failure factor, An evaluation score calculating means for calculating an evaluation score of the possibility of malfunction related to the location based on the variable dependency relationship, and an evaluation score displaying means for displaying the evaluation score are provided.

  According to the present invention, useful information can be appropriately provided to a verifier.

1 is a system configuration according to an embodiment of the present invention. Structure of the program related to the function of the source code verification system. Processing flow of the program related to the source code verification system. Processing flow of the variable dependency search unit. Sample code. Graph of variable dependency of sample code. Sample code evaluation data. Display of sample code evaluation results. Display the evaluation result of the modified sample code.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a configuration diagram of a source code verification system according to the present embodiment. This source code verification system is realized as a software tool. Each function is implemented as software, and is executed on a computer including a display screen, a main arithmetic device, a main storage device (main memory), a storage medium such as a hard disk, and an input device such as a keyboard and a pointing device.

  Software for realizing the source code verification system is stored in the ROM 113 of the computer 110 as the source code evaluation program 120, and is read and executed by the CPU 111. The computer 110 executes processing specified by the source code evaluation program 120. A source code file that is the source of the object code to be inspected and a verification model file created based on the source code are stored in the hard disk 114 on the computer 110. A user operation on the source code evaluation program 120 can be performed from the input device 130 such as a keyboard. The output by the source code evaluation program 120 is displayed on a display device 140 such as a display or generated as a data file on the hard disk 114, but is output to a non-illustrated external computer via a network, an external device such as a CD-ROM. It may be output by writing to a storage medium in a data file format. Other programs are also operated by inputting and outputting in the same manner as the source code evaluation program 120.

  FIG. 2 shows the configuration of the program stored in the ROM 113. The programs include a verification model generation program 210 and a source code evaluation program 120.

  The verification model generation program 210 receives the source code 200 and outputs a verification model 240. The verification model generation program 210 includes a code analysis unit 220, a variable dependency extraction unit 225, a code extraction unit 230, and a conversion unit 235. The code analysis unit 220 analyzes the variable dependency relationship of the source code 220. The variable dependency relationship extraction unit 225 receives the variable dependency relationship data from the code analysis unit 220, and extracts the variable dependency relationship for the variable designated by the user. The code extraction unit 230 extracts a code related to the variable dependency relationship data extracted by the variable dependency relationship extraction unit 225 from the source code 200. The conversion unit 235 generates and outputs a verification model 240 by converting the code extracted by the code extraction unit 230 into a model description language according to a predetermined conversion rule.

  The source code evaluation program 120 includes an input unit 250, a detection unit 260, an evaluation score calculation unit 270, an evaluation database 280, and a display unit 290. The input unit 250 reads the variable dependency relationship data extracted by the variable dependency relationship extraction unit 225 as an input. The detection unit 260 analyzes the variable dependency relationship data read by the input unit 250, detects a dependency relationship across different execution units as a possible defect factor, and records it in the evaluation database 280. The evaluation score calculation unit 270 determines, based on the variable dependency relationship data read by the input unit 250 and the detection result of the possibility of the failure factor by the detection unit 260, about each variable on the variable dependency relationship, that is, for each part of the program. An evaluation score of the possibility of malfunction is calculated and recorded in the evaluation database 280. The display unit 290 acquires the evaluation score calculated by the evaluation score calculation unit 270 from the evaluation database 280 and displays it on the display device 290. The display unit 290 may display the evaluation score together with the variable dependency relationship data.

  FIG. 3 is a processing flow executed by the verification model generation program 210 and the source code evaluation program 120. In step 300, the process is started. At this time, the evaluation database 280 is initialized. In step 310, the code analysis unit 220 analyzes the source code 200 and generates variable dependency relationship data. In step 320, the variable dependency extraction unit 225 extracts variable dependency relationship data related to the variable designated by the user from the variable dependency relationship data analyzed by the code analysis unit 220. In step 330, the input unit 250 reads the variable dependency relationship data extracted by the variable dependency relationship extraction unit 225 as an input. In step 340, the detection unit 260 analyzes the variable dependency relationship data, detects a dependency relationship across different execution units, and records it as evaluation data in the evaluation database 280. In step 350, the evaluation score calculation unit 270 calculates an evaluation score of possibility of failure for each variable on the variable dependency relationship, and records it in the evaluation database 280 as evaluation data. In step 360, display unit 290 acquires the evaluation score calculated by evaluation score calculation unit 270 from evaluation database 280 and displays it on display device 290. In step 390, the process ends.

  FIG. 4 is a flow detailing the process of step 350 by the evaluation score calculation unit 270. This process is executed at each node of the variable dependency relationship data extracted in the tree format, and is recursively executed from the root node toward the lower nodes. In step 400, the process is started. Steps 410 to 450 are executed for each lower node. In step 410, the process of this flow is executed for each lower node. Step 420 to step 450 are executed for each variable that is evaluated by one lower node. In step 420, evaluation data in the lower node for one variable is acquired from the evaluation database 280. This evaluation data is classified into category 1 and category 2. Category 2 shows the possibility of data race, and category 1 shows the other possibility. The reason that category 2 indicates the possibility of data conflict is that access to the same variable appears below the variable tree.

  In step 430, it is determined from the evaluation database 280 whether the variable targeted in step 420 is an evaluation target in the current node. If the evaluation data regarding the variable is not in the evaluation database 280, that is, it is not an evaluation target, and the evaluation data of the variable at the lower node is category 1, the process proceeds to step 440. Otherwise, that is, if there is evaluation data and it is an evaluation target, or if the evaluation data at the lower node is category 2, the process proceeds to step 450. In step 440, the evaluation data at the lower node relating to the variable is recorded in the evaluation database 280 as the category 1 evaluation data of the node. In step 450, the evaluation data at the lower node regarding the variable is added to the evaluation data of category 2 of the current node. Further, the evaluation data of category 1 relating to the variable at the current node is cleared, added to category 2, and recorded in evaluation database 280. After the processing is performed for all the evaluation target variables and the lower nodes, this flow is finished in step 490.

  As shown in the processing flow of FIG. 4, the failure risk in the lower node and the failure risk included in the code extracted by the code extraction unit 230 are evaluated by counting the detection results of the failure factor in the lower node at the upper node. Can do.

  FIG. 5 shows a part of the source code of the sample program to be verified. In this embodiment, it is assumed that the source code is written in C language. The configuration of a program composed of source files 510, 520, and 530 will be described below. The main process is a function func. The function input is set to be executed by interruption, and substitutes the value input to the register variable DI0 for the variable a. The value of register variable DI0 can change at any time. In the function func, the process of doubling the variable a is performed redundantly in the functions calc1 and calc2, the two calculation results x1 and x2 are compared, and if they match, the calculation result is fixed and assigned to the variable x, If they do not match, the error handling is performed by the function err_handle.

  FIG. 6 is a graph of the variable dependency data obtained by analyzing the sample source code of FIG. 5 by the code analysis unit 220 and the variable dependency extraction unit 225 extracting the variable x (line 016) as a root node in a tree format. Variable tree 600. In the variable dependency relationship data and the variable tree 600, the node indicates a variable, and the variable is distinguished by the description position and the execution unit to which the node belongs. For example, x @ 016 means the variable x on the 016th line. The execution unit or function to which each variable belongs is not shown in the figure, but is included in the data. In the variable tree 600, a control syntax such as an “if” statement is also handled as a node. A variable node with an oblique line means that the node has already appeared in another part of the variable tree (hereinafter referred to as “existing node”), and a lower node is omitted. An arrow indicates a dependency relationship, and the source of the arrow affects the dependency source, that is, the variable value, and the tip of the arrow indicates the dependency destination, that is, the affected one. A solid line arrow means that the dependency destination and the dependency source variable are included in the same execution unit, and a broken line arrow means that the different dependency destination and the dependency source variable belong to different execution units.

  In step 340, the detection unit 260 searches the variable tree 600, and finds and extracts a dependency represented by a dashed arrow. In the variable tree 600, a dependency relationship from a @ 205 to a @ 104 and a dependency relationship from a @ 205 to a @ 109 correspond. These are dependency relationships that extend over different execution units, and are recognized as possible fault factors depending on the processing timing.

  FIG. 7 shows the contents of the evaluation database 280 relating to the sample source code of FIG. In the evaluation data 700, the evaluation data for each of the category 1 and the category 2 is recorded for each node of the variable tree 600, that is, for each variable distinguished by the description position (represented by a line here). “A (2)” indicates that the variable a is an evaluation target, and there are two places where there is a possibility of a failure factor from the node. This numerical value becomes an evaluation score. In FIG. 7, illustration of some data such as nodes with empty evaluation data is omitted.

  Note that the evaluation points are not limited to the value of the number of places where there is a possibility of failure as described above, and various evaluation points can be considered. For example, the evaluation score may represent the degree of the possibility of the failure factor such as A, B, C,... Corresponding to the number of places where the failure factor may be possible. In this case, it is possible to adopt a method in which the evaluation score is A if there is one potential failure factor, and the evaluation score is B if there are two potential failure factors. One evaluation point may have a predetermined width, such that an evaluation point is A if there are one or two places, and an evaluation point is B if there are three or four places.

  The dependency between the two locations extracted by the detection unit 260 is recorded as “a (1)” in the category 1 column of a (line 104) and a (line 109). That is, the dependency relationship extracted by the detection unit 260 is recorded in the evaluation database 280 as data related to the dependency destination variable. At the time when step 340 is completed, only these two data are recorded in the evaluation data 700. Next, the evaluation score calculation unit 270 executes the processing flow of FIG. 4 with the variable tree 600 and the evaluation data 700 as inputs in step 350. x1 @ 104 has a @ 104 at the lower level, and a @ 104 has evaluation data “a (1)” in category 1. Since x1 @ 104 does not evaluate the variable a, the process proceeds from step 430 to step 440, and “a (1)” is entered in category 1 of the evaluation data 700. Similarly, “a (1)” is also entered in category 1 of x1 @ 016. In the variable tree 600, the process shown in FIG. 4 is not performed at x1 @ 104, which is a variable node with diagonal lines, and the evaluation data is empty. As a result, the evaluation data of x1 @ 012 is also emptied.

  Since there is a @ 109 below x2 @ 109 and x2 @ 109 has no evaluation for variable a, “a (1)” is entered in category 1 of evaluation data 700. Similarly, “a (1)” is also entered in the category 1 of x2 @ 012 and if @ 012. Below x @ 016 are x1 @ 016 and if @ 012. First, when the evaluation data of x1 @ 016 is acquired, there is evaluation data of “a (1)” in category 1, and there is no evaluation of variable a in x @ 016, so “a (1)” is in category 1. enter. Next, when the evaluation data of if @ 012 is acquired, there is still evaluation data of “a (1)” in category 1, but here, evaluation data for variable a already exists in category 1 of x @ 016. From step 430, the process proceeds to step 450, where “a (1)” of category 1 already recorded is cleared, and “a (1)” of if @ 012 is added, and “a (2)” is added to category 2. Is recorded. Above, the process of step 350 is complete | finished.

  In FIG. 7, evaluation data 710 indicates a method of recording evaluation data in a format different from the evaluation data 700. In the evaluation data 710, the dependency destination extracted by the detection unit 260 is recorded. Also in step 440 and step 450, the information extracted by the detection unit 260 is retained and recorded. For this reason, a @ 104 and a @ 109 are recorded in x @ 016 as the cause of category 2. Evaluation points are assigned by counting the number of variables recorded in each category. Since a @ 104 and a @ 109 each include themselves in category 1, it can be seen that they are locations of failure factors. In the format of the evaluation data 710, duplication of failure factors can be eliminated. Therefore, the process shown in FIG. 4 may be performed even on the already-exited node x1 @ 104. When implemented, “a @ 104” is placed in category 1 for x1 @ 012. In if @ 012, “a @ 104” and “a @ 109” are entered in category 1. At x @ 016, it is determined at step 450 that “a @ 104” of x1 @ 016 and “a @ 104” of if @ 012 are duplicated, and only one of them is recorded in category 2.

  FIG. 8 shows the contents displayed at step 360 by the display unit 290. The evaluation score table 800 is a summary of the contents of the evaluation data 700 or 710. x @ 016 indicates that the evaluation score of category 2 is 2, and a @ 104 and a @ 109 indicate that the evaluation score of category 1 is 1. It should be noted that the evaluation score table 800 displays only the nodes having different evaluation scores from the lower nodes among the nodes of the variable tree 600. Evaluation points are calculated in the same manner using other parts of the program or x @ 016 dependency destination as the root of the variable dependency relationship, and the same display as the evaluation score table 800 is performed in the descending order of evaluation points, so that the user can verify Can be prioritized. In addition, since the evaluation points are displayed separately from the categories 1 and 2, the user can recognize whether the cause of the failure is data competition or not, and can be used as reference information when selecting the verification target. it can. For example, when there is a policy of preferentially verifying data competition, a location with a high category 2 value may be selected. However, the evaluation score may be displayed as a value obtained by adding the numerical values of categories 1 and 2. Moreover, when the priority of a specific category is high, only the evaluation score regarding the category may be displayed.

  Although the evaluation score is displayed for each variable in the evaluation score table 800, the display unit 290 uses the source code 200 as an input and displays the code of the location where the variable is described together with the evaluation score using the description position information of the variable. May be.

  The variable tree 810 is a graph displayed by assigning numerical values of categories 1 and 2 of the evaluation data 700 to each node of the variable tree 600. Among the numerical values appended to each node, the left side indicates the category 1 and the right side indicates the category 2 numerical value. With such a display, the user can visually recognize the relationship between the variable tree and the distribution of failure factors.

  When the user designates an extraction range on the variable tree for the code extraction unit 230 of the verification model generation program 210, the display such as the variable tree 810 displays the priority range to be verified, and the user considers the extraction range. Make it easier to do. If all the lower nodes are extracted from the variable tree, the amount of code extraction may become enormous. For this reason, if the extraction of lower nodes can be interrupted, the amount of code extraction can be suppressed and the size of the verification model can be reduced. The depth of extracting the lower node of the variable tree affects the evaluation score of the upper node. The user can appropriately select the extraction range of the lower nodes by observing the evaluation points while extracting the lower nodes step by step.

  The code extraction unit 230 can also acquire evaluation points from the evaluation database 280 and automatically select a verification range. For example, for each sub-node of the root node of the variable tree 600, by extracting a code using a sub-tree whose root is the node having the highest evaluation score, verification including a portion having a high possibility of a failure while dividing the verification target A model can be generated. Or, extract the variable tree one by one for the variables described in the program, observe the evaluation points, execute code extraction and conversion to the verification model for the variables whose evaluation points exceed the specified threshold Also good.

  The function tree 820 aggregates the functions belonging to each node of the variable tree 810 as a unit, and expresses the functions as nodes. Similar to the variable tree 810, the evaluation points of the evaluation data 700 are assigned to the function nodes, but the numerical value of the variable node having the highest evaluation point in one function is assigned. Since the display of the function tree 820 is simpler than that of the variable tree 810, it is easy for the user to recognize. The user may use the variable tree 810 when the user wants to grasp the evaluation result in detail, or the function tree 820 when he / she wants to grasp the summary.

  Note that the evaluation point information as shown in FIG. 8 is information that can be used not only for model checking but also for prioritization of objects in the overall software verification method and for extraction of a potential defect.

  By the way, in FIG. 8, evaluation points are displayed for all portions having a variable dependency in the program, but the present invention is not limited to this. For example, an evaluation score may not be displayed at a point where the evaluation score is 0, or only a portion where the evaluation score is a certain level or more (for example, 2 points or more) may be displayed. Furthermore, only a part related to a specific variable that is likely to cause a failure among a plurality of variables may be displayed. For example, in the example of FIG. Conceivable. FIG. 9 shows source code 910 in which the source code 510 is corrected by grasping the cause of the malfunction based on the evaluation result of FIG. 8 and the result of the verification model 240 generated from the evaluation result and verification execution. 3 shows the variable tree 920 in which the processing of FIG. 3 is executed for 910, 520, and 530 and the evaluation results are displayed in the same manner as the variable tree 810. In the source code 910, the setting to execute the function input by interruption is stopped, and the function code is corrected to be called at the beginning of the function func. As a result, the value of the variable a does not change during the subsequent execution of the function func. With this modification, all the evaluation points are set to 0 in the variable tree 920, and the user can recognize that the failure factor has been removed.

  As described above, according to the source code verification system according to the present embodiment, it is possible to satisfactorily detect a timing-dependent defect and appropriately provide useful information to the verifier. Specifically, the verifier verifies the possibility of failure for each location to be verified, assigns an evaluation score based on the evaluation to each location to be verified, and displays the evaluation score. The priority order of the objects can be easily grasped. Therefore, the verifier can determine the priority of the execution of verification for each part of the program from the evaluation points, and can perform cost-effective verification in a limited amount of manpower and time.

  DESCRIPTION OF SYMBOLS 120 ... Source code evaluation program, 140 ... Display apparatus, 200 ... Source code, 210 ... Verification model generation program, 220 ... Code analysis part, 225 ... Variable dependence extraction part, 230 ... Code extraction part, 235 ... Conversion part, 240 ... Verification model, 250 ... Input unit, 260 ... Detection unit, 270 ... Evaluation point calculation unit, 280 ... Evaluation database, 290 ... Display unit

Claims (5)

A failure factor detection means for detecting a location having a variable dependency across different execution units as a possible failure factor based on variable dependency data relating to the dependency of a variable included in the program;
Based on the variable dependency relationship, an evaluation score calculating means for calculating an evaluation score of the possibility of malfunction related to the location;
For example Bei and an evaluation point display means for displaying the evaluation point,
The variable dependency relationship data input to the evaluation score calculation means is in a tree format, and the evaluation score calculation means counts the detection results by the failure factor detection means at an upper node of the variable dependency relationship data. A source code verification system characterized by calculating points . A failure factor detection means for detecting a location having a variable dependency across different execution units as a possible failure factor based on variable dependency data relating to the dependency of a variable included in the program;
Based on the variable dependency relationship, an evaluation score calculating means for calculating an evaluation score of the possibility of malfunction related to the location;
Evaluation point display means for displaying the evaluation point,
The evaluation score display means displays the location of the program to which the evaluation score is attached and the evaluation score in association with each other, and displays them in the order of the evaluation score . A failure factor detection means for detecting a location having a variable dependency across different execution units as a possible failure factor based on variable dependency data relating to the dependency of a variable included in the program;
Based on the variable dependency relationship, an evaluation score calculating means for calculating an evaluation score of the possibility of malfunction related to the location;
Evaluation point display means for displaying the evaluation point,
The evaluation point display means displays the variable to which the evaluation point is attached and the evaluation point in association with each other in the graph of the variable dependency relationship data . The said evaluation score calculation means distinguishes and calculates the evaluation score which shows the possibility of data competition, and the evaluation score which shows the other possibility , The Claim 1 thru | or 3 characterized by the above-mentioned. Source code verification system. A code analysis unit that analyzes variable dependency data from the source code of the program;
A variable dependency extraction unit that extracts a portion related to a user-specified variable from the variable dependency data;
A code extraction unit for extracting a code corresponding to the extracted dependency data from the source code;
A failure factor detection means for detecting a possible defect factor from a variable dependency across different execution units based on the variable dependency relationship data;
An evaluation score calculating means for calculating an evaluation score of the possibility of malfunction related to the location based on the variable dependency relationship;
The code extraction unit selects a code extraction range based on the evaluation points, and is a source code verification system.