A code defect analysis and repair method and system based on a large language model

Abstract

This invention discloses a code defect analysis and repair method and system based on a large language model. The method includes: receiving crash information triggered by fuzzing or program execution, and performing crash analysis to obtain crash analysis results; obtaining key defect analysis information based on the crash analysis results, and constructing structured defect analysis information based on the key defect analysis information; inputting the structured defect analysis information into a defect analysis model, and performing reasoning analysis on the code defects according to a three-round reasoning strategy to obtain defect analysis results; searching a historical repair database based on the defect analysis results to obtain historical repair retrieval results, and inputting the defect analysis results and historical repair retrieval results into a patch generation model to generate candidate patch code; performing sandbox verification on the candidate patch code to obtain valid patch code and patch verification results, and outputting an analysis and repair report based on the defect analysis results, valid patch code, and patch verification results.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and in particular to a method and system for code defect analysis and repair based on a large language model. Background Technology

[0002] Root cause analysis and remediation of software defects are crucial aspects of software quality assurance. However, current methods still rely heavily on manual analysis or single tools, and have the following shortcomings: Manual analysis: Engineers typically need to understand crash information, log data, and code logic to pinpoint the root cause of defects. For complex functions or programs with long call chains, this process can be time-consuming and inefficient, and the analysis results may differ between engineers. Furthermore, manual intervention in the core code analysis process may increase the risk of code leaks.

[0003] Static analysis tools, such as Coverity and SonarQube, can report defect types, such as null pointer exceptions and memory leaks, but they typically struggle to provide root cause analysis and remediation suggestions for specific crash scenarios. These tools are more useful for pinpointing potential problem locations and are less effective at explaining the underlying causes of defects or directly performing automated repairs.

[0004] Traditional fuzzing tools, such as AFL and LibFuzzer, can detect program crashes or abnormal input, but they typically cannot automatically analyze the underlying causes of the crashes. Developers still need to manually investigate by combining crash input, call stack, and source code logic to pinpoint the root cause of the problem.

[0005] Single-point application of large language models: In recent years, some solutions have attempted to directly generate code patches using large language models. However, this approach may suffer from unstable generation results, such as generated patches that do not meet compilation requirements or the original code logic. Furthermore, existing methods are mostly one-time generation, lacking constraint mechanisms and patch verification mechanisms that incorporate historical repair experience, leading to insufficient reliability of the repair results.

[0006] Lack of end-to-end automated repair system: Existing solutions usually cannot achieve full-process automation from crash input, root cause analysis, patch generation to patch verification. Multiple links still require manual intervention, making it difficult to form a stable automated analysis and repair closed loop.

[0007] Therefore, there is an urgent need for a code defect analysis and repair method and system based on a large language model. Summary of the Invention

[0008] This invention addresses the problems and shortcomings of existing technologies by providing a code defect analysis and repair method and system based on a large language model. It can achieve automated closed-loop processing from crash information parsing, defect root cause analysis, effective patch generation to patch verification, thereby improving the accuracy and efficiency of code defect analysis and repair.

[0009] The technical solution adopted by this invention to solve the above-mentioned technical problems is to provide a code defect analysis and repair method based on a large language model, which includes the following steps: Receive and parse crash information, receive crash information triggered by fuzzing or program execution, and perform crash analysis on the crash information to obtain crash analysis results. The crash analysis results include exception type, call stack information, crash location information, crash running status information, and trigger input association information. Construct structured defect analysis information. Based on the crash analysis results, obtain key defect analysis information, which includes at least exception type, crash location information, target function source code, and runtime variable information. Determine the crash point statement in the target function source code based on the crash location information, and determine the key variable that caused the crash based on the exception type or runtime variable information. Slice the target function source code using a static backward slicing algorithm based on the crash point statement and the key variable to obtain sliced ​​code information related to the key variable. Construct structured defect analysis information based on the key defect analysis information and the sliced ​​code information. Root cause reasoning involves inputting the structured defect analysis information into a defect analysis model based on a large language model, and performing reasoning analysis on code defects according to a three-round reasoning strategy. The output of the first round reasoning strategy is a first structured output including defect type and confidence level. Based on the first structured output, the output of the second round reasoning strategy includes a second structured output including the location of the main defect. Based on the first and second structured outputs, the output of the third round reasoning strategy includes a third structured output including root cause analysis results and trigger condition chains. The defect analysis result is generated based on the first, second, and third structured outputs. Defect repair involves constructing historical repair retrieval conditions based on the defect analysis results, searching the historical repair database to obtain matching historical repair cases, extracting historical repair patterns based on the historical repair cases, generating historical repair retrieval results, and inputting the defect analysis results and historical repair retrieval results into the patch generation model to generate candidate patch codes within the range corresponding to the main defect locations. The results output includes sandbox verification of the candidate patch code in a sandbox environment to obtain valid patch code and patch verification results, and outputting an analysis and repair report based on the defect analysis results, valid patch code and patch verification results.

[0010] Preferably, based on the crash analysis results, key defect analysis information is obtained, including: Extract the exception type and crash location information from the crash analysis results; Based on the call stack information and crash location information in the crash analysis results, the source file path, function name and line number corresponding to the crash point are determined, and the source code of the target function is obtained according to the source file path and function name; Based on the line number in the crash location information, extract the code fragment near the crash point from the source code of the target function; Based on the function call level, function name, and line number in the call stack information, call stack path information is generated; Based on the function name, source file path, and line number in the call stack path information, obtain the call stack associated code segment; Based on the trigger input association information, obtain the crash input data that triggers the crash information; Based on the crash running status information, obtain runtime variable information.

[0011] Preferably, the first round of inference strategy includes: inputting the exception type, call stack path information, code fragments near the crash point and runtime variable information from the structured defect analysis information into the defect analysis model to infer the defect type and obtain a first structured output, wherein the first structured output includes the defect type, confidence level and reason for defect type inference; The second round of reasoning strategy includes: inputting the first structured output, the source code of the target function, the code snippet near the crash point, the code snippet associated with the call stack, and the crash location information into the defect analysis model to locate the code location that caused the defect and obtain the second structured output, which includes the main defect location and the reason for the location location; The third round of reasoning strategy includes: inputting the first structured output, the second structured output, call stack path information, call stack associated code fragments, crash input data and runtime variable information into the defect analysis model to analyze the root cause of the defect and obtain the third structured output, which includes the root cause analysis results and the trigger condition chain. Defect analysis results are generated based on the first structured output, the second structured output, and the third structured output.

[0012] Preferably, when the confidence level in the first structured output is lower than a preset confidence threshold, a candidate defect type is determined based on the mapping relationship between the anomaly type and the preset defect type, and the candidate defect type is used as the input of the second round of reasoning strategy.

