Program error checking method and system

Abstract

This invention provides a method and system for program error checking. The method includes: acquiring the source code to be checked; constructing a static value flow graph corresponding to the source code, the static value flow graph containing multiple nodes and edges between nodes; processing each node in the static value flow graph using a graph neural network model, outputting a first confidence level and error type for each node, the first confidence level representing the probability that each node has a program error; for target nodes with a first confidence level less than a preset threshold, calling a rule engine for verification to obtain verification results; and determining the error detection results in the source code to be checked based on the first confidence level and the verification results. This invention achieves the integration of cross-process data flow analysis and intelligent error pattern recognition, and through a dual-engine collaborative verification mechanism, it balances the ability to cover unknown errors with the reliability of detection results, effectively reducing the false positive rate and the false negative rate.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and in particular to a method and system for checking program errors. Background Technology

[0002] Currently, automated error checking for system-level programming languages ​​mainly relies on traditional static analysis tools, pure machine learning solutions, or symbolic execution tools, but all of these methods have significant drawbacks. Traditional static analysis tools (such as ClangStatic Analyzer) lack the ability to accurately trace program value flow, struggle to handle cross-function pointer and complex heap memory operations, and have a high false positive rate; pure machine learning solutions (such as DeepBugs) do not explicitly model the program's data flow and control flow dependencies, cannot trace cross-function paths, and have a high false negative rate; symbolic execution tools (such as KLEE) face the problem of path explosion, with a large number of paths when analyzing medium-sized code, making it difficult to deploy in industrial-scale projects. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a program error checking method and system that can perform cross-process data flow tracing and intelligent identification of unknown error modes in source code.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for checking program errors, characterized in that it includes: Obtain the source code to be inspected, and construct a static value flow graph corresponding to the source code to be inspected. The static value flow graph contains multiple nodes and edges between the nodes. The nodes in the static value flow graph are processed by a graph neural network model, and the first confidence level and error type corresponding to each node are output. The first confidence level is used to represent the probability that each node has a program error. For target nodes whose first confidence level is less than a preset threshold, the rule engine is invoked for verification to obtain the verification result. Based on the first confidence level and the verification result, the error detection result in the source code to be inspected is determined.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A program error checking system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the various steps of the program error checking method described above.

[0006] The beneficial effects of this invention are as follows: By constructing a static value flow graph of the source code to be inspected, the dependencies between program variables are uniformly represented by the graph structure, enabling cross-process data flow tracing to be performed on a unified graph model, avoiding the problem of difficulty in associating cross-function paths; the static value flow graph is input into a graph neural network model for processing, utilizing the feature extraction capability of the graph neural network for graph structure data to automatically capture the dependencies between nodes, achieving intelligent identification of unknown error patterns without the need for manual definition of error rules; for target nodes with a first confidence level less than a preset threshold, the rule engine is invoked for verification, and the deterministic verification logic of the rule engine performs secondary verification on nodes with questionable first confidence levels in the neural network detection results, solving the problem of lack of interpretability in the detection results of pure machine learning solutions; the error detection result is determined comprehensively based on the first confidence level and the verification result, realizing the collaborative judgment of neural network intelligent detection and traditional rule deterministic verification, taking into account both the coverage capability of unknown error patterns and the verification accuracy of known error types, effectively reducing the false alarm rate and the false negative rate, and improving the accuracy and reliability of program error checking. Attached Figure Description

[0007] Figure 1 This is a flowchart of a program error checking method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the application architecture of the program error checking method provided in the embodiments of the present invention; Figure 3 A flowchart of the SVFG build engine provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a graph neural network model provided in an embodiment of the present invention; Figure 5 A flowchart illustrating the dual-engine collaborative determination mechanism provided in this embodiment of the invention; Figure 6 A timing diagram of the function pointer cross-function resolution process provided in an embodiment of the present invention; Figure 7 A schematic diagram of the folding process of the loop structure provided in an embodiment of the present invention; Figure 8 A timing diagram of the array out-of-bounds detection process provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of a program error checking system according to an embodiment of the present invention. Detailed Implementation

[0008] Definitions: Table 1

[0009] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0010] In existing technologies, error checking for system-level programming languages ​​primarily relies on traditional static analysis tools, pure machine learning solutions, or symbolic execution tools. Traditional static analysis tools, based on abstract syntax trees or control flow graphs for pattern matching, lack the ability to accurately trace program value flow, struggle to handle cross-function pointers and complex heap memory operations, resulting in a high false positive rate. Pure machine learning solutions treat source code as text or syntax tree fragments, failing to explicitly model data flow dependencies and unable to distinguish the order of nodes and dependency levels, leading to a high false negative rate in complex code scenarios. Symbolic execution tools, on the other hand, face the problem of path explosion; the number of paths increases dramatically when analyzing medium-sized code, making practical deployment in industrial-scale projects difficult.

[0011] To at least address the aforementioned issues, this method involves acquiring the source code to be inspected and constructing a corresponding static value flow graph. This graph structure uniformly represents the dependencies between program variables. The static value flow graph is then input into a graph neural network model for processing. The neural network captures the dependencies between nodes and outputs the probability of program errors at each node and the corresponding error type. For target nodes with probabilities below a preset threshold, a rule engine is invoked for deterministic verification. Finally, the error detection result is determined by combining the probabilities and verification results. This approach achieves the fusion of cross-process data flow analysis and intelligent pattern recognition, balancing the coverage of unknown error types with the verification accuracy of known error types. This effectively reduces false positive and false negative rates, improving the accuracy and reliability of program error checking.

[0012] The following describes a program error checking method of the present invention in detail. Please refer to [link / reference]. Figure 1 The method 100 includes steps 110 to 140.

[0013] Step 110: Obtain the source code to be inspected and construct the static value flow graph corresponding to the source code to be inspected. The static value flow graph contains multiple nodes and edges between nodes.

