Software repair method and device, equipment, medium and product

Abstract

The invention provides a software repair method and device, equipment, a medium and a product, and relates to the technical field of software engineering.The method comprises the steps that a to-be-repaired code snippet and multi-modal context information and a reference repair case associated with the to-be-repaired code snippet are obtained; according to the to-be-repaired code snippets, the multi-modal context information and the reference repair case, utilizing a generative model to generate at least one candidate repair patch; for each candidate repair patch, performing formalized verification and solution to obtain a verification result corresponding to the candidate repair patch; under the condition that the verification result indicates that the candidate repair patch passes verification, the to-be-repaired code snippets are repaired through the candidate repair patch; and under the condition that the verification result indicates that the candidate repair patch does not pass the verification, feeding back prompt information for triggering the generative model to optimize the candidate repair patch to the generative model according to the path information or the error state code corresponding to the candidate repair patch.

Description

Technical Field

[0001] This application relates to the field of software engineering technology, and in particular to a software repair method, apparatus, equipment, medium, and product. Background Technology

[0002] With the advancement of Industry 4.0, industrial software systems are evolving from monolithic applications to distributed architectures based on microservices, leading to a dramatic increase in system complexity. Industrial production places extremely high demands on the availability of software systems (typically requiring availability of over 99.9%), and even minor code defects can cause production downtime or safety incidents.

[0003] In existing technologies, code generation techniques based on Large Language Models (LLMs), such as GPT-4 and CodeT5, have demonstrated strong repair capabilities in the general software domain. However, directly applying LLMs for repair in industrial scenarios suffers from insufficient reliability. Specifically, LLMs can exhibit a "phantom" phenomenon: the generated code may be syntactically correct but may contain deep logical errors, such as integer overflows and deadlocks, that are difficult to detect through traditional unit tests. Summary of the Invention

[0004] This application provides a software repair method, apparatus, device, medium, and product, which solves the problem of insufficient reliability in software repair based on LLM.

[0005] Firstly, to achieve the above objectives, embodiments of this application provide a software repair method, comprising: Obtain the code snippet to be repaired, as well as the multimodal context information associated with the code snippet and reference repair cases; Based on the code snippet to be repaired, the multimodal context information, and the reference repair case, at least one candidate repair patch is generated using a generative model; wherein, the generative model is a domain-fine-tuned code-large language model; For each of the candidate repair patches, formal verification and solution are performed to obtain the verification results corresponding to the candidate repair patch; If the verification result indicates that the candidate patch has passed verification, the candidate patch is used to repair the code segment to be repaired. If the verification result indicates that the candidate patch has failed verification, a prompt message is sent to the generative model based on the path information or error status code corresponding to the candidate patch. The prompt message is used to trigger the generative model to optimize the candidate patch.

[0006] Among them, obtaining reference repair cases associated with the code snippet to be repaired includes: The code fragment to be repaired is input into the semantic vector model to obtain the semantic similarity between the code fragment to be repaired output by the semantic vector model and the historical repair cases in the historical repair case knowledge base; The syntactic similarity between the code segment to be repaired and the historical repair case is determined based on the edit distance between the abstract syntax tree (AST) structural features of the code segment to be repaired and the AST structural features corresponding to the historical repair cases. Based on the semantic similarity and the syntactic structural similarity, the reference repair case is obtained from the historical repair case knowledge base.

[0007] Specifically, based on the code snippet to be repaired, the multimodal context information, and the reference repair case, at least one candidate repair patch is generated, including: Based on the code snippet to be repaired, the multimodal context information, and the reference repair case, construct few-sample prompt words; The few-sample prompt words are input into the generative model to obtain at least one candidate repair patch generated by the generative model; wherein, the generative model is used for: The few-sample prompts are processed using a cross-modal attention mechanism to obtain a cross-modal attention weight matrix; Based on the attention weight matrix, determine the probability distribution of each lexical token generated by the few-sample prompt word; Based on the probability distribution, a beam search is performed on the sample prompt words, and the candidate repair patch is generated based on the search results.

[0008] After the step of determining the probability distribution of each lexical token generated by the few-sample prompt word based on the attention weight matrix, the method further includes: The attention distribution data corresponding to the probability distribution is rendered into a visual heatmap and displayed.

[0009] Specifically, for each candidate repair patch, formal verification and solution are performed to obtain the verification result corresponding to the candidate repair patch, including: The candidate repair patch is combined with the code segment to be repaired to obtain the combined code, and the combined code is parsed into a first intermediate representation; The first intermediate representation is statically analyzed using a static analyzer to obtain the static analysis results. Based on the static analysis results and security attributes, security attribute assertions are inserted into the first intermediate representation to obtain the second intermediate representation; Symbolic execution and bounded model testing are performed on the second intermediate representation, and the satisfiability verification of the security attribute assertions in the second intermediate representation is performed by calling the satisfiability model theory (SMT) solver.

[0010] The static analysis of the first intermediate representation is performed using a static analyzer to obtain static analysis results, including: During the static analysis of the first intermediate representation by the static analyzer, if the static analyzer fails to resolve the external function call, a nondeterministic stub function corresponding to the external function call is generated. The symbolic arbitrary value returned by the nondeterministic stub function is used as the static analysis result of the external function call.

[0011] The method further includes: If the candidate patch verification fails due to the uncertainty of the external codebase, as indicated by the verification result, the external function in the first intermediate representation is marked as a manually reviewed area, or the external function is replaced during the generation of the candidate patch.

[0012] The verification result includes cases where the verification fails, the solution times out, or the result is unknown. In such cases, the verification result indicates that the candidate repair patch has not passed the verification. If the verification result includes verification failure, the prompt information is obtained by converting the path information; If the verification result includes the solution timeout or the unknown, the prompt information is obtained by converting the error status code.

[0013] Secondly, to achieve the above objectives, embodiments of this application provide a software repair apparatus, comprising: The acquisition module is used to acquire the code segment to be repaired, as well as the multimodal context information and reference repair cases associated with the code segment to be repaired; The generation module is used to generate at least one candidate patch based on the code snippet to be repaired, the multimodal context information, and the reference repair case, using a generative model; wherein the generative model is a domain-adjusted code-large language model. The verification module is used to perform formal verification and solve for each of the candidate repair patches to obtain the verification result corresponding to the candidate repair patch. The repair module is used to repair the code segment to be repaired using the candidate repair patch when the verification result indicates that the candidate repair patch has passed verification. The feedback module is used to provide feedback information to the generative model based on the path information or error status code corresponding to the candidate repair patch when the verification result indicates that the candidate repair patch has failed verification. The feedback information is used to trigger the generative model to optimize the candidate repair patch.