[0013] Preferably, when the number of lines of code in the target function source code is greater than a preset line number threshold, a static backward slicing algorithm is used to slice the target function source code, and the sliced ​​target function source code is used to replace the target function source code to construct the structured defect analysis information; When the source code of the target function contains a loop structure or a recursive call structure, and the nesting level of the loop structure or the call chain length of the recursive call structure is greater than a preset level threshold, the static backward slicing algorithm is used to slice the source code of the target function, and the sliced ​​source code of the target function is used to replace the source code of the target function to construct the structured defect analysis information.

[0014] Preferably, the static backward slicing algorithm is used to slice the source code of the target function based on the crash point statement and the key variables, including: The source code of the objective function is divided into multiple basic blocks, and a control flow graph of the objective function source code is constructed based on the control flow jump relationship between the multiple basic blocks. The basic blocks are the nodes of the control flow graph of the objective function source code, and the control flow jump relationship is the edge of the control flow graph of the objective function source code. A data flow graph of the target function source code is constructed based on the variables in the target function source code and the data dependencies between the variables. The variables are the nodes of the target function source code data flow graph, and the data dependencies between the variables are the edges of the target function source code data flow graph. The data dependencies between the variables include assignment relationships, calculation relationships, function parameter passing relationships, or function return relationships between the variables. Based on the crash location information, the crash point statement is determined in the source code of the target function, and the key variable causing the crash is determined based on the exception type or runtime variable information; Using the crash point statement and key variables as slicing criteria, starting from the crash point statement, a reverse traversal is performed based on the target function source code control flow graph and target function source code data flow graph to collect code statements that define the key variables, code statements that have data dependencies on the key variables, and control condition statements that control the execution of the crash point statement. Arrange the collected code statements and control condition statements in the original order of the target function source code to obtain the sliced ​​code information.

[0015] Preferably, receiving and parsing the crash information includes: The call stack in the crash information is parsed to extract function names, line numbers, and module identifiers to obtain the call stack information. Based on the name of the function at the top of the stack, the line number of the code at the top of the stack, or the identifier of the crashed thread in the call stack information, the crash location information is determined; Identify the exception type based on the error code or exception message in the crash information; Based on the register status information, core dump file or memory error report in the crash information, extract the crash running status information, which includes at least one of register values, memory access address, access size and access range; The crash information is associated with the input file or input data that triggered the crash to obtain the trigger input association information; The crash analysis result is generated based on the exception type, call stack information, crash location information, crash running status information, and trigger input association information.

[0016] Preferably, the step of retrieving historical repair results from the historical repair database based on the defect analysis results includes: Based on the defect type, defect location, and root cause analysis results in the defect analysis results, historical repair retrieval conditions are constructed. Retrieve historical repair cases that match the historical repair search criteria from the historical repair database. The historical repair cases include historical defect types, historical function signatures, code snippets before and after repair. Perform a difference analysis on the code snippets before and after the repair to extract historical repair patterns; The historical repair search results are generated based on the historical repair cases and historical repair patterns.

[0017] This invention also provides a code defect analysis and repair system based on a large language model, the system comprising: The crash information receiving and parsing module receives crash information triggered by fuzzing or program execution, and performs crash parsing on the crash information to obtain crash parsing results. The crash parsing results include exception type, call stack information, crash location information, crash running status information, and trigger input association information. A structured defect analysis information module is constructed. Based on the crash analysis results, key defect analysis information is obtained. The key defect analysis information includes at least the exception type, crash location information, target function source code, and runtime variable information. The crash point statement is determined in the target function source code based on the crash location information, and the key variable causing the crash is determined based on the exception type or runtime variable information. Based on the crash point statement and the key variable, the target function source code is sliced ​​using a static backward slicing algorithm to obtain sliced ​​code information related to the key variable. The structured defect analysis information is constructed based on the key defect analysis information and the sliced ​​code information. The root cause reasoning module inputs the structured defect analysis information into a defect analysis model based on a large language model, and performs reasoning analysis on code defects according to a three-round reasoning strategy. The output of the first round reasoning strategy is a first structured output including defect type and confidence level. Based on the first structured output, the output of the second round reasoning strategy includes a second structured output including the location of the main defect. Based on the first and second structured outputs, the output of the third round reasoning strategy includes a third structured output including root cause analysis results and trigger condition chains. The defect analysis result is generated based on the first, second, and third structured outputs. The defect repair module constructs historical repair retrieval conditions based on the defect analysis results, searches the historical repair database to obtain matching historical repair cases, extracts historical repair patterns based on the historical repair cases, generates historical repair retrieval results, and inputs the defect analysis results and historical repair retrieval results into the patch generation model to generate candidate patch codes within the range corresponding to the main defect locations. The results output module performs sandbox verification on the candidate patch code in a sandbox environment to obtain the valid patch code and patch verification results, and outputs an analysis and repair report based on the defect analysis results, valid patch code and patch verification results.

[0018] Compared with the prior art, the technical solution of the embodiments of the present invention has the following beneficial effects: This invention provides a code defect analysis and repair method and system based on a large language model. The method includes: receiving and parsing crash information; receiving crash information triggered by fuzzing or program execution; performing crash analysis on the crash information to obtain crash analysis results, the crash analysis results including exception type, call stack information, crash location information, crash running state information, and trigger input association information; constructing structured defect analysis information; based on the crash analysis results, obtaining key defect analysis information, and constructing structured defect analysis information based on the key defect analysis information, the key defect analysis information including exception type, crash location information, call stack path information, target function source code, code snippets near the crash point, and call stack associated code snippets. The process involves several steps: 1) compiling crash input data and runtime variable information; 2) root cause reasoning: inputting the structured defect analysis information into a defect analysis model based on a large language model, and performing reasoning analysis on code defects according to a three-round reasoning strategy to obtain defect analysis results including defect type, defect location, and root cause analysis results; 3) defect repair: retrieving historical repair results from a historical repair database based on the defect analysis results, and inputting the defect analysis results and historical repair retrieval results into a patch generation model to generate candidate patch code; 4) result output: performing sandbox verification on the candidate patch code in a sandbox environment to obtain valid patch code and patch verification results, and outputting an analysis and repair report based on the defect analysis results, valid patch code, and patch verification results. This invention constructs structured defect analysis information from crash information parsing results, code information, crash input data, and runtime variable information, enabling the defect analysis model to perform root cause reasoning based on complete and corresponding multi-source information, avoiding reliance on a single crash log or human experience for judgment. By employing a three-round reasoning strategy to sequentially obtain defect type, defect location, and root cause analysis results, the defect analysis process is transformed from a single judgment into a phased, transferable reasoning process, thereby improving the accuracy and interpretability of crash defect root cause localization. Simultaneously, by retrieving similar historical repair cases from a historical repair database and combining the historical repair retrieval results to generate candidate patch code, the instability issues that may exist when generating patches independently using a large language model can be reduced, improving the matching degree between candidate patch code and the current defect scenario. Furthermore, by using a sandbox to verify and output patch verification results and analysis and repair reports, it is beneficial to form an automated closed loop from crash analysis, root cause localization, patch generation to patch verification, reducing the cost of manual investigation and manual repair.