[0014] For example, the system obtains the source code to be inspected, creates corresponding nodes for each program value in the source code, and parses the assignment and reference relationships between program values ​​to construct edges between nodes, thereby constructing a static value flow graph to represent the program data flow links.

[0015] Static Value Flow Graph (SVFG) is an intermediate representation for program analysis that models data flow relationships within a program using a graph structure. Specifically, an SVFG contains multiple nodes and edges between them: nodes represent program values ​​(e.g., variables, heap memory objects, function pointers), and edges represent dependencies between these values ​​(e.g., the definition-use relationship between an rvalue and a lvalue in an assignment statement, parameter passing relationships in function calls). Through SVFG, data flow operations such as assignment, referencing, and passing, which were originally scattered throughout the program, are organized into a unified graph structure, enabling cross-process (i.e., cross function call boundaries) data flow tracing to be performed on the graph model.

[0016] Existing static value flow graph construction methods (such as those in the SVF framework) primarily focus on data flow relationships within a process. For function pointer resolution across processes, they typically use alias sets for indirect association, leading to ambiguous data flow paths. This invention optimizes SVFG construction by performing cross-function resolution of function pointers to create direct edges from the call point to the target function, and by folding loop structures to generate summary nodes, thereby improving the accuracy and compactness of the SVFG.

[0017] Step 120: Process each node in the static value flow graph using a graph neural network model, and output the first confidence level and error type corresponding to each node. The first confidence level is used to represent the probability that each node has a program error.

[0018] For example, the system inputs the constructed static value flow graph into a pre-trained graph neural network model. The model extracts the feature information of the nodes and finally classifies each node, outputting the error type corresponding to each node (such as memory leak, array out of bounds, null pointer dereference, etc.) and the first confidence level of each node having a program error.

[0019] Step 130: For target nodes with a first confidence level less than a preset threshold, call the rule engine to perform verification and obtain the verification result.

[0020] For example, the system compares the first confidence level of each node with a preset threshold. When the first confidence level of a node is lower than the preset threshold, it indicates that the node is not trustworthy enough in the neural network detection. At this time, the system calls the rule engine to perform deterministic verification on the target node and performs secondary verification through preset verification rules (such as resource lifecycle tracking, comparison of declared size and access offset, etc.) to obtain the verification result.

[0021] Step 140: Based on the first confidence level and the verification results, determine the error detection results in the source code to be inspected.

[0022] For example, the system combines the first confidence level of each node with the verification results returned by the rule engine to make a final judgment and determine the error detection results in the source code to be checked.

[0023] As described above, by constructing a static value flow graph of the source code to be inspected, the dependencies between program variables are uniformly represented by the graph structure, enabling cross-process data flow tracing to be performed on a unified graph model, avoiding the problem of difficulty in associating cross-function paths. The graph neural network model processes each node in the static value flow graph, automatically capturing the dependencies between nodes and outputting the first confidence level and error type for each node, achieving intelligent identification of unknown error patterns without the need for manual definition of error rules. By calling the rule engine to verify target nodes with a first confidence level less than a preset threshold, the deterministic verification logic of the rule engine performs secondary verification on nodes with questionable confidence levels in the neural network detection results, solving the problem of lack of interpretability in pure machine learning detection results. The error detection result is determined comprehensively based on the first confidence level and the verification result, realizing the collaborative judgment of intelligent neural network detection and traditional rule-based deterministic verification, balancing the coverage of unknown error patterns and the verification accuracy of known error types, effectively reducing false positives and false negatives, and improving the accuracy and reliability of program error checking.

[0024] In one alternative implementation, step 110 constructs a static value flow graph corresponding to the source code to be inspected, including steps 111 and 112.

[0025] Step 111: Compile the source code to be checked to generate an intermediate representation.

[0026] For example, the system converts the source code to be inspected into an LLVM intermediate representation through the compiler front end. This intermediate representation preserves the control flow structure and data flow information of the source code, providing a unified intermediate format for subsequent static value flow graph construction.

[0027] Step 112: Analyze the data flow of the intermediate representation to obtain the analysis results, and construct a static value flow graph based on the analysis results.

[0028] For example, the system performs intra-process and inter-process data flow analysis on the intermediate representation, extracts the assignment, reference, and pass relationships of each program value in the program, creates a corresponding node for each program value based on the analysis results, and establishes edges between nodes with assignment-reference relationships, thereby constructing a complete static value flow graph.

[0029] As described above, by compiling the source code into an intermediate representation and performing data flow analysis on the intermediate representation, the automated construction of a static value flow graph from the source code is realized. This provides a structured graph data foundation for subsequent graph neural network processing and rule engine verification, ensuring the complete preservation and accurate representation of cross-process data flow dependencies in the static value flow graph.

[0030] In an alternative implementation, step 110 constructs a static value flow graph corresponding to the source code to be inspected, including steps 113 and 114.

[0031] Step 113: Create corresponding nodes for each program value in the source code to be inspected. Program values ​​include at least heap memory objects and function pointers.

[0032] For example, the system identifies each program value (including heap memory objects, function pointers, global variables, etc.) in the source code to be inspected, and creates a unique corresponding node in the static value flow graph for each program value. This node is used to carry the feature information of the program value in subsequent analysis, and the edges between nodes carry the dependency relationship between the program value and other program values.

[0033] Step 114: Perform cross-function parsing on the node corresponding to the function pointer and create a direct connection from the node corresponding to the function pointer to the node corresponding to the target function. The direct connection is used to represent the dependency relationship corresponding to the function pointer call relationship.