[0014] Thirdly, to achieve the above objectives, embodiments of this application provide a software repair device, including a transceiver, a processor, a memory, and a program stored in the memory and executable on the processor; the transceiver is used to send and receive data under the control of the processor, and the processor implements the software repair method as described in the first aspect when executing the program.

[0015] Fourthly, to achieve the above objectives, embodiments of this application provide a readable storage medium having a program or instructions stored thereon, which, when executed by a processor, implement the software repair method as described in the first aspect.

[0016] Fifthly, to achieve the above objectives, embodiments of this application provide a computer program product including computer instructions that, when executed by a processor, implement the software repair method as described in the first aspect.

[0017] The beneficial effects of the above technical solution in this application are as follows: In this embodiment, firstly, the code segment to be repaired, along with multimodal context information and reference repair cases associated with the code segment to be repaired, are obtained. Secondly, based on the code segment to be repaired, the multimodal context information, and the reference repair cases, at least one candidate repair patch is generated using a generative model. The generative model is a domain-adjusted code-large language model. Thirdly, formal verification and solving are performed on each candidate repair patch to obtain a verification result corresponding to the candidate repair patch. This ensures the security of the repair patch. Then, on the one hand, if the verification result indicates that the candidate repair patch has passed verification, the candidate repair patch is used to repair the code segment to be repaired. This improves the credibility of the repair patch. On the other hand, if the verification result indicates that the candidate repair patch has failed verification, a prompt message is fed back to the generative model based on the path information or error status code corresponding to the candidate repair patch. The prompt message triggers the generative model to optimize the candidate repair patch. This achieves an intelligent closed loop for software repair, thereby significantly improving the success rate of repairing complex defects. Attached Figure Description

[0018] Figure 1 This is one of the flowcharts illustrating the software repair method according to an embodiment of this application; Figure 2 This is a schematic diagram illustrating the data interaction between the hybrid retrieval mechanism and the large model generation module in an embodiment of this application; Figure 3 This is a schematic diagram illustrating the formal verification and solution in the embodiments of this application; Figure 4 This is a schematic diagram of the counterexample feedback loop after the verification of a counterexample fails in an embodiment of this application; Figure 5 This is a second schematic flowchart of the software repair method according to an embodiment of this application; Figure 6 This is a schematic diagram of the structure of the software repair device according to an embodiment of this application; Figure 7 This is a schematic diagram of the structure of the software repair device according to an embodiment of this application. Detailed Implementation

[0019] To make the technical problems, technical solutions and advantages of this application clearer, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments.

[0020] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments.

[0021] In the various embodiments of this application, it should be understood that the sequence number of each process described below does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0022] In addition, the terms "system" and "network" are often used interchangeably in this article.

[0023] In the embodiments provided in this application, it should be understood that "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0024] Embodiments of this application provide a software repair method, such as... Figure 1 As shown, the method includes: Step 101: Obtain the code segment to be repaired, as well as the multimodal context information associated with the code segment to be repaired and the reference repair case.

[0025] For example, step 101 can be executed when the industrial software system detects a software defect during operation. The software defect can be detected by the industrial software system through logs or telemetry indicators; the software defect may be, for example, a function crash or an outlier.

[0026] For example, the multimodal context information associated with the code segment to be repaired refers to relevant information within the complete compilation unit or function scope where the code segment to be repaired resides. For instance, the multimodal context information associated with the code segment to be repaired may include one or more of the following: system runtime logs, telemetry metrics, and execution trajectories.

[0027] Step 102: Based on the code snippet to be repaired, the multimodal context information, and the reference repair case, at least one candidate repair patch is generated using a generative model; wherein the generative model is a domain-fine-tuned code-large language model.

[0028] For example, step 102 above could involve inputting the three elements (the code snippet to be fixed, multimodal context information, and reference fix case) or information related to the three elements into a generative model to obtain one or more candidate fix patches output by the generative model. Furthermore, the generative model will also output the confidence level of each candidate fix patch.

[0029] It should be noted that the generative model mentioned above, for example, is an LLM model using CodeT5+ (770M parameters) as the base model. This generative model has been fine-tuned for domain adaptation on 5 million code repair samples. The key parameters in the fine-tuning process include: Learning Rate. Batch Size: 16.

[0030] Step 103: For each candidate patch, perform formal verification and solution to obtain the verification result corresponding to the candidate patch. Here, formal verification and solution can also be called mathematical proof and solution, which aims to mathematically prove the security of the candidate patch from a logical level.

[0031] Step 104: If the verification result indicates that the candidate patch has passed verification, use the candidate patch to repair the code segment to be repaired.

[0032] It should be noted here that when there are multiple verified candidate patch patches, the candidate patch used to repair the code segment to be repaired in step 104 above is the one with the highest confidence among the multiple verified candidate patch patches. As an example, the formal verification and solution of multiple candidate patch patches in step 103 above can be implemented as follows: formal verification and solution are performed on each candidate patch in descending order of confidence, and step 104 is executed based on the first verified candidate patch patch. In this way, both the credibility of the repair and the code quality / naturalness can be taken into account.

[0033] Step 105: If the verification result indicates that the candidate repair patch has failed verification, a prompt message is fed back to the generative model based on the path information or error status code corresponding to the candidate repair patch. The prompt message is used to trigger the generative model to optimize the candidate repair patch. In this way, the negative examples output by the verification are no longer discarded, but are transformed into natural language or structured data and fed back to the generative model, enabling the model to "learn from its mistakes" and significantly improving the success rate of repairing complex defects.

[0034] It should be noted that the number of times the generative model optimizes candidate repair patches based on the prompt information should be less than or equal to the pre-set optimization number threshold.

[0035] In other words, after formally verifying and solving the candidate patch using step 103 above, the formal verification and solution results of the candidate patch are obtained. On the one hand, if the formal verification and solution results are successful, that is, the candidate patch is mathematically proven to be safe from a logical perspective, then the code segment to be repaired can be repaired based on the candidate patch, thus improving the credibility of the repair. On the other hand, if the formal verification and solution results are unsuccessful or unknown, the candidate patch can be used as a counterexample and fed back to the generative model. In this way, the generative model will refer to the counterexample when regenerating the candidate patch, thereby improving the accuracy and reliability of the candidate patch generated by the generative model, and thus improving the success rate of repairing complex defects.