[0019] Furthermore, this invention obtains the target function source code, code snippets near the crash point, call stack-related code snippets, crash input data, and runtime variable information by using call stack information, crash location information, trigger input association information, and crash running state information. This establishes a clear data correspondence between the crash analysis results and the structured defect analysis information. When the target function source code is long or contains complex loops or recursive structures, this invention employs a static backward slicing algorithm to extract code information related to the crash point statement and key variables, reducing the interference of irrelevant code content on the defect analysis model and alleviating the problem of excessively long analysis context for complex functions. Simultaneously, by combining the inference results of the large language model with historical repair experience through low-confidence backoff, historical repair database retrieval, and historical repair pattern extraction, the instability or "illusion" problems that may occur when the large language model generates patches at a single point can be reduced, improving the matching degree between candidate patch code and the current defect scenario.

[0020] Furthermore, after generating candidate patch code, this invention performs compilation verification, original defect reproduction verification, and coverage checks on the candidate patch code in a sandbox environment, and outputs an analysis and repair report based on the verification results, thus forming an automated closed loop from crash information parsing, root cause analysis, candidate patch generation to patch verification. This method can, to a certain extent, replace the traditional processing flow that relies on manual investigation and manual repair, improve the efficiency of software defect analysis and repair, reduce the risk of leakage caused by manual intervention in core code, and can be used in conjunction with fuzzing tools or CI / CD pipelines to continuously accumulate historical repair cases and improve the accuracy and reliability of subsequent defect repairs. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention, but not all embodiments. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 The flowchart illustrates a preferred embodiment of the code defect analysis and repair method based on a large language model according to the present invention.

[0023] Figure 2 This is a schematic diagram of the architecture of a code defect analysis and repair system based on a large language model, which is a preferred embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] The technical solution of the present invention will be described in detail below with reference to specific embodiments.

[0026] To address the problems existing in the current technology, this invention provides a code defect analysis and repair method and system based on a large language model. This system can achieve automated closed-loop processing from crash information parsing, defect root cause analysis, effective patch generation to patch verification, thereby improving the accuracy and efficiency of code defect analysis and repair.

[0027] Now see Figure 1 This invention provides a code defect analysis and repair method based on a large language model, comprising the following steps: Step S101: Receive and parse crash information. Receive crash information triggered by fuzzing or program execution, and perform crash parsing on the crash information to obtain crash parsing results. The crash parsing results include exception type, call stack information, crash location information, crash running status information, and trigger input association information.

[0028] In this step, crash information triggered by fuzzing or program execution is received and parsed to obtain crash parsing results including exception type, call stack information, crash location information, crash running status information, and trigger input association information.

[0029] The receiving and parsing of crash information includes: The call stack in the crash information is parsed to extract function names, line numbers, and module identifiers to obtain the call stack information.

[0030] Based on the name of the function at the top of the stack, the line number of the code at the top of the stack, or the identifier of the crashed thread in the call stack information, the crash location information is determined.

[0031] The exception type is identified based on the error code or exception message in the crash information. For example, the error type includes SEGV, ABORT, or ASSERT. SEGV is used to indicate a segmentation fault, ABORT is used to indicate abnormal program termination, and ASSERT is used to indicate an assertion failure.

[0032] Based on the register status information, core dump file, or memory error report in the crash information, crash runtime status information is extracted. This crash runtime status information includes at least one of register values, memory access addresses, access sizes, and access ranges. In one implementation, when the Sanitizer tool is used to obtain a memory error report, the memory error report is parsed to obtain at least one of out-of-bounds access addresses, access sizes, access boundaries, memory allocation stacks, or memory deallocation stacks. The parsing results are then stored in a structured manner as part of the crash runtime status information.

[0033] The crash information is associated with the input file or input data that triggered the crash to obtain the trigger input association information.

[0034] The crash analysis result is generated based on the exception type, call stack information, crash location information, crash running status information, and trigger input association information.

[0035] Step S102: Construct structured defect analysis information. Based on the crash analysis results, obtain key defect analysis information. The key defect analysis information includes at least the exception type, crash location information, target function source code, and runtime variable information. Determine the crash point statement in the target function source code based on the crash location information, and determine the key variable that caused the crash based on the exception type or runtime variable information. Slice the target function source code using a static backward slicing algorithm based on the crash point statement and the key variable to obtain the sliced ​​code information related to the key variable. Construct structured defect analysis information based on the key defect analysis information and the sliced ​​code information.

[0036] In this step, based on the crash analysis results, multi-source information related to the crash event is acquired and organized to form structured defect analysis information that can be processed by the subsequent defect analysis model. Specifically, based on the exception type, call stack information, crash location information, crash running state information, and trigger input association information in the crash analysis results, key defect analysis information is acquired, including exception type, crash location information, call stack path information, target function source code, code snippets near the crash point, call stack associated code snippets, crash input data, and runtime variable information. This key defect analysis information is then structured to obtain structured defect analysis information.

[0037] In this embodiment, when the target function source code has a large amount of data, or when there are complex loop structures or recursive call structures in the target function source code, a static backward slicing algorithm is used to slice the corresponding code information to extract code information related to the crash point statement and key variables. The sliced ​​code information is then used to replace the corresponding original code information to participate in the construction of structured defect analysis information, thereby reducing the interference of irrelevant code content on the subsequent root cause reasoning process and improving the relevance of the input information of the defect analysis model.

[0038] In this embodiment, a large amount of source code data for the target function means that the number of lines of code in the target function source code is greater than a preset line number threshold, such as greater than 200 lines; a complex loop structure or recursive call structure can mean that the nesting level of the loop structure or the call chain length of the recursive call structure is greater than a preset level threshold, such as a preset level threshold of 3 levels.

[0039] The nesting level of loop structures represents the depth of nesting between loop statements. For example, when one loop statement contains another loop statement, its nesting level increases accordingly. The call chain length of recursive call structures represents the length of the call path from the current function call to the function with the same name or the recursively related function, reflecting the expansion level of the recursive call structure.

[0040] In this embodiment, based on the crash analysis results, key defect analysis information is obtained, including: Extract the exception type and crash location information from the crash analysis results; Based on the call stack information and crash location information in the crash analysis results, the source file path, function name and line number corresponding to the crash point are determined, and the source code of the target function is obtained according to the source file path and function name; Based on the line number in the crash location information, extract the code fragment near the crash point from the source code of the target function; Based on the function call level, function name, and line number in the call stack information, call stack path information is generated; Based on the function name, source file path, and line number in the call stack path information, obtain the call stack associated code segment; Based on the trigger input association information, obtain the crash input data that triggers the crash information; Based on the crash running status information, obtain runtime variable information.

[0041] In one implementation, the process of obtaining the source code of the target function and the code fragment near the crash point includes: reading the corresponding source file from the version control system or local source code directory based on the source file path, function name and line number in the call stack information; determining the target function where the crash point is located based on the crash location information, and extracting the source code of the target function.