[0034] For example, the system performs cross-function resolution on the node corresponding to the function pointer, extracts the symbolic address of the function pointer to determine the target function actually called, and creates a direct connection between the node corresponding to the function pointer and the node corresponding to the target function. This direct connection skips the traditional alias analysis step and is used to accurately represent the dependency relationship corresponding to the function pointer call relationship. The function pointer call relationship refers to an indirect call relationship in which a function pointer variable dynamically points to and calls the target function during program runtime. This relationship determines the function body actually executed at the call point and is a key link in cross-process data flow tracing. In system-level code (such as operating system kernel and drivers), function pointers are widely used in callback mechanisms, device operation interfaces, and other scenarios. Accurately resolving the function pointer call relationship is crucial for tracing the flow of data across function paths, discovering abnormal behaviors such as memory leaks caused by incorrect function pointer pointers, and null pointer dereferences.

[0035] As described above, by creating corresponding nodes for each program value in the source code to be inspected and establishing direct connections between function pointers and the nodes corresponding to the target functions they actually call, the precise binding of function pointer call relationships is achieved. This avoids the path ambiguity problem caused by the indirect multi-hop path association of target functions in traditional alias analysis, making cross-process data flow tracing more accurate and effectively reducing false negatives and false positives caused by inaccurate pointer resolution.

[0036] In one alternative implementation, after step 110 constructs the static value flow graph corresponding to the source code to be inspected, steps 150 to 152 are further included.

[0037] Step 150: Identify loop structures in the static value flow graph.

[0038] For example, the system traverses each node and the edge between nodes in the static value flow graph, and identifies the loop structure composed of multiple nodes and edges. The loop structure includes loop condition judgment nodes, operation nodes within the loop body, and update nodes for loop variables.

[0039] Step 151: Identify loop structures in the static value flow graph.

[0040] For example, the system calculates the maximum number of iterations for the identified loop structure and creates a summary node to represent the execution semantics of the loop structure as a whole. The summary node summarizes the data flow and dependencies in the loop structure.

[0041] Step 152: Replace the loop structure with the summarized node to obtain the updated static value flow graph.

[0042] For example, the system will delete all nodes and edges in the identified cycle structure and insert the generated summary node into the original position of the cycle structure, so that the summary node represents the entire cycle structure to complete the update of the static value flow graph.

[0043] As described above, by identifying the loop structure in the static value flow graph and generating the corresponding summary node, and replacing the original loop structure with the summary node to complete the update of the static value flow graph, the complex loop structure can be compressed into a single summary node, which greatly simplifies the size of the static value flow graph, reduces the computational complexity of subsequent graph neural network processing, and thus improves the overall efficiency of program error checking.

[0044] In one optional implementation, step 120 processes each node in the static value flow graph using a graph neural network model and outputs the first confidence level and error type corresponding to each node, including steps 121 to 125.

[0045] Step 121: Perform graph convolution processing on each node in the static value flow graph through the graph convolution layer in the graph neural network model to obtain the first intermediate feature.

[0046] For example, the system takes the feature vectors of each node as input, performs convolution operations on the features of each node and its neighboring nodes through graph convolution layers, aggregates the graph structure information of the local neighborhood, and obtains the first intermediate feature.

[0047] Step 122: The first intermediate feature is processed by gated convolution in the graph neural network model to obtain the second intermediate feature.

[0048] For example, the system performs gated convolution processing on the first intermediate feature through a gated convolutional layer, uses the gating mechanism to control the transmission of cross-process data flow information, captures the temporal dependencies on the cross-function call path, and obtains the second intermediate feature.

[0049] Step 123: The second intermediate feature is weighted by the attention layer in the graph neural network model to obtain the third intermediate feature.

[0050] For example, the system performs attention-weighted processing on the second intermediate feature through an attention layer, focusing on the node features on the critical path related to program errors, to obtain the third intermediate feature.

[0051] Step 124: Perform error detection processing on each node based on the third intermediate feature, and output the first confidence score corresponding to each node.

[0052] For example, the system performs error detection binary classification on each node based on the third intermediate feature to determine whether each node has a program error, and outputs the first confidence level of each node having a program error.

[0053] Step 125: Classify each node according to the third intermediate feature, and output the error type corresponding to each node and the second confidence level corresponding to the error type.

[0054] For example, the system performs multi-label classification on each node with program errors based on the third intermediate feature, determines the specific error type of each node, and outputs the second confidence level corresponding to each error type.

[0055] As described above, by aggregating local neighborhood information of nodes through graph convolutional layers to capture graph structure features, by modeling the temporal dependencies of cross-process calls through gated convolutional layers to solve the problem of difficult correlation of cross-function paths, by focusing on critical paths related to program errors through attention layers to highlight vulnerability-sensitive areas, by outputting the first confidence level through error detection processing, and by outputting the error type and second confidence level through classification processing, the system achieves hierarchical feature extraction and accurate classification of each node in the static value flow graph, effectively improving the ability to identify and detect unknown error patterns.

[0056] In one alternative implementation, step 123 includes step 1231.

[0057] Step 1231: The second intermediate feature is weighted by a preset number of attention branches in the attention layer to obtain the third intermediate feature.

[0058] For example, the system sets a preset number of parallel attention branches in the attention layer. Each attention branch independently calculates the attention weight for the second intermediate feature. The weighted results of each branch are then aggregated to obtain the third intermediate feature.

[0059] As described above, by setting multiple parallel attention branches to weight the node features, the model can focus on the critical paths related to program errors from different feature subspaces, capture vulnerability-sensitive features under different dimensions, and improve the model's ability to identify complex error patterns and its detection robustness.

[0060] In one optional implementation, step 120 processes each node in the static value flow graph using a graph neural network model and outputs the first confidence level and error type corresponding to each node, including steps 1201 to 1203.

[0061] Step 1201: Classify each node in the static value flow graph using a graph neural network model, and output the type confidence of each error type corresponding to each node.

[0062] For example, the system performs multi-label classification on each node through the classification layer in the graph neural network model, predicts the probability of each node belonging to each preset error type, and outputs the type confidence of each error type corresponding to each node.