[0036] In this embodiment, firstly, the code segment to be repaired, along with multimodal context information and reference repair cases associated with the code segment to be repaired, are obtained. Secondly, based on the code segment to be repaired, the multimodal context information, and the reference repair cases, at least one candidate repair patch is generated using a generative model. The generative model is a domain-adjusted code-large language model. Thirdly, formal verification and solving are performed on each candidate repair patch to obtain a verification result corresponding to the candidate repair patch. This ensures the security of the repair patch. Then, on the one hand, if the verification result indicates that the candidate repair patch has passed verification, the candidate repair patch is used to repair the code segment to be repaired. This improves the credibility of the repair patch. On the other hand, if the verification result indicates that the candidate repair patch has failed verification, a prompt message is fed back to the generative model based on the path information or error status code corresponding to the candidate repair patch. The prompt message triggers the generative model to optimize the candidate repair patch. This achieves an intelligent closed loop for software repair, thereby significantly improving the success rate of repairing complex defects.

[0037] As an optional implementation, step 101 involves obtaining a reference repair case associated with the code snippet to be repaired, including: Sub-step 1: Input the code fragment to be repaired into the Semantic Vector Model (SVM) to obtain the semantic similarity between the code fragment to be repaired output by the SVM and historical repair cases in the historical repair case knowledge base. The SVM is a pre-trained model; for example, it could be Sentence-BERT (Sentence = Bidirectional Encoder Representations from Transformers). The historical repair case knowledge base is a system-maintained knowledge base containing over 100,000 historical repair cases.

[0038] Sub-step 2: Determine the syntactic structural similarity between the code segment to be repaired and the historical repair case based on the edit distance between the abstract syntax tree (AST) structural features of the code segment to be repaired and the AST structural features corresponding to the historical repair cases; wherein, the syntactic structural similarity is measured by the edit distance.

[0039] Sub-step 3: Based on the semantic similarity and the syntactic structural similarity, obtain the reference repair case from the historical repair case knowledge base. For example, the reference repair case may include a table comparing the error code and the correct repair code for that case.

[0040] For example, sub-step three above can be based on determining a comprehensive similarity based on semantic similarity and syntactic structural similarity, and then filtering historical restoration cases with comprehensive similarities greater than a similarity threshold from the historical restoration case knowledge base, so as to select a reference restoration case from the filtered historical restoration cases. The comprehensive similarity can be obtained by weighted summation or averaging of semantic similarity and syntactic structural similarity.

[0041] In short, in this embodiment of the application, obtaining reference repair cases can be achieved by using a hybrid retrieval strategy to filter reference repair cases corresponding to the code segment to be repaired in the historical repair case knowledge base. The hybrid retrieval strategy includes a retrieval strategy based on semantic similarity and a retrieval strategy based on syntactic structure similarity. The overall similarity of the reference repair cases is greater than the similarity threshold, for example, the similarity threshold is 0.75.

[0042] The number of reference repair cases is less than or equal to k, where k is a pre-configured integer, such as k = 3. For example, if the number of historical repair cases with a comprehensive similarity greater than the similarity threshold is m, and if m is greater than k, then the top k historical repair cases with the highest comprehensive similarity among the m historical repair cases will be used as reference repair cases; if m is less than k, then all m historical repair cases will be used as reference repair cases.

[0043] Among the above-mentioned optional implementation methods, the reference case retrieval is performed by combining the structural features of the code, the abstract syntax tree (AST), and the semantic features, making the retrieved reference cases more targeted.

[0044] As a special case, if no historical repair cases with a comprehensive similarity greater than the similarity threshold exist, a downgrade process is performed. This downgrade means that candidate repair patches are not generated using Few-shot prompts, but solely rely on the generative model's own generation capabilities. This avoids introducing low-quality similar cases that could mislead the generative model. In other words, when no historical repair cases with a comprehensive similarity greater than the similarity threshold exist, the information input to the generative model includes the code snippet to be repaired and multimodal context information, but excludes reference repair cases.

[0045] As an optional implementation, step 102 involves generating at least one candidate patch based on the code snippet to be repaired, the multimodal context information, and the reference repair case, including: Sub-step 1: Construct few-shot cue words based on the code snippet to be repaired, the multimodal context information, and the reference repair case. In simpler terms, the code snippet to be repaired, the multimodal context information, and the reference repair case are the raw materials input to the generative model. The constructed few-shot cue words are a formatted encapsulation of these raw materials; that is, these raw materials are organized in a format that the generative model can understand, generating / encapsulating them into few-shot cue words.

[0046] It should be noted here that, as mentioned earlier, if no reference repair case is obtained in step 101, the Few-Shot prompt words can be constructed based solely on the code snippet to be repaired and the multimodal context information. In this case, candidate repair patches are subsequently generated based on the generative capabilities of the generative model itself.

[0047] Sub-step two: Input the few-sample prompt words into the generative model to obtain at least one candidate repair patch generated by the generative model; wherein, the generative model is used for: A) The few-sample prompts are processed using a cross-modal attention mechanism to obtain a cross-modal attention weight matrix; the cross-modal attention mechanism can also be described as a multi-head attention mechanism.

[0048] It should be noted that the cross-modal attention weight matrix can also be used to uncover the temporal dependencies and causal relationships between defective code snippets and system exception logs.

[0049] B) Determine the probability distribution of each lexical token generated by the few-sample prompt word based on the attention weight matrix.

[0050] For example, the implementation process of the above two steps can be described as follows: First, the attention weight of the current decoding step for each position in the input sequence (code, log, metric) / hint is calculated using a cross-modal attention mechanism; then, these weights are weighted and summed with the value vector of the corresponding position to obtain a context vector carrying cross-modal information; this context vector is fused with the current hidden state (usually through concatenation or gating mechanism) and jointly input into the classification layer to calculate the probability distribution of the next token; among them, repair mode tokens (such as boundary checks and null pointer checks) related to high-weight cross-modal information (such as abnormal logs) will obtain a higher generation probability, thereby achieving the purpose of guiding the generation of repair code with cross-modal association information.

[0051] C) Based on the probability distribution, perform a beam search on the sample prompts and generate candidate repair patches based on the search results. For example, the beam width of the beam search is set to 5, and the temperature parameter is 0.6.

[0052] In the aforementioned optional implementations, cross-modal attention enhancement influences the probability distribution of token generation at each step; beam search searches for the optimal complete sequence based on these probability distributions. In other words, cross-modal attention enhancement determines "which tokens are more likely to be selected at each step," while beam search determines "how to find the optimal complete patch from these possibilities."

