An interactive software debugging and automatic repairing method based on a large language model

Abstract

This invention provides an interactive software debugging and automatic repair method based on a large language model, addressing the problems of traditional software debugging relying on manual operation and being time-consuming, as well as the low repair accuracy caused by the lack of a dynamic operating environment in existing static automatic program repair technologies. The method first triggers a program exception by executing a reproduction command and captures the original crash stack information; then, it uses a large model to extract a simplified core function call sequence; subsequently, it constructs a closed-loop debugging mechanism, controlling the large model to generate hypotheses about the root cause of the defect and executing debugger probe commands, iteratively revising the hypotheses based on the dynamic information obtained by the debugger until the defective code is accurately located; finally, it combines the debugging context with the large model to complete root cause analysis and automatically generate and verify executable repair patches. This invention alleviates the "illusion" of large model inference by continuously capturing the underlying dynamic operating state, significantly improving the automation and accuracy of defect repair.

Description

Technical Field

[0001] This invention relates to the field of software engineering automation and artificial intelligence, specifically to a method, system, and storage medium for controlling a large language model and a debugger to interact with instructions based on a state machine mechanism, so as to achieve automatic location and repair of software defects. Background Technology

[0002] In software development and maintenance, debugging and defect repair are critical stages that are time-consuming, labor-intensive, and technically demanding. Existing automated program repair technologies mainly rely on static analysis or extensive test case matching. Static analysis struggles to capture the dynamic memory and variable states during program runtime, leading to a high false positive rate for logical errors involving complex state transitions. Test case-based repair methods, on the other hand, suffer from technical limitations such as high test case coverage requirements and a lack of contextual reasoning in the patch generation process.

[0003] With the development of deep learning technology, large language models have shown potential in code understanding. However, existing methods are mostly one-way static code review, which cannot effectively integrate the logical reasoning ability of large language models with the debugger's dynamic detection capability of the computer's underlying runtime state. Due to the lack of standardized instruction mapping mechanisms and exception handling loops, existing technologies are prone to "model illusion" or getting stuck in invalid operations when faced with complex defects that require multi-step runtime state verification. They still heavily rely on manual intervention and cannot form an automated repair control chain. This invention provides an interactive software debugging and automatic repair method based on large language models to solve the problems of traditional software debugging relying on manual operation and being time-consuming, as well as the low repair accuracy caused by the lack of a dynamic runtime environment in existing static automatic program repair technologies. Summary of the Invention

[0004] This invention provides an interactive software debugging and automatic repair method based on a large language model, addressing the key problems of software debugging relying heavily on manual intervention and being time-consuming, as well as the low accuracy of existing automatic program repair technologies due to the lack of dynamic program runtime context. This method captures abnormal crash stacks and utilizes a large model to streamline the core context; it constructs a state machine-based closed-loop interaction mechanism to control the large language model to perform multiple "hypothesis-verification" probes on a dynamic debugger, accurately locating defective code; finally, it aggregates debugging chain data throughout the entire lifecycle, uses the large language model to generate code repair patches, and performs automated build verification, ultimately achieving reliable automated repair of software defects.

[0005] To automatically locate and repair defects in software, this invention discloses an interactive software debugging and automatic repair method based on a large language model, specifically including the following steps:

[0006] Step 1: Execute the exception reproduction instruction in the software runtime environment to trigger the program defect and capture the original stack trace information when the target program crashes;

[0007] Step 2: Use a large language model to extract and simplify the features of the raw stack trace information captured in Step 1 to obtain the core function call sequence;

[0008] Step 3: Establish a closed-loop interactive debugging mechanism based on a state machine to control the large language model and the dynamic debugger to perform multiple rounds of "hypothesis-verification" interactive loops until the specific physical line of code that triggers the defect is located.

[0009] Step 4: Combine the physical location of the defective code located in Step 3, the interactive debugging history, and the corresponding source code fragments with the input into the large language model to perform defect root cause analysis and generate differentiated code repair patches.

[0010] Step 5: Automatically apply the differentiated code repair patch generated in Step 4 to the target project, recompile and build, and execute the anomaly reproduction command to verify and confirm.

[0011] In step 1, a dynamic debugger such as GDB or LLDB is launched, and the defective target program is restarted using a preset reprocommand. When the target instruction executes and causes an abnormal state such as a memory violation or crash, the full raw stack trace of the underlying system and related standard output stream data are captured as a debugging benchmark.