[0063] Step 1202: Based on the type confidence of each error type corresponding to each node, determine the first confidence level of each node and the judgment result of whether there is a program error in each node.

[0064] For example, the system determines the overall probability of whether a program error exists in each node by comprehensively judging the type confidence of each error type corresponding to each node as the first confidence level, and determines the judgment result of whether a program error exists in each node based on whether the first confidence level exceeds the threshold.

[0065] Step 1203: Based on the judgment result, output the error type corresponding to each node with a program error.

[0066] For example, for each node whose judgment result indicates the existence of a program error, the system selects the error type with the highest type confidence as the final error type for that node and outputs it.

[0067] As described above, by using a graph neural network model to perform multi-label classification on each node and outputting the type confidence of each error type, and then comprehensively determining whether there is a program error in each node based on the type confidence, the error type corresponding to each node with an error is finally output. This achieves a progressive recognition from coarse-grained error existence detection to fine-grained error type classification, improving the accuracy and interpretability of error detection.

[0068] In one alternative implementation, step 130 includes steps 131 and 132.

[0069] Step 131: When the first confidence level is less than the preset threshold, the rule engine is invoked to verify the target node and obtain the verification result.

[0070] For example, the system compares the first confidence level of the target node with a preset threshold. When the first confidence level is less than the preset threshold, it indicates that the credibility of the neural network detection result is insufficient. The system calls the rule engine to match the corresponding verification rule according to the node type of the target node to perform deterministic verification of the target node and outputs the verification result.

[0071] Step 132: When the first confidence level is greater than or equal to the preset threshold, determine the error detection result of the target node based on the first confidence level.

[0072] For example, the system compares the first confidence level of the target node with a preset threshold. When the first confidence level is greater than or equal to the preset threshold, it indicates that the neural network detection result is highly reliable. The system directly determines the erroneous detection result of the target node based on the first confidence level without calling the rule engine for secondary verification.

[0073] As described above, by comparing the first confidence level of each node with a preset threshold, when the first confidence level is lower than the threshold, the rule engine is invoked for deterministic verification; when the first confidence level is higher than or equal to the threshold, the neural network detection result is directly adopted. This achieves dynamic collaboration between neural network intelligent detection and traditional rule-based deterministic verification, ensuring both the detection efficiency of high-confidence nodes and the verification accuracy of low-confidence nodes, effectively balancing detection efficiency and detection reliability.

[0074] In an optional implementation, before step 120 processes each node in the static value flow graph using a graph neural network model and outputs the first confidence level and error type corresponding to each node, steps 160 and 161 are also included.

[0075] Step 160: Extract the static semantic features and dynamic features of the data flow for each node.

[0076] For example, the system extracts the static semantic features of each node (such as node type, opcode category, etc.) and the dynamic features of the data flow of each node (such as variable value range constraints, data pollution markers, etc.) as the raw input for node feature encoding.

[0077] Step 161: Merge static semantic features and data flow dynamic features to generate feature vectors for each node, and input the feature vectors of each node into the graph neural network model.

[0078] For example, the system merges the extracted static semantic features and data flow dynamic features of each node into a complete feature vector, and uses this feature vector as the initial feature input to the graph neural network model for subsequent layers of the network to perform feature extraction and classification.

[0079] As described above, by extracting the static semantic features and dynamic data flow features of each node and merging them to generate feature vectors for each node, and then inputting these feature vectors into the graph neural network model, the joint encoding of static semantic information and dynamic data flow information is achieved. This provides the graph neural network with rich node feature information, improving the model's ability to understand program semantics and the accuracy of error detection.

[0080] Please refer to Figure 2 The present invention can apply the above solution to the program error checking scenario of system-level programming languages. Taking the automated defect detection of operating system kernel or embedded system code developed by system-level languages ​​such as C / C++ as an example, the entire interaction process involves the coordinated operation of three core modules: input layer, core analysis layer and result processing layer, specifically including S201 to S204.

[0081] S201. The input layer obtains the C / C++ source code to be inspected, which serves as the raw input for the entire inspection process. This source code contains the program logic to be analyzed, function call relationships, and data flow operations. This is equivalent to step 110 above.

[0082] S202, the LLVM IR generator compiles the input source code to generate the corresponding LLVM intermediate representation. This intermediate representation preserves the control flow structure and data flow information of the source code, providing a unified intermediate format for subsequent static value flow graph construction. This is equivalent to steps 111 to 112 above.

[0083] The S203 and SVFG build engines perform data flow analysis on the intermediate representation and construct a static value flow graph based on the analysis results. During the construction process, corresponding nodes are created for each program value (including heap memory objects and function pointers) in the source code to be examined, and cross-function resolution is performed on function pointers to create direct edges from the call point to the target function, so as to accurately represent the dependencies corresponding to the function pointer call relationships. At the same time, the loop structure in the static value flow graph is identified, and the corresponding summary node is generated to replace the loop structure, thus completing the update of the static value flow graph. This is equivalent to steps 113 to 114 and steps 150 to 152 above.

[0084] S204. The dual-engine detection system processes the static value flow graph. The GNN intelligent detection engine processes each node in the static value flow graph using a graph neural network model, outputting the first confidence level and error type for each node. The traditional rule engine performs deterministic verification on target nodes with a first confidence level less than a preset threshold, obtaining the verification result. The hierarchical verification system determines the error detection result based on the first confidence level and the verification result. This is equivalent to steps 120 to 125 and steps 130 to 132 above.

[0085] S205. The error pattern matching module performs collaborative matching on the output results of the dual-engine detection system to determine the final error type and location. The error report output module generates an error detection report based on the matching results. The report includes the error type, error location, and corresponding confidence information for developers to review and fix. This is equivalent to step 140 above.