[0042] When the number of lines of code in the objective function is not greater than a preset line count threshold (e.g., 200 lines), the complete source code of the objective function will be used as the source code of the objective function participating in the construction of structured defect analysis information.

[0043] The code snippet near the crash point is extracted from the target function's source code based on the line number in the crash location information. Specifically, with the line corresponding to the crash location information as the center, code content within a preset range before and after that line is extracted to obtain the code snippet near the crash point. For example, the preset range can be 20 lines before and 20 lines after the center line.

[0044] When the number of lines of code in the target function source code exceeds a preset line number threshold (e.g., 200 lines), the static backward slicing algorithm is used to slice the target function source code, and the sliced ​​target function source code is used to replace the target function source code to construct the structured defect analysis information. When the source code of the target function contains a loop structure or a recursive call structure, and the nesting level of the loop structure or the call chain length of the recursive call structure is greater than a preset level threshold (e.g., the preset level threshold is 3 levels), the static backward slicing algorithm is used to slice the source code of the target function, and the sliced ​​source code of the target function is used to replace the source code of the target function to construct the structured defect analysis information.

[0045] The step of slicing the source code of the objective function using a static backward slicing algorithm includes: The source code of the objective function is divided into multiple basic blocks, and a control flow graph of the objective function source code is constructed based on the control flow jump relationship between the multiple basic blocks. The basic blocks are the nodes of the control flow graph of the objective function source code, and the control flow jump relationship is the edge of the control flow graph of the objective function source code. A data flow graph of the target function source code is constructed based on the variables in the target function source code and the data dependencies between the variables. The variables are the nodes of the target function source code data flow graph, and the data dependencies between the variables are the edges of the target function source code data flow graph. The data dependencies between the variables include assignment relationships, calculation relationships, function parameter passing relationships, or function return relationships between the variables. Based on the crash location information, the crash point statement is determined in the source code of the target function, and the key variable causing the crash is determined based on the exception type or runtime variable information; Using the crash point statement and key variables as slicing criteria, starting from the crash point statement, a reverse traversal is performed based on the target function source code control flow graph and target function source code data flow graph to collect code statements that define the key variables, code statements that have data dependencies on the key variables, and control condition statements that control the execution of the crash point statement. Arrange the collected code statements and control condition statements in the original order of the target function source code to obtain the sliced ​​code information.

[0046] In one implementation, the process of obtaining call stack-associated code fragments includes: reading the source files corresponding to each call stack level from the version control system or local source code directory based on the function call level, function name, source file path, and line number in the call stack path information; determining the call position corresponding to each call stack level in the corresponding source file according to the function name and line number corresponding to each call stack level; extracting the code content within a preset range (e.g., 20 lines) before and after the line of code corresponding to the call position, centered on the line of code, to obtain the code fragments corresponding to each call stack level; and organizing the code fragments corresponding to each call stack level in sequence according to the function call level to obtain the call stack-associated code fragments.

[0047] In this implementation, the call stack associated code snippets are used to characterize the function call path before the crash occurs, as well as the transmission process of abnormal parameters, abnormal return values, or abnormal states in the call chain. For example, when the call stack path information includes the first-level call function, the second-level call function, and the target function where the crash point is located, code snippets related to the next-level function call statements in each level of call function can be extracted and written into the structured defect analysis information according to the call hierarchy, so that the subsequent defect analysis model can combine the call path for root cause reasoning.

[0048] In one implementation, the process of obtaining runtime variable information includes: when a core dump file exists, calling the debugger interface to load the core dump file and the corresponding symbol file, and switching to the call stack frame of the crashed thread; extracting the local variable values ​​and function parameter values ​​at the crash point, and recording the corresponding variable types and memory addresses; and also extracting machine instruction information near the crash point to assist in subsequent defect analysis.

[0049] In one specific implementation, the debugger interface can be the Python API of GDB, and the values ​​of local variables and function parameters can be obtained through info locals and info args.

[0050] In one specific implementation, the Sanitizer tool can be AddressSanitizer, and the structured storage format can be JSON.

[0051] In one implementation, structured defect analysis information can be represented using structured objects, such as JSON objects, for storage or transmission.

[0052] Step S103: Root cause reasoning. The structured defect analysis information is input into the defect analysis model based on a large language model, and the code defect is reasoned and analyzed according to a three-round reasoning strategy. The output of the first round reasoning strategy is a first structured output including defect type and confidence level. Based on the first structured output, the output of the second round reasoning strategy includes a second structured output including the location of the main defect. Based on the first and second structured outputs, the output of the third round reasoning strategy includes a third structured output including the root cause analysis result and the trigger condition chain. The defect analysis result is generated based on the first, second, and third structured outputs.

[0053] In this step, the defect analysis model is a code defect analysis model built based on a large language model, where the large language model is a language model with code understanding and natural language reasoning capabilities. This embodiment does not limit the specific model name, model parameter scale, or network structure of the large language model, as long as it can perform defect type inference, defect location localization, and root cause analysis based on the input structured defect analysis information.

[0054] To improve the stability and interpretability of the root cause reasoning process, this embodiment does not directly generate the final conclusion by inputting all structured defect analysis information into the defect analysis model at once. Instead, it performs staged reasoning based on a three-round reasoning strategy, following the order of defect type inference, defect location localization, and root cause analysis.

[0055] The input of the second round reasoning strategy includes the first structured output of the first round reasoning strategy, and the input of the third round reasoning strategy includes the first structured output of the first round reasoning strategy and the second structured output of the second round reasoning strategy. The defect analysis results include at least the defect type of the first structured output, the defect location of the second structured output, and the root cause analysis results of the third structured output.

[0056] The first round of inference strategy includes: inputting the exception type, call stack path information, code fragments near the crash point and runtime variable information from the structured defect analysis information into the defect analysis model to infer the defect type and obtain a first structured output, wherein the first structured output includes the defect type, confidence level and reason for defect type inference.

[0057] In this implementation, the first-round inference strategy is used to infer the defect type. The input to the first-round inference strategy is a structured input based on the exception type, call stack path information, code snippets near the crash point, and runtime variable information. The first-round structured input can be represented as a JSON object, a key-value pair structure, or a table structure. For example: { "round": 1, "exception_type": "SEGV", "call_stack": [ "main:line10", "parse_request:line25", "get_user_name:line42" ], "crash_code_snippet": "return names[user_id];", "runtime_vars": { "user_id": -1 } } Among them, exception_type is used to represent the exception type; call_stack is used to represent the call stack path information; crash_code_snippet is used to represent the code snippet near the crash point; and runtime_vars is used to represent runtime variable information.