[0012] In step 2, since the original stack trace information is lengthy and usually contains a large number of low-level system library or application framework layer interference calls, the original stack text is input into a large language model for "stack distillation" to remove irrelevant items and extract the set of core function call sequences that are directly causally related to logical errors or the root cause of the crash.

[0013] In step 3, a probe-based verification architecture is introduced to narrow the exploration space of the large language model. First, based on the core call sequence obtained in step 2, the language model generates initial technical hypotheses about the root cause of defects (e.g., assuming a variable is an illegal reference). Second, the language model translates this hypothesis verification operation into low-level probing instructions recognizable by the debugger (e.g., register lookup instructions, variable status printing instructions). Next, while the target program is suspended, these probing instructions are pushed into the dynamic debugger for execution, obtaining actual memory or variable data feedback. Finally, the language model verifies and updates its technical hypotheses based on this actual feedback. This hypothesis-verification closed loop iterates continuously until the anomaly is determined to be locked to a specific physical line number of code.

[0014] In step 4, the specific lines of code output from the localization phase, a set of verification logic history contexts generated during the interactive debugging phase, and associated physical file code fragments are aggregated. This data is integrated as global instruction prompts and input into a large language model. The model then interprets the root causes of defects at the natural language dimension based on the dynamically collected data and synthesizes standard format diff code patches (in diff form) that support automated applications.

[0015] In step 5, the verification module applies the generated differential code patch to the original source file via system commands to perform physical overwrite. It then calls the project's internal build script to restore the target program and repeats the exception triggering mechanism from step 1. Based on the execution results, it verifies whether the original crash signature and suspended state have disappeared; if no abnormal characteristics are generated, the patch verification is considered successful.

[0016] This invention uses a large language model to simulate the interaction between security engineers and debugging tools, integrating the code reasoning capabilities of the large model with the physical memory probing capabilities of a system-level debugger. By dynamically constraining and guiding the judgment logic of the large model through program state feedback, it overcomes the predicament of static analysis easily generating "illusory code patches," and solves the problem of automating the repair of deep logic faults in traditional software testing, significantly improving the accuracy of patch generation and the efficiency of defect removal.

[0017] Beneficial effects: This method effectively enables end-to-end automated debugging and repair of complex software. By utilizing a dynamic debugger to obtain real memory and variable feedback and transmitting it to a large pre-trained model for iterative inference, the accuracy of locating defective code containing complex state transitions is significantly improved. By binding patch generation with the automated compilation and backtesting process, a closed-loop solution addresses the technical challenge of lacking an effective automated repair chain in software maintenance. Attached Figure Description

[0018] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments, and the advantages of the present invention as described above or otherwise will become clearer.

[0019] Figure 1 This is an overall flowchart of an interactive software debugging and automatic repair method based on a large language model provided in an embodiment of the present invention.

[0020] Figure 2 This is a control flowchart for obtaining feedback and performing closed-loop interactive debugging and verification (i.e., the "hypothesis-verification" loop) provided in the embodiments of the present invention.

[0021] Figure 3 This is a system flowchart of the root cause aggregation analysis and code repair patch automatic verification module provided in the embodiments of the present invention. Detailed Implementation

[0022] To more clearly describe the purpose, technical solution, and advantages of this invention, this chapter provides a further detailed description of the invention in conjunction with the accompanying drawings.

[0023] Figure 1 The overall flowchart of the interactive software debugging and automatic repair method in this invention is shown, including 5 core steps, as follows:

[0024] Step 1, Instruction Loading and Exception Trigger Capture: Load the user's reproduced instructions and execute them in the debugger sandbox to obtain the full original stack trace that caused the crash;

[0025] Step 2, model-based associative stack feature distillation filtering;

[0026] Step 3: Dynamic interactive deduction driven by language model to cyclically locate the physical line number of the defect;

[0027] Step 4: Summarize the debugging link status and source code context, and generate a code merge patch containing root cause analysis;

[0028] Step 5: Use external compilation instructions to perform patch coverage integration, system-level recompilation, and secondary crash verification detection closed loop.

[0029] Figure 2 A flowchart illustrating the control loop details of closed-loop interactive debugging and verification is provided to demonstrate the specific implementation of step 3, and the process is as follows:

[0030] Step 2-1: Based on the input core stack information, generate initial root cause hypotheses for defects (such as null pointer exceptions and array memory out-of-bounds exceptions).