[0086] Through the above steps, this invention provides a complete automated detection infrastructure for program error checking in system-level programming languages ​​by automatically constructing static value flow graphs, intelligently detecting errors using graph neural network models, deterministically verifying errors using rule engines, and comprehensively judging errors using a hierarchical verification system. Specifically, C / C++ source code is compiled into an LLVM intermediate representation, providing a unified intermediate format for static analysis; cross-process data flow dependencies are accurately represented through static value flow graphs, avoiding the difficulty of associating cross-function paths in traditional methods; program errors are intelligently identified through graph neural network models, eliminating the need for manually defined error rules and covering unknown error types; low-confidence nodes undergo secondary deterministic verification through a rule engine, solving the problem of lack of interpretability and reliable verification in pure machine learning solutions; and detection results are comprehensively output through dual-engine collaborative judgment, balancing the coverage of unknown error patterns with the verification accuracy of known error types. This effectively solves the technical problems of insufficient accuracy in traditional static analysis tools, high false negative rates in pure machine learning solutions, and path explosion issues faced by symbolic execution tools in existing technologies, improving the automation level, detection accuracy, and result reliability of program error checking.

[0087] Please refer to Figure 3 The SVFG build engine of the present invention converts the source code to be inspected into a structured static value flow graph through the following steps, specifically including S301 to S306.

[0088] S301. Obtain the LLVM intermediate representation code. The SVFG build engine obtains the generated LLVM intermediate representation from the preprocessing layer. This intermediate representation contains the control flow graph, function call relationships, and variable definition-usage information of the source code to be inspected, serving as a unified input for subsequent data flow analysis. This is equivalent to steps 111 to 112 above.

[0089] S302. Perform pointer analysis on the intermediate representation. The system analyzes the pointers of all pointer variables in the intermediate representation, calculates the set of memory objects that each pointer variable may point to at various points in the program, and obtains pointer pointing information, providing a foundation for subsequent inter-process data flow analysis and function pointer resolution. This is equivalent to heap memory object identification in step 113 above.

[0090] S303. Perform inter-procedural data flow analysis based on pointer analysis results. Based on the pointer analysis results, the system performs cross-procedural data flow propagation analysis along function call relationships, tracing the path of program values ​​passed between functions, identifying assignment-reference relationships across function call chains, and generating inter-procedural data flow information. This is equivalent to step 114 above.

[0091] S304. Explicitly model heap memory objects during the analysis process. The system creates corresponding heap memory object nodes for dynamic memory allocation operations (such as malloc, new, etc.) in the program, incorporates the heap memory objects into the node system of the static value flow graph, and establishes data flow associations between the allocation points, usage points, and release points of heap memory objects to ensure complete tracing of heap memory operations. This is equivalent to creating corresponding nodes for heap memory objects in step 113 above.

[0092] S305. Fold the loop structures in the analysis results. The system identifies the loop structures in the data flow graph, compresses the iterative logic inside the loop body into summary nodes, and uses a single summary node to represent the data flow semantics of the entire loop structure, thus completing the folding optimization of the loop structure. This is equivalent to steps 150 to 152 above.

[0093] S306. Generate a complete SVFG graph based on the above analysis results. The system integrates the inter-process data flow analysis results, heap memory object nodes, and summary nodes after cyclic folding to construct a complete static value flow graph. This graph contains multiple nodes and edges between them. Nodes represent program values, and edges represent dependencies between program values, providing structured graph data input for subsequent graph neural network processing. This is equivalent to the integrated output of the static value flow graphs constructed in steps 113 to 114 and step 152 above.

[0094] As described above, pointer analysis obtains pointer information, inter-process data flow analysis traces the path of program values ​​between functions, explicit modeling of heap memory objects ensures complete tracking of dynamic memory operations, and loop structure folding compresses loop bodies into summary nodes to simplify the graph scale, ultimately generating a structured static value flow graph. This provides a complete graph data foundation for subsequent graph neural network processing and rule engine verification, ensuring accurate preservation and efficient representation of cross-process data flow dependencies.

[0095] Please refer to Figure 4 The graph neural network model of the present invention processes each node in the static value flow graph through the following steps, specifically including S401 to S406.

[0096] S401. Obtain each node in the static value flow graph as model input. The system obtains the complete static value flow graph from the SVFG building engine and uses each node in the graph as the raw input to the graph neural network model. Each node corresponds to a program value in the source code. This is equivalent to the process of inputting the static value flow graph into the graph neural network model in step 120 above.

[0097] S402. Generate a 128-dimensional feature vector for each node. The system extracts the static semantic features (including node type, opcode category, etc.) and data flow dynamic features (including value range constraints, data pollution markers, etc.) of each node, and merges the two types of features into a 128-dimensional feature vector as the initial feature representation of each node. This is equivalent to steps 160 to 161 above.

[0098] S403. Perform graph convolution processing on the feature vector using a GCN graph convolutional layer. The system performs graph convolution operations on each node in the static value flow graph through the graph convolutional layer in the graph neural network model, aggregating the feature information of each node and its neighboring nodes, capturing the local neighborhood structure features of the nodes, and obtaining the first intermediate feature. This is equivalent to step 121 above.

[0099] S404. The first intermediate feature is processed by gated convolution through a gated graph convolutional layer. The system processes the first intermediate feature by gated convolution through a gated graph convolutional layer, using a gating mechanism to control the transmission of cross-process data flow information, capturing the temporal dependencies on the cross-function call path, and obtaining the second intermediate feature. This is equivalent to step 122 above.

[0100] S405. The second intermediate feature is weighted using a multi-head attention mechanism. The system weights the second intermediate feature using a preset number of attention branches in the multi-head attention layer, enabling the model to focus on the critical paths related to program errors from multiple feature subspaces, thus obtaining the third intermediate feature. This is equivalent to steps 123 to 1231 above.