[0053] Below, in conjunction with Figure 2 The following describes an example of obtaining reference repair cases and generating candidate repair patches in the two optional implementation methods mentioned above. The process of obtaining reference repair cases can be referred to as being implemented by the hybrid retrieval module, and the process of generating candidate repair patches can be referred to as being implemented by the generative AI engine. The generative AI engine can be an AI engine that deploys a generative model, or the generative AI engine can refer to the aforementioned generative model.

[0054] The process of obtaining reference repair cases by the hybrid retrieval module includes: mapping the defective code to be repaired (i.e., the aforementioned code fragment to be repaired) to obtain semantic vector features corresponding to the defective code to be repaired, and parsing the defective code to be repaired (i.e., the aforementioned code fragment to be repaired) to obtain AST structural features corresponding to the defective code to be repaired; on the other hand, obtaining case vectors and case ASTs of cases in the historical repair knowledge base; secondly, inputting the semantic vector features and the case vectors into Sentence-BERT to obtain the semantic similarity between the two, and calculating the edit distance between the AST structural features and the case AST to obtain the structural similarity between the two (i.e., the aforementioned syntactic structural similarity); thirdly, comprehensively ranking and filtering the cases in the historical repair knowledge base based on syntactic similarity and structural similarity to obtain the top K cases with the highest comprehensive similarity (Top-K cases); finally, inputting the Top-K cases into the generative AI engine to generate candidate repair patches.

[0055] The generative AI engine obtains candidate repair patches through the following process: First, it acquires the defective code to be restored and the Top-K cases, and performs context assembly based on the defective code to be restored, its multimodal context information, and the Top-K cases to obtain a hint word; second, it inputs the hint word into the CodeT5+ large model based on the model input layer; third, the CodeT5+ large model generates a set of candidate patches (i.e., the aforementioned candidate repair patches) based on the hint word and the domain fine-tuning weights.

[0056] Furthermore, as an optional implementation, after the step of determining the probability distribution of each lexical token generated by the few-sample prompt word based on the attention weight matrix, the method further includes: The attention distribution data corresponding to the probability distribution is rendered into a visual heatmap and displayed. This visual heatmap enhances the interpretability of candidate repair patches, helping industrial field engineers understand the rationale behind the AI-based repairs and build trust. The attention distribution data refers to the attention weight matrix data extracted from the generative model's internal attention layer during inference. This data characterizes the contribution or correlation of each input multimodal context token to the generated candidate patch tokens.

[0057] In other words, to build trust among industrial field engineers in the results of AI-based repairs, an attention mechanism can be used as a core technology for interpretability. The specific implementation is as follows: First, the attention weight matrix of each layer in the generative model during the inference process is extracted. The token sequence generated by each word (Token) in the input sequence (i.e. the aforementioned Few-Shot cue words) is calculated, such as the aforementioned code snippet to be repaired, multimodal context information and reference repair cases, and its contribution to the generated candidate repair patch. This allows industrial field engineers to understand the basis for the generative model to generate candidate repair patches based on this contribution.

[0058] Secondly, for cross-modal features, the system not only analyzes internal code dependencies, but also automatically aligns "code execution" with "system logs" through a cross-attention layer. For example, when fixing a deadlock, the attention mechanism will capture the extremely high correlation weight between lock acquisition operations in the code and "wait timeout" records in the log.

[0059] Finally, in the system interface, the calculated attention distribution data is rendered as a "visualized heatmap." Engineers can visually see through the heatmap that during the model's repair, not only was the variable `temperature` defined as `uint8` (thus avoiding errors such as assigning values ​​exceeding 255) considered, but also the associated abnormal log entries were highlighted. This mechanism, which transforms underlying mathematical weights into intuitive visual feedback, breaks down the black box and enhances the transparency of the repair plan.

[0060] Another way to describe the above implementation is as follows: First, obtain the raw data, extract the attention weights, calculate the contribution of each token to the generated patch, and output the attention weight matrix; second, add a cross-modal dimension on this basis, align the code lines and logs through Cross-Attention, and output the cross-modal association weights; finally, visualize the results of the first two steps: render the attention distribution as a visual heatmap, and output the heatmap displayed on the interface.

[0061] As an optional implementation, step 103 involves performing formal verification and solving for each candidate repair patch to obtain the verification result corresponding to the candidate repair patch, including: Sub-step 1: Combine the candidate repair patch with the code fragment to be repaired to obtain the combined code, and parse the combined code into a first intermediate representation.

[0062] For example, the combination of the candidate patch and the code segment to be repaired can be in any of the following ways: Method 1: Code replacement: Replace the original code segment to be repaired in the source code with the candidate patch to form complete code to be verified; Method 2: AST splicing: Replace or insert the AST node of the candidate patch into the corresponding position of the AST in the source code at the abstract syntax tree level to ensure the integrity of the syntax structure; Method 3: Symbol table merging: Merge the new variables and types introduced in the candidate patch with the symbol table of the original code to ensure the consistency of variable scope and type definition.

[0063] After obtaining the combined code, the control flow graph (CFG) can be reconstructed based on the combined code, serving as the basis for subsequent formal verification.

[0064] For example, the above-mentioned parsing of the combined code into a first intermediate representation can be achieved by inputting the combined code into the Efficient SMT-Based Context-Bounded Model Checker (ESMBMC)-AI framework to parse the combined code (such as C / C++ code) into a GOTO intermediate representation.

[0065] Sub-step 2: Use a static analyzer to perform static analysis on the first intermediate representation to obtain the static analysis results.

[0066] It should be noted here that the static analyzer is a built-in analyzer of the system that executes the method of the embodiments of this application. The static analysis performed by the static analyzer on the first intermediate representation includes control flow analysis and data flow analysis to identify potential risk variables and boundary conditions.

[0067] Sub-step 3: According to the static analysis results and security properties, insert security property assertions into the first intermediate representation to obtain a second intermediate representation; among which, for different security properties, the inserted security property assertions are different. For example, for memory security and arithmetic security, assertion statements including array out-of-bounds check, null pointer dereference check, buffer overflow check, and integer overflow check are automatically injected. For example, the assertion statement for array out-of-bounds check is assert(variable < MAX_INT); for concurrent security, identify lock operations and thread synchronization primitives in the code, construct a concurrent dependency graph or a partial order model, and generate safety constraint properties (Safety Properties) for detecting deadlocks and race conditions; in other words, for concurrent security, identify lock objects (Mutex) and thread operations, construct a local partial order relationship, and insert timing assertions for detecting deadlock circular waits.