[0058] The first structured output is in JSON format, for example: { "round": 1, "defect_type": "buffer_overflow", "confidence": 0.92, "reason": "The crash point used user_id as an array index, and user_id was -1, leading to out-of-bounds access." } Here, `defect_type` represents the defect type; `confidence` represents the confidence level corresponding to the defect type; and `reason` represents the reason for inferring the defect type. The above JSON object is merely an example and does not limit the specific data format of the first round of structured input or the first structured output.

[0059] When the confidence level in the first structured output is lower than the preset confidence threshold (e.g., the preset confidence threshold is 0.6), the candidate defect type is determined based on the mapping relationship between the anomaly type and the preset defect type, and the candidate defect type is used as the input of the second round of inference strategy.

[0060] In this embodiment, a preset defect type mapping relationship is used to characterize the correspondence between exception types and candidate defect types. For example, when the exception type is SEGV, the candidate defect types are determined to include null pointer dereference or buffer overflow; when the exception type is ABORT, the candidate defect types are determined to include assertion failure or program abnormal termination related defects; when the exception type is ASSERT, the candidate defect types are determined to include assertion failure or condition check failure related defects.

[0061] The second round of reasoning strategy includes: inputting the first structured output, the source code of the target function, the code snippet near the crash point, the code snippet associated with the call stack, and the crash location information into the defect analysis model to locate the code location that caused the defect and obtain the second structured output, which includes the main defect location and the reason for the location.

[0062] In this embodiment, the second-round inference strategy is used to locate the defect. The input to the second-round inference strategy is a second-round structured input based on the first structured output, code information, crash location information, and call stack path information. The second-round structured input can be in JSON format, for example: { "round": 2, "previous_output": { "defect_type": "buffer_overflow", "reason": "The crash point used user_id as an array index, and user_id was -1, leading to out-of-bounds access." }, "code_snippet": "38: char name = get_user_name(user_id);\n42:return names[user_id];", "crash_line": 42, "call_stack": [ "main:line10", "parse_request:line25", "get_user_name:line42" ] } Among them, previous_output is used to represent the defect type and the reason for the defect type inference in the first structured output; code_snippet is used to represent code information with code line numbers; crash_line is used to represent the code line number where the crash point is located; and call_stack is used to represent the call stack path information.

[0063] The second-round inference strategy, based on the second-round structured input, locates the code position causing the defect and outputs the defect position and the reason for its location. In one implementation, the second-round inference strategy supports outputting multiple candidate defect positions and determining the primary defect position from among them. Specifically, the multiple candidate defect positions can be sorted according to their proximity to the crash location information, whether the code statement corresponding to the candidate defect position directly uses key variables, and whether the candidate defect position matches the defect type in the first structured output. The candidate defect position with the highest ranking is then determined as the primary defect position.

[0064] For example, when the defect type is buffer overflow, if the code statement corresponding to a candidate defect location directly uses the exception index variable in the runtime variable information to access the array, and the code line is the same as or close to the code line corresponding to the crash location information, then the candidate defect location is determined as the primary defect location.

[0065] The output of the second round of reasoning strategy, for example: { "round": 2, "locations": [ { "line": 42, "code": "return names[user_id];", "reason": "user_id was used as an index without verification." }, { "line": 38, "code": "char name = get_user_name(user_id);", "reason": "The passed-in user_id may be negative." } ], "primary_line": 42 } Here, `locations` represents the set of candidate defect locations, with each candidate defect location including the line number, code content, and reason for locating the location; `primary_line` represents the primary defect location. The above JSON object is merely an example and does not limit the specific data format of the second-round structured input or the second-round structured output.

[0066] The third round of reasoning strategy includes: inputting the first structured output, the second structured output, call stack path information, call stack associated code fragments, crash input data, and runtime variable information into the defect analysis model to analyze the root cause of the defect and obtain the third structured output, which includes the root cause analysis results and the trigger condition chain.

[0067] In this embodiment, the third-round inference strategy is used for root cause analysis. The input to the third-round inference strategy is a third-round structured input based on the first structured output, the second structured output, code information, call stack path information, call stack associated code fragments, and runtime variable information. For example, the input to the third-round inference strategy might be: { "round": 3, "previous_outputs": { "defect_type": "buffer_overflow", "defect_reason": "The crash point used user_id as an array index, and user_id was -1, resulting in out-of-bounds access." "locations": [ { "line": 42, "code": "return names[user_id];", "reason": "user_id was used as an index without verification." } ], "primary_line": 42 }, "code_snippet": "38: char name = get_user_name(user_id);\n42:return names[user_id];", "call_stack": [ "main:line10", "parse_request:line25", "get_user_name:line42" ], "runtime_vars": { "user_id": -1 } } Among them, previous_outputs is used to represent the defect type, the reason for the defect type inference, the candidate defect location, and the main defect location in the first and second structured outputs; code_snippet is used to represent code information with line numbers; call_stack is used to represent call stack path information; and runtime_vars is used to represent runtime variable information.

[0068] The third-round reasoning strategy, based on the third-round structured input, analyzes the root cause of the defect, generating root cause analysis results and trigger condition chains. Specifically, the defect analysis model, based on defect type, defect location, call stack path information, call stack associated code segments, and runtime variable information, analyzes the source, transmission process, and missing verification or processing code links of abnormal variables or abnormal states, thereby determining the root cause of the defect.

[0069] The output of the third round of reasoning strategy, for example: { "round": 3, "root_cause": "Input validation is missing. The function get_user_name assumes that the passed user_id is always within a valid range, but the caller does not guarantee this condition. The trigger condition is user_id=-1 or user_id>=MAX_USERS." "trigger_chain": [ "main() reads user input -1", "Get_user_name was called without checking the scope". "Use the user_id index array within the function", "Overstepping boundaries leads to SEGV" ], "suggested_fix_pattern": "add_boundary_check" } Here, `root_cause` represents the root cause analysis result, `trigger_chain` represents the chain of triggering conditions from crash input, call path, and exception variables to the crash occurrence, and `suggested_fix_pattern` represents the suggested fix pattern. The above JSON object is merely an example and does not limit the specific data format of the third-round structured input or the third-round structured output.

[0070] Defect analysis results are generated based on the first structured output, the second structured output, and the third structured output.

[0071] In this embodiment, generating defect analysis results based on the first structured output, the second structured output, and the third structured output refers to summarizing and organizing the defect types in the first structured output, the defect locations in the second structured output, and the root cause analysis results in the third structured output to form defect analysis results for subsequent historical repair retrieval and candidate patch generation. Specifically, the third structured output provides the root cause analysis results, while the first and second structured outputs supplement the defect types and defect locations, respectively.

[0072] Step S104: Defect Repair. Based on the defect analysis results, construct historical repair retrieval conditions, search the historical repair database to obtain matching historical repair cases, extract historical repair patterns based on the historical repair cases, generate historical repair retrieval results, input the defect analysis results and historical repair retrieval results into the patch generation model, and generate candidate patch codes within the range corresponding to the main defect locations.