[0031] Step 2-2: Compile the hypothetical logic into the corresponding debugger's set of operation commands (e.g., issue `infoargs` or `p struct->field` in GDB to view the structure memory, etc.);

[0032] Steps 2-3 involve suspending the program being debugged, scheduling the underlying interactive module to issue a set of commands, and capturing the actual feedback results from the system.

[0033] Step 2-4: Determine whether the actual feedback result of the system supports the current defect hypothesis; if yes, and the evidence is sufficient to point to a specific line of code, then break out of the loop and output the file information; if no, update the corrective reasoning hypothesis model, return to step 2-1 to generate a new layer of commands, until the depth threshold is reached or the location is successful.

[0034] Figure 3 The flowchart illustrating the structure of the root cause aggregation analysis and code fix patch automatic verification module details the final generated verification process as follows:

[0035] First, aggregate the debugging loop history (including successfully hit probe data and failed probe exclusion information), and use the positioning row generated in the previous round to extract the surrounding source code range;

[0036] Technical analysis documents in the form of natural descriptions are generated using large language models, and the replaced and modified lines of code are encapsulated and distributed through Diff file objects.

[0037] The file system and shell pipes are invoked to merge the Diff, and the compilation engine is restarted to build and generate the executable file. If the same crash flag is detected again under the target instruction or a compilation error occurs and aborts, the new error is captured and the process returns to regenerate the patch logic.

[0038] This invention provides a method for interfacing with a low-level debugger using a large model. Many methods and approaches exist for implementing this technical solution. The above description is merely a preferred embodiment of this invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this invention, and these improvements and modifications should also be considered within the scope of protection of this invention. All components not explicitly stated in this embodiment can be implemented using existing technologies.

Claims

1. An interactive software debugging and automatic repair method based on a large language model, characterized in that, Includes the following steps: Step 1: In response to the exception triggered by the target program, obtain the original stack trace information of the target program at the time of the crash; Step 2: Use a large language model to extract features from the original stack trace information to identify the core function call sequence; Step 3: Based on the core function call sequence, control the large language model to perform multiple rounds of interactive probing with the dynamic debugger until the defective code location of the target program is located; wherein, in each round of interaction, the large language model generates debugging hypotheses based on the current probing results, and converts the debugging hypotheses into probe instructions executable by the dynamic debugger, which executes the probe instructions and feeds back program running status data to the large language model; Step 4: Using the large language model, generate a code patch for the target program based on the location of the defective code, the context record of the interactive probe, and the associated source code fragment; Step 5: Apply the code repair patch to the target program and perform automated verification of the repaired target program based on preset verification instructions.

2. The method according to claim 1, characterized in that, Step 3 includes: Establish a closed-loop interaction mechanism based on a state machine, and maintain the transition of debugging states through the state machine; The large language model infers the root cause hypothesis of program defects based on the core function call sequence or historical feedback data in the current state. Map the root cause hypothesis to low-level debugging instructions for specific registers, variables, or memory addresses; The underlying debugging instructions are input into the dynamic debugger for execution, and the returned runtime variable values ​​or memory image data are captured. The large language model performs self-consistency verification on the root cause hypothesis based on the returned data, and decides to terminate the probe or enter the next round of interaction based on the verification results.

3. The method according to claim 1, characterized in that, Step 2 includes: The original stack trace information is distilled using the large language model to identify and filter out non-business logic calls belonging to system libraries or third-party frameworks, retaining only function call paths related to business application logic, in order to construct the core function call sequence.

4. The method according to claim 1, characterized in that, Step 4 includes: The defect code location, the instruction and feedback sequence generated during the interactive detection process, and the preset number of lines of source code before and after the defect code location are assembled into prompt words; The large language model is used to reason about the assembled prompt words, and the resulting defect root cause explanations and code fix patches for standard difference formats are output.

5. The method according to claim 1, characterized in that, Step 5 includes: Perform code merging and project refactoring in an automated sandbox environment; The verification command is triggered again, and the program's running status is monitored; If verification fails or a new exception is introduced, the failure feedback is returned to the large language model, triggering the large language model to regenerate a code fix patch based on the failure feedback.

6. An electronic device, characterized in that, include: processor; as well as A memory for storing a computer program that, when executed by the processor, implements the method as described in any one of claims 1-5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-5.

Images