[0068] In other words, to achieve automatic assertion insertion, a static analyzer is built into this system. After converting the code into GOTO intermediate representation, the static analyzer traverses the control flow graph (CFG). For example, when an array access operation Array[i] is identified, the static analyzer will automatically insert the assertion assert(i >= 0 && i < Size) before the access based on the size (Size) declared in the array; when an arithmetic division a / b is identified, the assertion assert(b != 0) is automatically inserted. This process requires no manual intervention, ensuring that all potential boundary conditions are included in the verification scope. Specifically: First, convert the combined complete code (original source code + candidate repair patch) into GOTO intermediate representation and generate the corresponding control flow graph (Control Flow Graph‌, CFG). Second, the built-in static analyzer starts to traverse the control flow graph node by node, analyzing the operation type and operands of each instruction. Third, during the traversal, the static analyzer identifies key operations that need to insert assertions according to the predefined risk pattern library, including array access, pointer dereference, arithmetic operations, lock operations, etc.; then, for the identified risk operations, the analyzer obtains the necessary context information from the symbol table and the scope; based on the risk type and the obtained context information, generate the corresponding assertion condition expression; and insert the generated assertion statement into the corresponding position of the control flow graph; finally, update the inserted assertion as a new node into the control flow graph to form a complete verification model containing assertion information for subsequent symbolic execution and SMT solving.

[0069] Sub-step four: Perform symbolic execution and bounded model checking on the second intermediate representation, and call the Satisfiability Modulo Theories (SMT) solver to verify the satisfiability of the security attribute assertions in the second intermediate representation, that is, verify whether there is an execution path that violates the assertions in the code corresponding to the second intermediate representation.

[0070] The SMT solver can verify the satisfiability of the security attribute assertions in the second intermediate representation by solving the path formula containing the patch, and mathematically proving that the patch does not violate the assertions within the unfolding depth.

[0071] It should be noted here that the preset loop unrolling depth of symbolic execution (e.g., 50) and the preset timeout threshold of the SMT solver need to be set in advance. The SMT solver can be, for example, the Z3 solver or the CVC solver.

[0072] Here, it should also be noted that, considering that industrial code may call unparseable third-party closed-source libraries (such as .dll, .so) or low-level system calls, causing the formal verification engine to fail to expand, a "function stubbing" mechanism is set up in this embodiment. Based on this, as an optional implementation, the aforementioned step of "using a static analyzer to perform static analysis on the first intermediate representation to obtain static analysis results" includes: During the static analysis of the first intermediate representation by the static analyzer, if the static analyzer fails to resolve the external function call, a nondeterministic stub function corresponding to the external function call is generated; and the symbolic arbitrary value returned by the nondeterministic stub function is used as the static analysis result of the external function call.

[0073] In other words, when the static analyzer encounters an unresolved external function call, it automatically generates a non-deterministic stub function. This stub function returns a symbolic arbitrary value to simulate the behavior of the external library, thereby ensuring the continuity of the symbolic execution path. The simulation of external behavior can include: symbolic return values, no concrete implementation, preservation of interface signatures, path forks, etc. Furthermore, the aforementioned "arbitrary value" refers to a symbolic value in symbolic execution, represented by symbolic variables (such as α, β) to indicate the unknown value.

[0074] Furthermore, as an optional implementation, the method also includes: If the verification of the candidate patch indicated by the verification result fails due to the uncertainty of the external code library, the external function in the first intermediate representation is marked as a manually reviewed area. Alternatively, the external function may be replaced during the generation of the candidate patch. In other words, if the verification result is "Unknown" due to the uncertainty of the external library, the system will mark the area as requiring manual review or attempt to replace the external call during the generation phase.

[0075] Here, it's important to note that there are several ways to determine the cause of verification failure: Method 1: When the SMT solver returns "UNKNOWN," it usually includes a cause code or description. Based on this cause code or description, it can be determined whether the verification failure is due to the non-determinism of an external codebase. Method 2: Tag tracking during symbolic execution. When the SMT solver returns "UNKNOWN," backtrack the path conditions of the current path and check if it contains symbolic variables marked with "SYMBOL_FROM_STUB." Method 3: Perform complexity analysis on the constraints in the path conditions to identify whether complex constraints are caused by symbols introduced from an external library.

[0076] As an optional implementation, if the verification result includes verification failure, solution timeout, or unknown, the verification result indicates that the candidate repair patch verification failed; wherein, if the verification result includes verification failure, the prompt information is obtained by converting the path information; if the verification result includes solution timeout or unknown, the prompt information is obtained by converting the error status code.

[0077] In other words, the output of the SMT solver contains three states, which the system processes as follows: (1) Verification passed: If the SMT solver returns UNSAT (unsatisfiable), that is, no path violating the assertion was found within the constraint range, it means that the verification passed. At this time, the patch can be output and deployed.

[0078] (2) Verification Failure: If the SMT solver returns SAT (satisfiable), the verification fails, indicating a counterexample exists. The system outputs a specific counterexample (e.g., overflow occurs when input x=65535). The system uses a prompt word template to convert this trace into a text description: "The current fix will cause an integer overflow when input x=65535. Please regenerate." The generative model receives this feedback as a negative sample prompt, enabling it to regenerate the fix patch based on this negative sample prompt and other information. This counterexample can be the result of solving the satisfiable path formula using the SMT solver, generating specific variable assignments. When the SMT solver determines the path formula to be SAT (satisfiable), it means there exists a set of variable assignments that result in: the path condition being met and the assertion condition being violated (security attribute not met). In this case, the SMT solver not only returns SAT but also provides a specific model that satisfies the formula, i.e., the specific value of each symbolic variable. This specific assignment combination is the counterexample.

[0079] For example, when an SMT solver (such as Z3) returns "SAT" and the corresponding Trace, the Trace data typically contains a series of variable assignment states (e.g., step 1: x=10; step 2: y=0; step 3: crash). First, the Trace data is processed using a predefined prompt template. For example, the template might look like this: "When the input variable {var_name} has the value {value}, an error of {error_type} is triggered on line {line_num}." Second, the extracted variable values ​​are populated into the template to generate a natural language description such as "When the input x=65535, an integer overflow error is triggered on line 12." This description is appended to the generative model's input prompt, explicitly telling the generative model "Do not generate code containing this logical path," thus forcing the model to explore new solution spaces.

[0080] (3) Timeout or Unknown: If the SMT solver returns UNKNOWN or TIMEOUT, it is usually caused by path explosion, nonlinear constraints, or third-party library calls. In this case, the system extracts the error status code or last log of the SMT solver and converts it into a prompt that "the code logic is too complex or contains unsolvable constraints". This prompt is fed back to the generative model to guide it in generating a "simplified logic" or "split function" solution to reduce code complexity and thus attempt to bypass the solver's bottleneck.