[0073] In this step, the historical fix database is used to store historical fix cases, which include historical defect types, historical function signatures, code snippets before and after the fix. By retrieving historical fix cases that match the current defect analysis results, fix references can be provided for the generation of subsequent candidate patch code.

[0074] The process of searching the historical repair database based on the defect analysis results to obtain historical repair search results includes: Based on the defect type, defect location, and root cause analysis results in the defect analysis, historical repair retrieval conditions are constructed.

[0075] The historical repair database is used to retrieve historical repair cases that match the historical repair retrieval criteria. These historical repair cases include historical defect types, historical function signatures, pre-repair code snippets, and post-repair code snippets. In one implementation, a vector retrieval method is used for similarity matching. For example, the CodeBERT model is used to encode the code information corresponding to the current defect and the pre-repair code snippets in historical repair cases, and similar historical repair cases are determined based on vector similarity.

[0076] Perform a difference analysis on the code snippets before and after the repair to extract historical repair patterns; The historical restoration retrieval results are generated based on the historical restoration cases and historical restoration patterns. In this embodiment, the historical restoration retrieval results include matching historical restoration cases and historical restoration patterns extracted from the historical restoration cases.

[0077] After obtaining the historical repair retrieval results, the defect analysis results and historical repair retrieval results are input into the patch generation model to generate candidate patch code.

[0078] In this embodiment, the patch generation model is a code patch generation model built based on a large language model. The patch generation model is used to generate candidate patch code based on defect analysis results and historical repair retrieval results. This embodiment does not limit the specific model name, model parameter scale, or network structure of the large language model corresponding to the patch generation model, as long as it can generate candidate patch code based on the input defect type, defect location, root cause analysis results, similar historical repair cases, and historical repair patterns.

[0079] In one implementation, the defect analysis results and historical repair retrieval results are input into the patch generation model to generate candidate patch code, including: Based on the root cause analysis results in the defect analysis results, the historical repair examples in the historical repair retrieval results, and the code snippet to be repaired, the patch generation input information is constructed. Input the patch generation information into the patch generation model, which then generates one or more candidate patch codes. Each candidate patch code includes the modification location and the modification content. For each candidate patch code, its corresponding modification location and content are recorded, and a corresponding compilation script is generated. This compilation script is used to compile and verify the source code after applying the candidate patch code during subsequent sandbox verification; for example, the compilation script can be a Makefile.

[0080] When the patch generation model generates multiple candidate patch codes, these codes are sorted to obtain a sorted list of candidate patches. The sorting process comprehensively considers syntax correctness, code style similarity, modification complexity, historical fix success rate, and semantic similarity, assigning a weight to each metric. A weighted scoring method is used to calculate a comprehensive score for each candidate patch code, and the sorted list of candidate patch codes is output based on this comprehensive score.

[0081] Among them, syntax correctness is used to characterize whether the candidate patch code can pass the compilation check, code style similarity is used to characterize the degree of matching between the candidate patch code and the original source code style, modification complexity is used to characterize the complexity of the number of lines modified or the addition of dependencies, historical repair success rate is used to characterize the repair success of similar historical repair patterns, and semantic similarity is used to characterize the degree of matching between the candidate patch code and the defect analysis results.

[0082] Step S105: Output the results. Perform sandbox verification on the candidate patch code in the sandbox environment to obtain the valid patch code and patch verification results. Output an analysis and repair report based on the defect analysis results, valid patch code and patch verification results.

[0083] In this step, based on the sorted list of candidate patch codes, the highest-priority candidate patch code is selected as the candidate patch code to be verified, and sandbox verification is performed on the candidate patch code to be verified in an isolated sandbox environment. Specifically, sandbox verification includes: Build a compilation environment that includes source code, candidate patch code to be verified, and dependent libraries; Apply the candidate patch code to be verified to the corresponding source code and configure the compilation options; Perform a compilation verification to determine whether the patched source code can be compiled and output the verification result. The verification result should include at least one of successful or failed compilation. After successful compilation and verification, the original defect is reproduced and verified. Crash input data that could trigger the original defect is input into the tested program after applying the candidate patch code to verify whether the original defect has been fixed, and the original defect reproduction verification result is output. The original defect reproduction verification result includes at least two options: original defect reproduction verification passed or original defect reproduction verification failed. Passing the original defect reproduction verification means that the tested program after applying the candidate patch code did not trigger the original defect again when processing the crash input data; failing the original defect reproduction verification means that the original defect was still triggered or a preset exception occurred. Regression testing is performed by executing the existing test case set of the project under test to determine whether the candidate patch code to be verified introduces new regression issues and to generate regression test results. The regression test results include at least one of the following: regression test passed or regression test failed. The existing test case set of the project under test includes at least one of the following: unit test cases, integration test cases, or regression test cases configured before the patch was applied. Furthermore, code coverage information is collected after applying the candidate patch code to be verified to form patch test coverage information, which is used to determine whether the candidate patch code to be verified meets the coverage check requirements. When the compilation verification result of the candidate patch code to be verified is successful, the original defect reproduction verification result is successful, and the regression test result is successful, the candidate patch code to be verified is marked as a valid patch code.

[0084] Otherwise, select the next priority candidate patch code from the sorted candidate patch code list to continue sandbox verification.

[0085] After determining the valid patch code, patch verification results are generated based on the compilation verification results, the original defect reproduction verification results, the regression test results, and the patch test coverage information.

[0086] The analysis and remediation report, based on a three-round inference strategy, outputs the defect analysis results, valid patch code, and patch verification results. The report includes a defect description, root cause analysis results, valid patch code, a comparison of code before and after the remediation, patch test results, and test coverage information. The defect description includes the defect type and location.

[0087] Specifically, the defect type comes from the first structured output; the defect location comes from the second structured output; the root cause analysis result comes from the third structured output; the valid patch code is the valid patch code that has passed the sandbox verification; the code comparison before and after the fix is ​​generated based on the modification location, modification content and code snippet before the fix corresponding to the valid patch code; the patch test result is generated based on the compilation verification result verified by the sandbox, the original defect reproduction verification result and the regression test result; the test coverage information is generated based on the patch test coverage information of the valid patch code.