[0101] S406. Classify each node into 8 error categories based on the third intermediate feature. The system performs error detection and classification on each node based on the third intermediate feature. First, it outputs the first confidence level of whether each node has a program error. Then, for nodes with program errors, it outputs the corresponding error type (including memory leak, array out-of-bounds, null pointer dereference, free after use, integer overflow, command injection, format string vulnerability, etc., totaling 8 categories) and the second confidence level corresponding to each error type. This is equivalent to steps 124 to 125 above.

[0102] As described above, by generating 128-dimensional feature vectors that integrate static semantics and dynamic features of data flow for each node, aggregating local neighborhood information through graph convolutional layers to capture graph structure features, modeling the temporal dependencies of cross-process calls through gated graph convolutional layers to solve the problem of difficult correlation of cross-function paths, focusing on the critical paths related to program errors from multiple feature subspaces through a multi-head attention mechanism, and finally outputting the error detection confidence and specific error type of each node through 8 types of error classification, the system achieves hierarchical feature extraction and accurate classification of each node in the static value flow graph, effectively improving the ability to identify and detect unknown error patterns.

[0103] Please refer to Figure 5 The dual-engine collaborative judgment mechanism of the present invention comprehensively judges the GNN detection results and the rule engine verification results through the following steps, specifically including S501 to S504.

[0104] S501. Obtain GNN detection results. The system receives the first confidence score and error type corresponding to each node output by the graph neural network model, and uses the first confidence score as the initial basis for dual-engine collaborative judgment. This is equivalent to the process of outputting the first confidence score and error type corresponding to each node in step 120 above.

[0105] S502. Perform hierarchical and triage processing based on the first confidence level. The system compares the first confidence level of each node with a preset threshold (e.g., 0.8). When the first confidence level is greater than 0.8, it indicates that the neural network detection result has high credibility, and the node is directly confirmed to be faulty, proceeding to S503 to output the final error result. When the first confidence level is between 0.5 and 0.8, it indicates that the detection result has insufficient credibility, proceeding to S504 to call the rule engine for secondary verification. When the first confidence level is less than 0.5, it indicates that the node is less likely to be faulty, and it is directly marked as a safe node, without further processing. This is equivalent to steps 130 to 132 above.

[0106] S503. Direct Error Confirmation. For target nodes with a first confidence level higher than a preset threshold (e.g., 0.8), the system directly confirms the error detection result based on the first confidence level and the error type, without needing to call the rule engine for secondary verification, and outputs the final error result. This is equivalent to the process in step 132 above where the error detection result is determined based on the first confidence level when it is greater than or equal to the preset threshold.

[0107] S504. Call the rule engine for secondary verification. For target nodes with a first confidence level between a preset low-to-medium threshold and a preset high threshold (e.g., 0.5 to 0.8), the system calls the rule engine to perform deterministic verification based on the node type of the target node, matching the corresponding verification rules. When the rule engine verification passes, the node is confirmed to have an error; when the rule engine verification fails, the node is marked as a suspicious node or the error is excluded, and the verification result of the rule engine is output. This is equivalent to the process in step 131 above, where the rule engine is called to verify the target node and obtain the verification result, and the process in step 140, where the error detection result is determined by combining the first confidence level and the verification result.

[0108] As described above, by performing hierarchical and tiered processing based on the first confidence level in the GNN detection results, high-confidence nodes are directly confirmed as errors to ensure detection efficiency, while nodes with questionable confidence levels are verified by calling the rule engine for deterministic validation to ensure detection accuracy. This achieves dynamic synergy between neural network intelligent detection and traditional rule-based deterministic validation, balancing detection efficiency and reliability. It avoids the problem of lack of interpretability in detection results from pure machine learning solutions, and also avoids the problem of traditional rule engines being unable to cover unknown error patterns, effectively improving the overall accuracy and reliability of program error checking.

[0109] Please refer to Figure 6 The function pointer cross-function resolution process of the present invention accurately binds the function pointer call to the target function that it is actually called through the following steps, specifically including S601 to S605.

[0110] S601. Obtain the function pointer call point. During the static value flow graph construction process, the system identifies function pointer call points in the source code. These call points contain the function pointer variable and its call context information. For example, the system identifies the function pointer call point 'void(*func_ptr)(int) =&target_func;' in the code. This is equivalent to the cross-function resolution process for the node corresponding to the function pointer in step 114 above.

[0111] S602. The pointer analysis module is invoked for address resolution. The system analyzes the function pointer using the pointer analysis module, extracts the symbolic address pointed to by the function pointer, and directly resolves the target function actually referenced by the function pointer. For example, address resolution is performed on the function pointer "func_ptr" to determine that it points to the function "target_func". This is equivalent to the process of performing pointer analysis on the intermediate representation to obtain pointer pointing information in step 302 above, and the pre-processing of cross-function resolution of the function pointer in step 114.

[0112] S603. The target function is determined by the target function resolver. Based on the address resolution result, the system searches the symbol table to determine the corresponding target function information, obtaining the function signature and entry address of the target function. For example, the resolver determines the target function to be "target_func", and its function signature is "void target(int)". This is equivalent to the process of determining the target function during cross-function resolution in step 114 above.

[0113] S604. Create direct inter-procedural edges using the SVFG builder. During the static value flow graph construction process, the system creates direct edges between the node corresponding to the function pointer and the node corresponding to the target function. These direct edges skip the traditional alias analysis step and directly connect the calling point and the target function. This is equivalent to creating a direct edge from the node corresponding to the function pointer to the node corresponding to the target function in step 114 above.

[0114] S605. Generate the data flow edge from CallSite to target_func, completing the creation of the cross-procedural data flow. The system completes the creation of the data flow edge from the call point (CallSite) to the target function. This direct edge accurately represents the dependency relationship corresponding to the function pointer call relationship, enabling subsequent data flow tracing to accurately jump from the call point to the target function, thus completing the creation of the cross-procedural data flow. This is equivalent to the direct edge in step 114 above being used to represent the dependency relationship corresponding to the function pointer call relationship.