[0081] Below, in conjunction with Figure 3This document describes the implementation process of formal verification and solution, as well as the feedback of information to the generative model, among the various optional implementation methods described above. This process can be achieved through a generative large model (…). Figure 3 The interaction between the candidate patch code (represented by candidate patch code), the ESBMC-AI frontend, the symbolic execution engine, and the Z3 SMT solver includes the following steps: First, candidate patch code (i.e., the aforementioned candidate repair patch) is input into the ESBMC-AI frontend, where the candidate patch code can be C / C++ code; second, the ESBMC-AI frontend parses the candidate patch code, stubs external functions (if external functions exist in the code), and converts it into an intermediate representation (IR), then automatically inserts safety assertions into the IR; the purpose of automatically inserting safety assertions is to check whether there are memory out-of-bounds errors, overflows, deadlocks, or race conditions in the code; third, the ESBMC-AI frontend submits the asserted IR to the symbolic execution engine; then, the symbolic execution engine performs symbolic execution (bounded expansion), where the process is cyclical expansion with a preset expansion depth, and this process is used to construct path constraint formulas (SSA form); finally, the symbolic execution engine submits the SMT logic formula generated by the above symbolic execution process to the Z3 SMT solver, so that the Z3 solver can process it. The SMT solver is based on the SMT logic formula and the inverse satisfiability solution (AST Solving). Then, the Z3 SMT solver feeds back the solution results to the symbolic execution engine. The solution results include: verification passed (no vulnerabilities), verification failed (counterexamples found), solution timeout, or unknown. Finally, the symbolic execution engine feeds back different information to the generative large model according to the solution results. When the solution result is verification passed (no vulnerabilities), a success signal is returned to the generative large model. When the solution result is verification failed (counterexamples found), a trace (counterexample path) is returned to the generative large model. When the solution result is solution timeout or unknown, an error (suggesting simplified logic) is returned to the generative large model.

[0082] An example of the counterexample feedback loop after a failed verification of a counterexample in this application embodiment is as follows: Figure 4As shown, the process includes a Prompt Engineering phase: generating enhanced prompts based on the verification results and the original prompts; and a candidate patch regeneration phase. For verification failure (SAT), the Prompt Engineering phase includes: parsing the counterexample Trace:x=65535… using a counterexample parser to obtain a parsing result, where the parsing result is described as: an overflow occurred when the input x is 65535…; secondly, dynamically injecting enhanced prompts based on the parsing result and the original prompts. For exceptions (TIMEOUT / UNKNOWN), the Prompt Engineering phase includes: firstly, analyzing the error state based on the error log: Solver Timeout to obtain an analysis result, where the analysis result is described as: code constraints are too fine-grained; please split the function or simplify the logic; secondly, dynamically injecting enhanced prompts based on the decomposition result and the original prompts. The candidate patch regeneration phase includes: LLM regenerating the patch based on the enhanced prompts to obtain a new candidate patch v2, and verifying the new candidate patch v2.

[0083] The implementation process of the embodiments of this application will now be described in terms of the modules included in the device / system that executes the embodiments of this application. The device / system that executes the embodiments of this application includes: a multimodal perception and retrieval module, a generative repair engine, a formal verification engine, and a closed-loop control and feedback module.

[0084] The multimodal perception and retrieval module is used to acquire defective code (i.e., the aforementioned code fragment to be repaired) and its associated runtime logs and telemetry metrics, and retrieves historical repair cases from the knowledge base based on the hybrid similarity of AST structure and semantic vectors; the generative repair engine has a built-in domain-fine-tuned code language model, which is used to generate candidate patches based on the retrieval results and multimodal context; the formal verification engine integrates bounded model verification tools and SMT solvers, which is used to convert candidate patches into intermediate representations and automatically insert security assertions for symbolic execution and mathematical verification; the closed-loop control and feedback module includes a counterexample parsing and exception handling unit, which is used to obtain the counterexample path output by the solver when verification fails or the solution times out, parse it and convert it into negative sample prompts in natural language, and inject it into the generative repair engine to trigger iterative optimization of the patch.

[0085] Below, in conjunction with Figure 5 The implementation examples of the software repair method in the embodiments of this application will be described, such as... Figure 5 As shown, this example includes the following steps: Step 501: Software anomaly / defect detected; Step 502: Extract the defect context and multimodal data; wherein, the defect context includes the aforementioned code segment to be repaired and related information about its complete compilation unit or function scope, and the multimodal data is the aforementioned multimodal context information; Step 503: Based on the extracted information, perform a mixed search in the historical restoration knowledge base to obtain Top-K cases; Step 504: Construct cue words based on Top-K cases; the construction of cue words also requires the extraction of defect context and multimodal data; Step 505: The Code5+ big model generates patches based on the constructed prompts; where Code5+ is the aforementioned generative big model. Step 506: Generate candidate repair patches based on the generated patches; for example, generate candidate repair patches through beam search; Step 507: Convert candidate patch to IR / external library stubbing; that is: convert candidate patch to IR, and stubbing external functions when they are included; Step 508: Insert security assertions (including concurrency) for IR; Step 509: For IRs with inserted security assertions, perform bounded model verification / symbolic execution to generate SMT logic formulas; Step 510: The SMT solver verifies the SMT logic formula; if the verification result is failure, proceed to step 511; if the verification result is timeout or unknown, proceed to step 512; if the verification result is successful, proceed to step 513. Step 511: Extract the counter-example path, convert the counter-example into a negative sample, and re-execute step 504; Step 512: Extract the error status / generate simplified instructions, provide simplification suggestions, and re-execute step 504; Step 513: Output and deploy the fix patch.

[0086] In the example above, steps 502 to 505 are the retrieval enhancement generation stage, and steps 506 to 510 are the formal verification stage.

[0087] In summary, the embodiments of this application disclose a reliable automatic repair method for industrial software based on the coupling of a large model and formal verification, belonging to the interdisciplinary field of industrial internet and software engineering. The method includes: obtaining historical repair cases with semantic and structural similarity to the defective code to be repaired through a hybrid retrieval mechanism; constructing a pre-trained large model of code with prompt words as input, generating candidate repair patches; converting the candidate repair patches into intermediate representations and inserting security attribute assertions, constructing a symbolic execution model using bounded model verification techniques; calling the SMT solver to perform a satisfiability check on the symbolic execution model; if the verification passes, deploying the patch; if the verification fails, extracting counterexample paths and feeding them back to the large model for iterative generation. This application deeply integrates the creativity of generative AI with the mathematical rigor of formal methods, solving the "illusion" and security risks inherent in traditional large models in industrial-grade code repair, ensuring that the repair solution meets over 99.9% usability requirements in industrial scenarios.