[0088] Now see Figure 2 This invention also provides a code defect analysis and repair system 200 based on a large language model, the system comprising: The crash information receiving and parsing module 210 receives crash information triggered by fuzzing or program execution, and performs crash parsing on the crash information to obtain crash parsing results. The crash parsing results include exception type, call stack information, crash location information, crash running status information, and trigger input association information. A structured defect analysis information module 220 is constructed. Based on the crash analysis results, key defect analysis information is obtained. The key defect analysis information includes at least the exception type, crash location information, target function source code, and runtime variable information. The crash point statement is determined in the target function source code according to the crash location information, and the key variable causing the crash is determined according to the exception type or runtime variable information. Based on the crash point statement and the key variable, the target function source code is sliced ​​using a static backward slicing algorithm to obtain the sliced ​​code information related to the key variable. The structured defect analysis information is constructed based on the key defect analysis information and the sliced ​​code information. The root cause reasoning module 230 inputs the structured defect analysis information into a defect analysis model based on a large language model, and performs reasoning analysis on code defects according to a three-round reasoning strategy. The output of the first round reasoning strategy is a first structured output including defect type and confidence level. Based on the first structured output, the output of the second round reasoning strategy includes a second structured output including defect location. Based on the first and second structured outputs, the output of the third round reasoning strategy includes a third structured output including root cause analysis results and trigger condition chains. The defect analysis result is generated based on the first, second, and third structured outputs. The defect repair module 240 constructs historical repair retrieval conditions based on the defect analysis results, performs a retrieval in the historical repair database to obtain matching historical repair cases, extracts historical repair patterns based on the historical repair cases, generates historical repair retrieval results, and inputs the defect analysis results and historical repair retrieval results into the patch generation model to generate candidate patch codes within the range corresponding to the main defect locations. The result output module 250 performs sandbox verification on the candidate patch code in a sandbox environment to obtain the valid patch code and patch verification results, and outputs an analysis and repair report based on the defect analysis results, valid patch code and patch verification results.

[0089] In summary, this invention provides a code defect analysis and repair method and system based on a large language model. The method includes: receiving and parsing crash information; receiving crash information triggered by fuzzing or program execution; performing crash analysis on the crash information to obtain crash analysis results, the crash analysis results including exception type, call stack information, crash location information, crash running state information, and trigger input association information; constructing structured defect analysis information; based on the crash analysis results, obtaining key defect analysis information, and constructing structured defect analysis information based on the key defect analysis information, the key defect analysis information including exception type, crash location information, call stack path information, target function source code, code snippets near the crash point, and call stack association information. The invention comprises the following steps: First, it constructs structured defect analysis information from crash information parsing results, code information, crash input data, and runtime variable information. Second, it performs root cause reasoning by inputting the structured defect analysis information into a defect analysis model based on a large language model, and analyzes the code defects using a three-round reasoning strategy to obtain defect analysis results including defect type, defect location, and root cause analysis results. Third, it performs defect repair by searching a historical repair database based on the defect analysis results to obtain historical repair retrieval results, and inputs these results into a patch generation model to generate candidate patch code. Fourth, it outputs results by performing sandbox verification on the candidate patch code in a sandbox environment to obtain valid patch code and patch verification results, and outputs an analysis and repair report based on the defect analysis results, valid patch code, and patch verification results. This invention constructs structured defect analysis information from crash information parsing results, code information, crash input data, and runtime variable information, enabling the defect analysis model to perform root cause reasoning based on complete and corresponding multi-source information, avoiding reliance on a single crash log or human experience for judgment. By employing a three-round reasoning strategy to sequentially obtain defect type, defect location, and root cause analysis results, the defect analysis process is transformed from a single judgment into a phased, transferable reasoning process, thereby improving the accuracy and interpretability of crash defect root cause localization. Simultaneously, by retrieving similar historical repair cases from a historical repair database and combining the historical repair retrieval results to generate candidate patch code, the instability issues that may exist when generating patches independently using a large language model can be reduced, improving the matching degree between candidate patch code and the current defect scenario. Furthermore, by using a sandbox to verify and output patch verification results and analysis and repair reports, it is beneficial to form an automated closed loop from crash analysis, root cause localization, patch generation to patch verification, reducing the cost of manual investigation and manual repair.

[0090] Furthermore, this invention obtains the target function source code, code snippets near the crash point, call stack-related code snippets, crash input data, and runtime variable information by using call stack information, crash location information, trigger input association information, and crash running state information. This establishes a clear data correspondence between the crash analysis results and the structured defect analysis information. When the target function source code is long or contains complex loops or recursive structures, this invention employs a static backward slicing algorithm to extract code information related to the crash point statement and key variables, reducing the interference of irrelevant code content on the defect analysis model and alleviating the problem of excessively long analysis context for complex functions. Simultaneously, by combining the inference results of the large language model with historical repair experience through low-confidence backoff, historical repair database retrieval, and historical repair pattern extraction, the instability or "illusion" problems that may occur when the large language model generates patches at a single point can be reduced, improving the matching degree between candidate patch code and the current defect scenario.

[0091] Furthermore, after generating candidate patch code, this invention performs compilation verification, original defect reproduction verification, and coverage checks on the candidate patch code in a sandbox environment, and outputs an analysis and repair report based on the verification results, thus forming an automated closed loop from crash information parsing, root cause analysis, candidate patch generation to patch verification. This method can, to a certain extent, replace the traditional processing flow that relies on manual investigation and manual repair, improve the efficiency of software defect analysis and repair, reduce the risk of leakage caused by manual intervention in core code, and can be used in conjunction with fuzzing tools or CI / CD pipelines to continuously accumulate historical repair cases and improve the accuracy and reliability of subsequent defect repairs.

[0092] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for code defect analysis and repair based on a large language model, characterized in that, include: Receive and parse crash information, receive crash information triggered by fuzzing or program execution, and perform crash analysis on the crash information to obtain crash analysis results. The crash analysis results include exception type, call stack information, crash location information, crash running status information, and trigger input association information. Construct structured defect analysis information. Based on the crash analysis results, obtain key defect analysis information, which includes at least exception type, crash location information, target function source code, and runtime variable information. Determine the crash point statement in the target function source code based on the crash location information, and determine the key variable that caused the crash based on the exception type or runtime variable information. Slice the target function source code using a static backward slicing algorithm based on the crash point statement and the key variable to obtain sliced ​​code information related to the key variable. Construct structured defect analysis information based on the key defect analysis information and the sliced ​​code information. Root cause reasoning involves inputting the structured defect analysis information into a defect analysis model based on a large language model, and performing reasoning analysis on code defects according to a three-round reasoning strategy. The output of the first round reasoning strategy is a first structured output including defect type and confidence level. Based on the first structured output, the output of the second round reasoning strategy includes a second structured output including the location of the main defect. Based on the first and second structured outputs, the output of the third round reasoning strategy includes a third structured output including root cause analysis results and trigger condition chains. The defect analysis result is generated based on the first, second, and third structured outputs. Defect repair involves constructing historical repair retrieval conditions based on the defect analysis results, searching the historical repair database to obtain matching historical repair cases, extracting historical repair patterns based on the historical repair cases, generating historical repair retrieval results, and inputting the defect analysis results and historical repair retrieval results into the patch generation model to generate candidate patch codes within the range corresponding to the main defect locations. The results output includes sandbox verification of the candidate patch code in a sandbox environment to obtain valid patch code and patch verification results, and an analysis and repair report based on the defect analysis results, valid patch code and patch verification results.