[0115] As described above, by resolving function pointers across function addresses to determine the actual target function being called, and by creating direct edges between the node corresponding to the function pointer and the node corresponding to the target function, the precise binding of function pointer call relationships is achieved. This avoids the path ambiguity problem caused by associating target functions through indirect multi-hop paths in traditional alias analysis, making cross-process data flow tracing more accurate and effectively reducing false negatives and false positives caused by inaccurate pointer resolution.

[0116] Please refer to Figure 7 The loop structure folding process of the present invention compresses the loop structure in the static value flow graph into a summary node through the following steps, specifically including S701 to S702.

[0117] S701. Generate a summary node to represent the loop structure. The system creates a summary node based on the semantic analysis results of the loop structure. This summary node summarizes the overall data flow behavior of the loop structure, specifically including: abstracting the loop body by abstracting multiple operation nodes within the loop body into a single node to represent the data flow semantics of all operations within the loop body; representing iterative constraints by using the iterative constraints of the loop structure as node attributes to summarize the execution boundary of the loop; and representing the output state by using the final output state after the loop structure is executed as the node's output to summarize the final data flow result of the loop. This is equivalent to step 151 above.

[0118] S702. Obtain the original loop structure to be collapsed and identify its nodes. The system traverses each node and the edges between nodes in the static value flow graph, locates the loop structure subgraph to be collapsed, and identifies the loop head node, loop body node, loop end judgment node, and iteration update node in the loop structure: the loop head node is the entry point of the loop structure, controlling the loop entry condition; the loop body node is located between the loop head and the loop end judgment, containing the operation statements inside the loop; the loop end judgment node controls the loop exit condition, determining when the loop terminates; the iteration update node contains the increment or decrement operation of the loop variable, used to update the control variable in the loop condition. The system replaces all the above nodes with the summary node generated in S701, completing the collapse of the loop structure. This is equivalent to steps 150 to 152 above.

[0119] As described above, by generating summary nodes to represent the loop structure, the summary nodes abstractly represent the loop body and characterize the iterative constraints and output states. At the same time, the loop head node, loop body node, loop end judgment node, and iteration update node in the original loop are identified. By replacing the entire original loop structure with summary nodes, the complex loop structure can be compressed into a single summary node, which greatly simplifies the size of the static value flow graph, reduces the computational complexity of subsequent graph neural network processing, and thus improves the overall efficiency of program error checking.

[0120] Please refer to Figure 8 The array out-of-bounds detection process provided by the present invention performs cross-process data flow tracking and collaborative verification of array access operations through the following steps, specifically including S801 to S806.

[0121] S801. Obtain the source code to be inspected and perform code conversion. The system obtains the C / C++ source code to be inspected and converts it into an LLVM intermediate representation through the compiler front-end. This intermediate representation preserves the control flow structure, array access operations, and data flow information of the source code, providing a unified intermediate format for subsequent static analysis. This is equivalent to steps 111 to 112 above.

[0122] S802. Construct a static value flow graph using the SVFG engine. The system performs data flow analysis on the LLVM intermediate representation and constructs a corresponding static value flow graph based on the analysis results. This graph contains nodes related to array access operations (e.g., array declaration nodes, array access nodes, index variable nodes) and edges representing dependencies between nodes, ensuring that the declaration, access, and index transit relationships of arrays are accurately represented in a unified graph model. This is equivalent to steps 110 and 113 to 114 above.

[0123] S803. Submit the graph structure to the GNN detection engine. The system inputs the constructed static value flow graph into the graph neural network model. Through the model's internal graph convolutional layers, gated convolutional layers, and attention layers, it extracts the feature information of each node in the graph, performs error detection and classification on each node, and outputs the first confidence score and error type for each node. For array out-of-bounds detection scenarios, the model focuses on the features of array access nodes and their related index values. This is equivalent to steps 120 to 125 and steps 160 to 161 above.

[0124] S804. Perform hierarchical traffic distribution processing based on preset thresholds. The system compares the first confidence score of each node with the preset threshold: when the first confidence score is greater than or equal to the preset high threshold (e.g., 0.8), it directly confirms that the node has an array out-of-bounds error and proceeds to S806; when the first confidence score is between the preset low-to-medium threshold and the preset high threshold (e.g., 0.5 to 0.8), it indicates that the detection result is not reliable enough, and proceeds to S805 to call the rule engine for deterministic verification; when the first confidence score is lower than the preset low-to-medium threshold (e.g., 0.5), it is marked as a safe node and no processing is performed. This is equivalent to steps 130 to 132 above.

[0125] S805. Call the rule engine to verify the array index range. The system calls the rule engine to perform deterministic verification on the target node, matching the corresponding verification rule according to the node type of the target node. For array access nodes, the rule engine tracks the declared size of the array and the access offset, compares whether the value range of the index variable is within the legal boundaries of the array declaration, and verifies whether the data flow source of the index variable has undergone legal initialization or boundary checks, outputting the verification result of verification pass or verification failure. This is equivalent to step 131 above.

[0126] S806. Confirm the error location and output the detection result. The system determines the final error detection result based on the first confidence level and the verification result of the rule engine: for nodes with a first confidence level higher than a preset high threshold or nodes that have passed the rule engine verification, an array out-of-bounds error is confirmed, and the error type and error location are output; for nodes that have failed the rule engine verification, the error is excluded or marked as suspicious. Finally, an error detection result containing the error type, error location, and corresponding confidence level is generated and output. This is equivalent to step 140 above.