[0088] Embodiments of this application also provide a software repair apparatus, such as... Figure 6 As shown, it includes: The acquisition module 601 is used to acquire the code segment to be repaired, as well as the multimodal context information and reference repair cases associated with the code segment to be repaired; The generation module 602 is used to generate at least one candidate repair patch based on the code fragment to be repaired, the multimodal context information, and the reference repair case, using a generative model; wherein the generative model is a domain-adjusted code-large language model. The verification module 603 is used to perform formal verification and solve for each of the candidate repair patches to obtain the verification result corresponding to the candidate repair patch. Repair module 604 is used to repair the code segment to be repaired using the candidate repair patch when the verification result indicates that the candidate repair patch has passed verification; The feedback module 605 is used to provide feedback information to the generative model based on the path information or error status code corresponding to the candidate repair patch when the verification result indicates that the candidate repair patch has failed verification. The feedback information is used to trigger the generative model to optimize the candidate repair patch.

[0089] The acquisition module 601 includes: The first acquisition submodule is used to input the code fragment to be repaired into the semantic vector model and obtain the semantic similarity between the code fragment to be repaired output by the semantic vector model and the historical repair cases in the historical repair case knowledge base; The determination submodule is used to determine the syntactic similarity between the code segment to be repaired and the historical repair case based on the edit distance between the abstract syntax tree (AST) structure features of the code segment to be repaired and the AST structure features corresponding to the historical repair cases. The second acquisition submodule is used to acquire the reference repair case from the historical repair case knowledge base based on the semantic similarity and the syntactic structure similarity.

[0090] The generation module 602 includes: A submodule is constructed to build few-sample prompt words based on the code fragment to be repaired, the multimodal context information, and the reference repair case; The third acquisition submodule is used to input the few-sample prompt words into the generative model to obtain at least one candidate repair patch generated by the generative model; wherein, the generative model is used for: The few-sample prompts are processed using a cross-modal attention mechanism to obtain a cross-modal attention weight matrix; Based on the attention weight matrix, determine the probability distribution of each lexical token generated by the few-sample prompt word; Based on the probability distribution, a beam search is performed on the sample prompt words, and the candidate repair patch is generated based on the search results.

[0091] The device further includes: The first processing module is used to render the attention distribution data corresponding to the probability distribution into a visual heatmap and display the visual heatmap.

[0092] The verification module 603 includes: The processing submodule is used to combine the candidate repair patch with the code segment to be repaired to obtain the combined code, and parse the combined code into a first intermediate representation; The analysis submodule is used to perform static analysis on the first intermediate representation using a static analyzer to obtain static analysis results. An insertion submodule is used to insert security attribute assertions into the first intermediate representation based on the static analysis results and security attributes to obtain a second intermediate representation; The verification submodule is used to perform symbolic execution and bounded model verification on the second intermediate representation, and to call the satisfiability model theory (SMT) solver to verify the satisfiability of the security attribute assertions in the second intermediate representation.

[0093] The analysis submodule includes: The generation unit is used to generate a nondeterministic stub function corresponding to the external function call when the static analyzer fails to resolve the external function call during the static analysis of the first intermediate representation by the static analyzer. A determining unit is used to take the symbolic arbitrary value returned by the nondeterministic stub function as the static analysis result of the external function call.

[0094] The device further includes: The second processing module is configured to, when the verification result indicates that the candidate patch failed verification due to the uncertainty of the external codebase, mark the external function in the first intermediate representation as a manually reviewed area, or, during the generation of the candidate patch, replace the external function.

[0095] The verification result includes cases where the verification fails, the solution times out, or the result is unknown. In such cases, the verification result indicates that the candidate repair patch has not passed the verification. If the verification result includes verification failure, the prompt information is obtained by converting the path information; If the verification result includes the solution timeout or the unknown, the prompt information is obtained by converting the error status code.

[0096] It should be noted that the software repair device provided in this application embodiment can implement all the method steps implemented in the above software repair method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0097] Embodiments of this application also provide a software repair device, such as... Figure 7 As shown, it includes a transceiver 710, a processor 700, a memory 720, and a program or instructions stored in the memory 720 and executable on the processor 700; when the processor 700 executes the program or instructions, it implements the above-mentioned software repair method.

[0098] The transceiver 710 is used to receive and send data under the control of the processor 700.

[0099] Among them, Figure 7In this context, the bus architecture can include any number of interconnected buses and bridges, specifically linking various circuits of one or more processors represented by processor 700 and memory represented by memory 720 together. The bus architecture can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 710 can be multiple elements, including a transmitter and a receiver, providing a unit for communicating with various other devices over a transmission medium.

[0100] The processor 700 is responsible for managing the bus architecture and general processing, while the memory 720 can store the data used by the processor 700 during operation.

[0101] This application provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the steps in the software repair method described above and achieve the same technical effect. To avoid repetition, further details are omitted here.

[0102] The processor mentioned above is the processor in the software repair device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0103] In this embodiment, the module can be implemented in software so that it can be executed by various types of processors. For example, an identified executable code module may include one or more physical or logical blocks of computer instructions, which may be constructed as objects, procedures, or functions. Nevertheless, the executable code of the identified module does not need to be physically located together, but may include different instructions stored in different bits, which, when logically combined, constitute the module and achieve the module's intended purpose.

[0104] Through the above description of the implementation methods, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, disk, optical disk) and includes several instructions for executing the methods described in the various embodiments of this application.

[0105] Therefore, embodiments of this application also provide a computer program product, including computer instructions, which, when executed by a processor, implement the software repair method described above and achieve the same technical effect. To avoid repetition, further details are omitted here.

[0106] In this embodiment, the module can be implemented in software so that it can be executed by various types of processors. For example, an identified executable code module may include one or more physical or logical blocks of computer instructions, which may be constructed as objects, procedures, or functions. Nevertheless, the executable code of the identified module does not need to be physically located together, but may include different instructions stored in different bits, which, when logically combined, constitute the module and achieve the module's intended purpose.

[0107] In practice, an executable code module can be a single instruction or many instructions, and can even be distributed across multiple different code segments, different programs, and across multiple memory devices. Similarly, operational data can be identified within the module and can be implemented in any suitable form and organized within any suitable data structure. This operational data can be collected as a single dataset or distributed across different locations (including different storage devices), and can exist, at least in part, solely as electronic signals within the system or network.