2. The code defect analysis and repair method based on a large language model according to claim 1, characterized in that, Based on the crash analysis results, key information for defect analysis is obtained, including: Extract the exception type and crash location information from the crash analysis results; Based on the call stack information and crash location information in the crash analysis results, the source file path, function name and line number corresponding to the crash point are determined, and the source code of the target function is obtained according to the source file path and function name; Based on the line number in the crash location information, extract the code fragment near the crash point from the source code of the target function; Based on the function call level, function name, and line number in the call stack information, call stack path information is generated; Based on the function name, source file path, and line number in the call stack path information, obtain the call stack associated code segment; Based on the trigger input association information, obtain the crash input data that triggers the crash information; Based on the crash running status information, obtain runtime variable information.

3. The code defect analysis and repair method based on a large language model according to claim 1, characterized in that, The first round of inference strategy includes: inputting the exception type, call stack path information, code fragments near the crash point and runtime variable information from the structured defect analysis information into the defect analysis model to infer the defect type and obtain the first structured output, which includes the defect type, confidence level and reason for defect type inference; The second round of reasoning strategy includes: inputting the first structured output, the source code of the target function, the code snippet near the crash point, the code snippet associated with the call stack, and the crash location information into the defect analysis model to locate the code location that caused the defect and obtain the second structured output, which includes the main defect location and the reason for the location location; The third round of reasoning strategy includes: inputting the first structured output, the second structured output, call stack path information, call stack associated code fragments, crash input data and runtime variable information into the defect analysis model to analyze the root cause of the defect and obtain the third structured output, which includes the root cause analysis results and the trigger condition chain. Defect analysis results are generated based on the first structured output, the second structured output, and the third structured output.

4. The code defect analysis and repair method based on a large language model according to claim 1, characterized in that, When the confidence level in the first structured output is lower than the preset confidence threshold, a candidate defect type is determined based on the mapping relationship between the anomaly type and the preset defect type, and the candidate defect type is used as the input of the second round of inference strategy.

5. The code defect analysis and repair method based on a large language model according to claim 1, characterized in that, When the number of lines of code in the target function source code exceeds a preset line count threshold, the static backward slicing algorithm is used to slice the target function source code, and the sliced ​​target function source code is used to replace the target function source code to construct the structured defect analysis information. When the source code of the target function contains a loop structure or a recursive call structure, and the nesting level of the loop structure or the call chain length of the recursive call structure is greater than a preset level threshold, the static backward slicing algorithm is used to slice the source code of the target function, and the sliced ​​source code of the target function is used to replace the source code of the target function to construct the structured defect analysis information.

6. The code defect analysis and repair method based on a large language model according to claim 1, characterized in that, Based on the crash point statement and the key variables, the static backward slicing algorithm is used to slice the source code of the target function, including: The source code of the objective function is divided into multiple basic blocks, and a control flow graph of the objective function source code is constructed based on the control flow jump relationship between the multiple basic blocks. The basic blocks are the nodes of the control flow graph of the objective function source code, and the control flow jump relationship is the edge of the control flow graph of the objective function source code. A data flow graph of the target function source code is constructed based on the variables in the target function source code and the data dependencies between the variables. The variables are the nodes of the target function source code data flow graph, and the data dependencies between the variables are the edges of the target function source code data flow graph. The data dependencies between the variables include assignment relationships, calculation relationships, function parameter passing relationships, or function return relationships between the variables. Based on the crash location information, the crash point statement is determined in the source code of the target function, and the key variable causing the crash is determined based on the exception type or runtime variable information; Using the crash point statement and key variables as slicing criteria, starting from the crash point statement, a reverse traversal is performed based on the target function source code control flow graph and target function source code data flow graph to collect code statements that define the key variables, code statements that have data dependencies on the key variables, and control condition statements that control the execution of the crash point statement. Arrange the collected code statements and control condition statements in the original order of the target function source code to obtain the sliced ​​code information.

7. The code defect analysis and repair method based on a large language model according to claim 1, characterized in that, The receiving and parsing of the crash information includes: The call stack in the crash information is parsed to extract function names, line numbers, and module identifiers to obtain the call stack information. Based on the name of the function at the top of the stack, the line number of the code at the top of the stack, or the identifier of the crashed thread in the call stack information, the crash location information is determined; Identify the exception type based on the error code or exception message in the crash information; Based on the register status information, core dump file or memory error report in the crash information, extract the crash running status information, which includes at least one of register values, memory access address, access size and access range; The crash information is associated with the input file or input data that triggered the crash to obtain the trigger input association information; The crash analysis result is generated based on the exception type, call stack information, crash location information, crash running status information, and trigger input association information.

8. The code defect analysis and repair method based on a large language model according to claim 1, characterized in that, The process of retrieving historical repair results from the historical repair database based on the defect analysis results includes: Based on the defect type, defect location, and root cause analysis results in the defect analysis results, historical repair retrieval conditions are constructed. Retrieve historical repair cases that match the historical repair search criteria from the historical repair database. The historical repair cases include historical defect types, historical function signatures, code snippets before and after repair. Perform a difference analysis on the code snippets before and after the repair to extract historical repair patterns; The historical repair search results are generated based on the historical repair cases and historical repair patterns.

9. A code defect analysis and repair system based on a large language model, characterized in that, include: The crash information receiving and parsing module receives crash information triggered by fuzzing or program execution, and performs crash parsing on the crash information to obtain crash parsing results. The crash parsing results include exception type, call stack information, crash location information, crash running status information, and trigger input association information. A structured defect analysis information module is constructed. Based on the crash analysis results, key defect analysis information is obtained. The key defect analysis information includes at least the exception type, crash location information, target function source code, and runtime variable information. The crash point statement is determined in the target function source code based on the crash location information, and the key variable causing the crash is determined based on the exception type or runtime variable information. Based on the crash point statement and the key variable, the target function source code is sliced ​​using a static backward slicing algorithm to obtain sliced ​​code information related to the key variable. The structured defect analysis information is constructed based on the key defect analysis information and the sliced ​​code information. The root cause reasoning module inputs the structured defect analysis information into a defect analysis model based on a large language model, and performs reasoning analysis on code defects according to a three-round reasoning strategy. The output of the first round reasoning strategy is a first structured output including defect type and confidence level. Based on the first structured output, the output of the second round reasoning strategy includes a second structured output including the location of the main defect. Based on the first and second structured outputs, the output of the third round reasoning strategy includes a third structured output including root cause analysis results and trigger condition chains. The defect analysis result is generated based on the first, second, and third structured outputs. The defect repair module constructs historical repair retrieval conditions based on the defect analysis results, searches the historical repair database to obtain matching historical repair cases, extracts historical repair patterns based on the historical repair cases, generates historical repair retrieval results, and inputs the defect analysis results and historical repair retrieval results into the patch generation model to generate candidate patch codes within the range corresponding to the main defect locations. The results output module performs sandbox verification on the candidate patch code in a sandbox environment to obtain the valid patch code and patch verification results, and outputs an analysis and repair report based on the defect analysis results, valid patch code and patch verification results.

Images