[0127] As described above, a static value flow graph containing array access-related nodes is constructed using the SVFG engine. The GNN engine intelligently detects each node in the graph and outputs a first confidence level and error type. Based on preset thresholds, hierarchical and segmented processing is performed. For target nodes with questionable confidence levels, a rule engine is invoked to perform deterministic verification of the array index range. Finally, the error location is confirmed by combining the first confidence level and the verification results. By using the static value flow graph as a bridge, combining intelligent detection from graph neural networks with traditional rule-based deterministic verification, accurate cross-process detection and reliable verification of array out-of-bounds errors are achieved. This effectively solves the problems of difficult tracing of cross-function paths and lack of interpretability of detection results in traditional methods.

[0128] Please refer to Figure 9The present invention also provides a program error checking system 900, including a memory 901, a processor 902, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the various steps of a program error checking method as described above.

[0129] In summary, the present invention provides a program error checking method and system that obtains the source code to be checked and constructs a corresponding static value flow graph to uniformly represent the dependencies between program variables using a graph structure. The graph neural network model processes each node in the static value flow graph and outputs the first confidence level and error type of each node. For target nodes with a first confidence level less than a preset threshold, a rule engine is called to verify the verification results. The error detection result is determined by combining the first confidence level and the verification results.

[0130] This invention achieves accurate tracking of cross-process data flow through the construction of a static value flow graph, automatically identifies unknown error patterns through intelligent detection using a graph neural network model, and reliably verifies detection results through deterministic verification using a rule engine. The collaborative judgment of the two engines balances the coverage of unknown error patterns with the verification accuracy of known error types. Compared with related technologies, this invention effectively solves the technical problems of insufficient cross-process tracking accuracy in traditional static analysis tools, high false negative rates due to a lack of semantic understanding in pure machine learning solutions, and the difficulty in deploying symbolic execution tools due to path explosion. It achieves the technical effect of integrating cross-process data flow analysis with intelligent pattern recognition, and balancing detection accuracy with result reliability. It can be widely applied to code defect detection and vulnerability investigation scenarios in security-critical areas such as operating system kernels and embedded systems, and has the advantages of high automation, low false positive rate, low false negative rate, and high detection efficiency.

[0131] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for checking program errors, characterized in that, include: Obtain the source code to be inspected, and construct a static value flow graph corresponding to the source code to be inspected. The static value flow graph contains multiple nodes and edges between the nodes. The nodes in the static value flow graph are processed by a graph neural network model, and the first confidence level and error type corresponding to each node are output. The first confidence level is used to represent the probability that each node has a program error. For target nodes whose first confidence level is less than a preset threshold, the rule engine is invoked for verification to obtain the verification result. Based on the first confidence level and the verification result, the error detection result in the source code to be inspected is determined.

2. The program error checking method according to claim 1, characterized in that, The construction of the static value flow graph corresponding to the source code to be inspected includes: Compile the source code to be inspected to generate an intermediate representation; The data stream of the intermediate representation is analyzed to obtain the analysis results, and the static value flow graph is constructed based on the analysis results.

3. The program error checking method according to claim 1, characterized in that, The construction of the static value flow graph corresponding to the source code to be inspected includes: Create a corresponding node for each program value in the source code to be inspected, wherein the program value includes at least a heap memory object and a function pointer; Perform cross-function parsing on the node corresponding to the function pointer, and create a direct connection from the node corresponding to the function pointer to the node corresponding to the target function. The direct connection is used to represent the dependency relationship corresponding to the function pointer call relationship.

4. The program error checking method according to claim 1, characterized in that, After constructing the static value flow graph corresponding to the source code to be inspected, the method further includes: Identify the loop structure in the static value flow graph; Generate the summary node corresponding to the loop structure; The loop structure is replaced with the summary node to obtain the updated static value flow graph.

5. The program error checking method according to claim 1, characterized in that, The process of processing each node in the static value flow graph using the graph neural network model and outputting the first confidence level and error type corresponding to each node includes: The first intermediate feature is obtained by performing graph convolution processing on each node in the static value flow graph through the graph convolution layer in the graph neural network model. The first intermediate feature is processed by gated convolution in the graph neural network model to obtain the second intermediate feature; The second intermediate feature is weighted by the attention layer in the graph neural network model to obtain the third intermediate feature; Based on the third intermediate feature, error detection processing is performed on each node, and the first confidence level corresponding to each node is output. The nodes are classified according to the third intermediate feature, and the error type and the second confidence level corresponding to each error type are output.

6. The program error checking method according to claim 5, characterized in that, The process of performing attention-weighted processing on the second intermediate feature through the attention layer in the graph neural network model to obtain the third intermediate feature includes: The second intermediate feature is weighted by a preset number of attention branches in the attention layer to obtain the third intermediate feature.

7. The program error checking method according to claim 1, characterized in that, The process of processing each node in the static value flow graph using the graph neural network model and outputting the first confidence level and error type corresponding to each node includes: The graph neural network model is used to classify each node in the static value flow graph and output the type confidence of each error type corresponding to each node. Based on the type confidence of each error type corresponding to each node, determine the first confidence level corresponding to each node and the judgment result of whether each node has a program error; Based on the judgment result, output the error type corresponding to each node where a program error exists.

8. The program error checking method according to claim 1, characterized in that, The step of calling the rule engine to verify the target node whose first confidence level is less than a preset threshold, and obtaining the verification result, includes: When the first confidence level is less than a preset threshold, the rule engine is invoked to verify the target node and obtain the verification result; When the first confidence level is greater than or equal to a preset threshold, the error detection result of the target node is determined based on the first confidence level.

9. The program error checking method according to claim 1, characterized in that, Before processing each node in the static value flow graph using the graph neural network model and outputting the first confidence level and error type corresponding to each node, the method further includes: Extract the static semantic features and data flow dynamic features of each node; The static semantic features and the data flow dynamic features are combined to generate feature vectors for each node, and the feature vectors of each node are input into the graph neural network model.

10. A program error checking system, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements each step of the program error checking method according to any one of claims 1 to 9.

Images