[0108] When a module can be implemented using software, considering the current level of hardware technology, modules that can be implemented in software can be implemented using hardware circuits by those skilled in the art to achieve the corresponding functions, without considering cost. These hardware circuits include conventional very-large-scale integrated circuits (VLSI) or gate arrays, as well as existing semiconductors such as logic chips and transistors, or other discrete components. Modules can also be implemented using programmable hardware devices, such as field-programmable gate arrays, programmable array logic, and programmable logic devices.

[0109] The exemplary embodiments described above are illustrated with reference to the accompanying drawings. Many different forms and embodiments are feasible without departing from the spirit and teachings of this application, and therefore, this application should not be construed as limiting the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided to make this application complete and convey the scope of this application to those skilled in the art. In these drawings, component dimensions and relative dimensions may be exaggerated for clarity. The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, unless explicitly stated otherwise, the singular forms “a,” “an,” and “the” are intended to include all such forms. It will be further understood that the terms “comprising” and / or “including”, when used in this specification, indicate the presence of the stated features, integers, steps, operations, components, and / or elements, but do not exclude the presence or addition of one or more other features, integers, steps, operations, components, elements, and / or groups thereof. Unless otherwise indicated, a range of values ​​is stated to include the upper and lower limits of the range and any subranges therebetween.

[0110] The above description is the preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principles described in this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A software repair method, characterized in that, include: Obtain the code snippet to be repaired, as well as the multimodal context information associated with the code snippet and reference repair cases; Based on the code snippet to be repaired, the multimodal context information, and the reference repair case, at least one candidate repair patch is generated using a generative model; wherein, the generative model is a domain-adjusted code-large language model. For each of the candidate repair patches, formal verification and solution are performed to obtain the verification results corresponding to the candidate repair patch; If the verification result indicates that the candidate patch has passed verification, the candidate patch is used to repair the code segment to be repaired. If the verification result indicates that the candidate patch has failed verification, a prompt message is sent to the generative model based on the path information or error status code corresponding to the candidate patch. The prompt message is used to trigger the generative model to optimize the candidate patch.

2. The method according to claim 1, characterized in that, Obtain reference repair cases associated with the code snippet to be repaired, including: The code fragment to be repaired is input into the semantic vector model to obtain the semantic similarity between the code fragment to be repaired output by the semantic vector model and the historical repair cases in the historical repair case knowledge base; The syntactic similarity between the code segment to be repaired and the historical repair case is determined based on the edit distance between the abstract syntax tree (AST) structural features of the code segment to be repaired and the AST structural features corresponding to the historical repair cases. Based on the semantic similarity and the syntactic structural similarity, the reference repair case is obtained from the historical repair case knowledge base.

3. The method according to claim 1, characterized in that, Based on the code snippet to be repaired, the multimodal context information, and the reference repair case, at least one candidate repair patch is generated, including: Based on the code snippet to be repaired, the multimodal context information, and the reference repair case, construct few-sample prompt words; The few-sample prompt words are input into the generative model to obtain at least one candidate repair patch generated by the generative model; wherein, the generative model is used for: The few-sample prompts are processed using a cross-modal attention mechanism to obtain a cross-modal attention weight matrix; Based on the attention weight matrix, determine the probability distribution of each lexical token generated by the few-sample prompt word; Based on the probability distribution, a beam search is performed on the sample prompt words, and the candidate repair patch is generated based on the search results.

4. The method according to claim 3, characterized in that, After the step of determining the probability distribution of each lexical token generated by the few-sample prompt word based on the attention weight matrix, the method further includes: The attention distribution data corresponding to the probability distribution is rendered into a visual heatmap and displayed.

5. The method according to claim 1, characterized in that, For each candidate repair patch, formal verification and solution are performed to obtain the verification result corresponding to the candidate repair patch, including: The candidate repair patch is combined with the code segment to be repaired to obtain the combined code, and the combined code is parsed into a first intermediate representation; The first intermediate representation is statically analyzed using a static analyzer to obtain the static analysis results. Based on the static analysis results and security attributes, security attribute assertions are inserted into the first intermediate representation to obtain the second intermediate representation; Symbolic execution and bounded model testing are performed on the second intermediate representation, and the satisfiability verification of the security attribute assertions in the second intermediate representation is performed by calling the satisfiability model theory (SMT) solver.

6. The method according to claim 5, characterized in that, Static analysis is performed on the first intermediate representation using a static analyzer to obtain the static analysis results, including: During the static analysis of the first intermediate representation by the static analyzer, if the static analyzer fails to resolve the external function call, a nondeterministic stub function corresponding to the external function call is generated. The symbolic arbitrary value returned by the nondeterministic stub function is used as the static analysis result of the external function call.

7. The method according to claim 6, characterized in that, The method further includes: If the candidate patch verification fails due to the uncertainty of the external codebase, as indicated by the verification result, the external function in the first intermediate representation is marked as a manually reviewed area, or the external function is replaced during the generation of the candidate patch.

8. The method according to claim 1, characterized in that, The verification result includes cases of verification failure, solution timeout, or unknown information, indicating that the candidate repair patch failed the verification. If the verification result includes verification failure, the prompt information is obtained by converting the path information; If the verification result includes the solution timeout or the unknown, the prompt information is obtained by converting the error status code.

9. A software repair device, characterized in that, include: The acquisition module is used to acquire the code segment to be repaired, as well as the multimodal context information and reference repair cases associated with the code segment to be repaired; The generation module is used to generate at least one candidate patch based on the code snippet to be repaired, the multimodal context information, and the reference repair case, using a generative model; wherein the generative model is a domain-adjusted code-large language model. The verification module is used to perform formal verification and solve for each of the candidate repair patches to obtain the verification result corresponding to the candidate repair patch. The repair module is used to repair the code segment to be repaired using the candidate repair patch when the verification result indicates that the candidate repair patch has passed verification. The feedback module is used to provide feedback information to the generative model based on the path information or error status code corresponding to the candidate repair patch when the verification result indicates that the candidate repair patch has failed verification. The feedback information is used to trigger the generative model to optimize the candidate repair patch.

10. A software repair device, comprising a transceiver, a processor, a memory, and a program stored in the memory and executable on the processor; characterized in that, The transceiver is used to send and receive data under the control of the processor, and the processor implements the software repair method as described in any one of claims 1 to 8 when executing the program.

11. A readable storage medium having a program or instructions stored thereon, characterized in that, When the program or instructions are executed by the processor, they implement the software repair method as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the software repair method as described in any one of claims 1 to 8.

Images