Global anomaly semantic analysis and repair suggestion generation method and related equipment

Abstract

The invention provides a global anomaly semantic analysis and repair suggestion generation method and related equipment. In the method, a repair suggestion generation system firstly converts original abnormal information into structured information, then determines a specific position and an execution link of an abnormal problem based on an abnormal type and a stack trajectory in the structured information, and clarifies a code coordinate and a propagation path of the abnormal problem. And then, the repair suggestion generation system intercepts a code snippet containing a complete execution node, performs reverse analysis according to an execution sequence of the execution node by using a data flow tracing technology, and determines a direct reason node causing an abnormal problem, so that the blindness of troubleshooting is avoided. And finally, a repair suggestion generation system performs semantic analysis on the key code sub-fragments through a large language model, excavates a root cause causing an abnormal problem and generates a repair suggestion. According to the method, the technical problem that developers are difficult to rapidly troubleshoot abnormal reasons is relieved, and the processing efficiency of the abnormal problems is improved.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a method and related equipment for global anomaly semantic analysis and repair suggestion generation. Background Technology

[0002] With the widespread adoption of microservice architecture and distributed computing, the structure of modern software systems is becoming increasingly complex, with intricate inter-service call relationships. In this environment, the stability and reliability of software systems face significant challenges. When an anomaly occurs in the system, its impact can rapidly propagate along the service call chain, triggering a chain reaction and leading to widespread service unavailability.

[0003] In related technologies, the industry has proposed and widely applied a series of external monitoring-based Application Performance Management (APM) systems. These systems (such as SkyWalking or Dynatrace) monitor the application's runtime status from the outside in a non-intrusive or low-intrusive manner by deploying probes in the application's runtime environment. In this way, APM systems can connect the complete call paths of a seemingly independent request across numerous distributed services, forming a clear distributed chain, thus providing developers with a macroscopic view of the system's operation.

[0004] However, as an external monitoring tool, APM systems primarily monitor and analyze at the method or service call level, unable to delve into the detailed logic of the code within the method. Therefore, when a developer locates a specific line of code with an exception using an APM system, the system cannot provide direct insight into the upstream code logic that caused the exception (such as null pointer exceptions or incorrect parameters). Technical personnel still need to combine contextual information and conduct secondary investigations through local reproduction, log analysis, and code review. In scenarios with complex logic and deep call nesting, this makes it difficult to quickly find the root cause, reducing the efficiency of exception handling during software development. Summary of the Invention

[0005] This application provides a method and related equipment for global anomaly semantic analysis and repair suggestion generation, which can alleviate the technical problem that developers have difficulty in quickly identifying the cause of anomalies and improve the efficiency of handling anomaly problems.

[0006] Firstly, this application provides a method for global anomaly semantic analysis and repair suggestion generation, including: obtaining the original anomaly information of all anomalies in the project source code and converting the original anomaly information into structured information; determining the specific location and execution chain of each anomaly in the project source code based on the anomaly type and stack trace information in the structured information; extracting the execution code fragment of each anomaly based on the specific location and execution chain, wherein the execution code fragment represents the code fragment that can completely present the execution node of the anomaly; based on the execution chain, using data flow tracing technology to analyze the execution operation of a single execution node sequentially from back to front according to the execution order, and determining whether the currently analyzed execution node is the direct source of the current anomaly; when the current execution node is the direct source of the current anomaly, stopping the tracing analysis and determining the current execution node as the direct cause node of the current anomaly; and using a large language model to perform semantic analysis on the code sub-fragments from the beginning to the direct cause node in the execution code fragment to obtain the root cause of the anomaly and repair suggestions.

[0007] By employing the above technical solution, the repair suggestion generation system first transforms the raw exception information into structured information. Then, based on the exception type and stack trace within the structured information, it determines the specific location and execution chain of the exception, clarifying the code coordinates and propagation path where the exception occurred. Next, the system extracts code snippets containing complete execution nodes and uses data flow tracing technology to reverse-engineer the execution order of these nodes, identifying the direct cause of the exception and avoiding blind troubleshooting. Finally, the system performs semantic analysis on key code segments using a large language model to uncover the root cause of the exception and generate repair suggestions. This method alleviates the technical challenge of developers quickly identifying the causes of exceptions and improves the efficiency of exception handling.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, the specific location and execution chain of each exception in the project source code is determined based on the exception type and stack trace information in the structured information. Specifically, this includes: parsing the stack trace information in the structured information to obtain an ordered list containing multiple stack frames; extracting the class name, method name, and line number of the first stack frame in the ordered list, and mapping the line number to the specific location of the exception; traversing all stack frames in the stack trace information, extracting the class name and method name of each stack frame, and connecting them in the order of invocation to form an execution chain from the initial call node to the specific location.

[0009] By adopting the above technical solution, the repair suggestion generation system maps the specific line location of the anomaly by parsing the ordered list of stack frames in the stack trace, and connects them in the order of calls to form a complete execution chain. This method transforms the stack information into a structured output of "specific location" and "full-chain call relationship," realizing the construction of a complete code-level tracing path from the point of occurrence to the calling node of the anomaly. This provides a tracing anchor point for subsequent in-depth analysis and alleviates the problem of not being able to locate the specific code location of the anomaly and the complete propagation path.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, based on the specific location and execution chain, the execution code fragment of each exception problem is extracted. Specifically, this includes: extracting the complete source code of the method at the specific location as the base code fragment, and tracing upwards along the execution chain to locate the line of code in each upstream calling method that calls the downstream method; expanding the extraction range upwards based on the line of code until the extracted content contains the definition and assignment statements of all parameter variables passed to the downstream method; adding all the code within the expanded extraction range to the base code fragment, up to the starting node of the execution chain, to obtain the execution code fragment.

[0011] By adopting the above technical solution, the repair suggestion generation system traces upwards along the execution chain and expands the interception scope to ensure that the intercepted code snippets include all definitions and assignment statements of the passed parameters. In this method, the logic of code snippet interception is centered on "parameter flow," which can preserve the entire code context from the upstream propagation of the abnormal state to the point of occurrence, avoiding analysis gaps caused by missing parameter sources, and achieving full-link context coverage of the abnormal-related code logic.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, based on the execution chain, data flow tracing technology is used to analyze the execution operations of individual execution nodes sequentially from back to front according to the execution order. Specifically, this includes: constructing a control flow graph and a data dependency graph corresponding to the execution code segment based on the execution code segment and the execution chain; taking a specific location as the starting point for tracing, performing syntactic analysis on the code at the specific location according to the exception type in the structured information, identifying one or more suspect variables directly related to the exception type, and marking the suspect variables as tainted variables; tracing the tainted variables backward along the control flow graph and data dependency graph; when a single execution node is a statement that assigns or modifies a tainted variable, updating the tainted variable according to the source of the assignment; and determining whether the currently analyzed execution node is the direct source of the current exception problem.

[0013] By adopting the above technical solution, the remediation suggestion generation system combines control flow graphs, data dependency graphs, and tainted variable reverse tracing. After marking suspected variables based on anomaly types, it traces the variable flow backward along the code logic framework. This method can automatically identify the assignment and modification nodes of anomaly-related variables, achieving automated tracing of anomaly data flow.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, determining whether the currently executing node being analyzed is the direct source of the current exception problem specifically includes: determining whether the assignment source is the return value of an external method call; if the assignment source is the return value of an external method call, then the execution node of the external method call is determined as the direct source of the current exception problem; if the assignment source is not the return value of an external method call, then determining whether the assignment source is an input parameter of an external method, or a constant value that can cause an exception and is directly assigned in the code; if so, then the currently executing node containing the assignment operation is determined as the direct source of the current exception problem; if not, then the source variable that assigns the value to the tainted variable is taken as a new tainted variable, and the upstream code is continued to be reverse-traced and analyzed with the new tainted variable as the target.

[0015] By adopting the above technical solution, the repair suggestion generation system first determines whether the assignment source is the return value of an external method call. If not, it determines whether it is an external input parameter or a constant value that can trigger an exception, as these are common initial sources of abnormal states. If none of these are the case, the tainted variable is updated and the tracing continues. The judgment logic of this method is to check the abnormal source in descending order of probability, and sets clear tracing termination conditions, which can quickly identify the direct cause node during the tracing process, ensuring the efficiency of direct cause node location.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, a large language model is used to perform semantic analysis on the code sub-segments from the start to the direct cause node in the executed code segment to obtain the root cause of the anomaly and remediation suggestions. Specifically, this includes: using a large language model to perform semantic analysis on the executed code segment to obtain the code intent and business scenario description of the executed code segment; inferring the expected behavior of the executed code segment in the corresponding business scenario by analyzing the naming conventions, comment documentation, exception type annotations, and associated test cases of the executed code segment; integrating the code sub-segments from the start to the direct cause node, exception type, code intent, and business scenario description of each anomaly's executed code segment to obtain the comprehensive analysis input for each anomaly; using a large language model to perform semantic analysis on the comprehensive analysis input to obtain the actual execution logic of the code sub-segments from the start to the direct cause node in the executed code segment; identifying the logical conflict points or missing links between the actual execution logic and the expected behavior; generating the root cause of the anomaly based on the logical conflict points or missing links, and generating remediation suggestions that conform to the code intent and business scenario of the anomaly based on the root cause.

[0017] By adopting the above technical solution, the repair suggestion generation system combines the semantic understanding capabilities of a large language model with code intent and business scenario inference. By comparing the actual execution logic with the expected behavior, it identifies logical conflict points. The generated repair suggestions are not only based on the code level but also closely aligned with business scenario requirements. This method achieves deep alignment from code logic to business goals, alleviating the problem of traditional repair suggestions being disconnected from actual business needs.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after performing semantic analysis on the code sub-segments from the beginning to the direct cause node in the executed code segment using a large language model to obtain the root cause and repair suggestions of the anomaly, the method further includes: creating a structured diagnostic data object for each anomaly in the project source code; matching the original anomaly information of each anomaly with the corresponding executed code segment, anomaly type, root cause, and repair suggestions, and populating it into the diagnostic data object; and compiling the diagnostic data objects of all anomalies to form a diagnostic report of the project source code.

[0019] By adopting the above technical solution, the repair suggestion generation system constructs a structured diagnostic data object, which associates scattered anomaly information, code snippets, root causes, and repair suggestions to ultimately generate a diagnostic report. This method enables the structured display of all anomalies in the project, alleviating the difficulty of information integration in multi-anomaly scenarios.

[0020] In a second aspect, this application provides a repair suggestion generation system, including one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the repair suggestion generation system to perform the method as described in the first aspect and any possible implementation thereof.

[0021] Thirdly, this application provides a computer-readable storage medium including instructions that, when executed on a repair suggestion generation system, cause the repair suggestion generation system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, this application provides a computer program product that, when run on a repair suggestion generation system, causes the repair suggestion generation system to perform the method described in the first aspect and any possible implementation thereof.

[0023] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By employing technical means such as structuring the original exception information, determining the specific location and execution link based on the exception type and stack trace, extracting complete execution code fragments, tracing the direct cause node through data flow, and using a large language model for semantic analysis and generating repair suggestions, the technical problem of developers having difficulty quickly identifying the root cause of exceptions in existing technologies is effectively alleviated, and the efficiency of exception handling is improved.

[0024] 2. By adopting a hierarchical judgment technique that first determines whether the source of the assignment is a return value of an external method, then determines whether it is an external input parameter or a constant value that causes an exception, and finally updates the tainted variable to continue tracing, the technical problems of data flow tracing range being easily out of control and direct cause node positioning being ambiguous in the existing technology are effectively alleviated, and the technical effect of fast and accurate positioning of direct cause nodes is achieved.

[0025] 3. By employing a technical approach that utilizes large language models to analyze code intent and business scenarios, infer expected behavior, integrates multi-dimensional information for comprehensive analysis, identifies conflict points between actual execution logic and expected behavior, and generates repair suggestions adapted to business scenarios, the technical problem of disconnect between anomaly repair suggestions and actual business in existing technologies is effectively alleviated. This achieves deep alignment from code logic to business goals, generating more reasonable and effective repair suggestions. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a global anomaly semantic analysis and repair suggestion generation method in an embodiment of this application; Figure 2 This is another flowchart illustrating the global anomaly semantic analysis and repair suggestion generation method in this application embodiment; Figure 3 This is a schematic diagram of the hardware structure of the repair suggestion generation system in the embodiments of this application. Detailed Implementation

[0027] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to any or all possible combinations including one or more of the listed items.

[0028] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0029] For ease of understanding, the method provided in this implementation is described in process below. Please refer to [link / reference]. Figure 1 This is a flowchart illustrating a global anomaly semantic analysis and repair suggestion generation method in an embodiment of this application.

[0030] S101. Obtain the original exception information of all exceptions in the project source code and convert the original exception information into structured information.

[0031] Raw exception information refers to unprocessed exception data generated during program runtime, including raw information such as exception type, exception description, and stack trace; structured information refers to information after raw exception information has been standardized according to a predefined data structure; project source code represents the complete code library of the software project to be analyzed.

[0032] Specifically, when the remediation suggestion generation system begins analyzing anomalies, it first collects all anomaly information from the project's source code. The system scans multiple sources, including project log files, error reports, and test results, extracting all recorded anomaly information. After obtaining the raw anomaly information, the system converts this unstructured text information into standard data structures, storing information such as anomaly type, occurrence time, anomaly description, and stack trace in structured data fields. This conversion process ensures that subsequent analysis can accurately and efficiently process this anomaly information.

[0033] In some embodiments, the acquisition and structured transformation of anomaly information can be achieved in several ways: Optionally, the remediation suggestion generation system can establish an anomaly log parser, first identifying anomaly markers in the log file, then using regular expressions to extract key information, and finally mapping the extracted information to a predefined data structure; alternatively, the system can access the API of an application performance monitoring (APM) system to directly obtain semi-structured anomaly data, and then perform further structured processing. It is understood that other methods can also be used to collect and transform anomaly information, which are not limited here.

[0034] S102. Based on the exception type and stack trace information in the structured information, determine the specific location and execution chain of each exception in the project source code.

[0035] The exception type indicates the specific exception class thrown by the program, such as NullPointerException, IllegalArgumentException, etc.; the stack trace information indicates the method call stack information when the exception occurred; the specific location refers to the line number and file location where the exception occurred; the execution chain indicates the complete method call sequence that led to the exception.

[0036] Specifically, the fix suggestion generation system analyzes the structured information of each exception. First, it understands the basic nature of the exception by identifying its type, then it parses the stack trace to reconstruct the call context at the time the exception occurred. Next, the system analyzes the stack trace layer by layer to determine where the exception was initially thrown and how it propagated between different method call levels. Through this analysis, the fix suggestion generation system constructs a complete exception propagation path, helping developers understand how the exception spreads from the point of occurrence to the point of being caught.

[0037] In some embodiments, the location and path of an anomaly can be determined in several ways: Optionally, the repair suggestion generation system can construct a call graph analyzer to convert stack information into a directed graph structure and determine the anomaly propagation path through a graph traversal algorithm; alternatively, the repair suggestion generation system can use static code analysis techniques, combining source code and stack information, to construct detailed method call relationships, thereby locating the anomaly location. It is understood that other methods can also be used to achieve anomaly location and path analysis, which are not limited here.

[0038] S103. Based on the specific location and execution chain, extract the execution code fragment for each exception problem. The execution code fragment represents the code fragment that can fully present the execution node of the exception problem.

[0039] An execution code snippet represents the smallest complete unit of code associated with an exception, including the code at the point where the exception occurs and its associated context code; an execution node represents a key code location on the exception propagation path, including the point where the exception occurs, the point where the exception propagates, and the point where the exception is caught.

[0040] Specifically, the repair suggestion generation system extracts relevant code snippets based on the determined location of the exception and the execution chain. The system not only obtains the code line where the exception directly occurred, but also analyzes contextual dependencies to extract relevant code necessary for understanding and fixing the exception. This includes code parts that may affect the occurrence of the exception, such as variable definitions, method calls, and conditional statements. The system also ensures that the extracted code snippets contain sufficient contextual information while avoiding excessive irrelevant code.

[0041] S104. Based on the execution chain, use data flow tracing technology to analyze the execution operations of individual execution nodes sequentially from back to front according to the execution order, and determine whether the currently analyzed execution node is the direct source of the current abnormal problem.

[0042] Data flow tracing technology refers to a program analysis technique used to trace the definition point of a variable's value, i.e., the source of its value, by starting from the point of use of a variable in a program and tracing back along the program's control flow and data dependencies. The execution order from back to front means starting from the instruction where the exception occurred and tracing back along the execution chain, analyzing each instruction node on the path. In this context, the execution node refers to the atomic operation in the execution chain, such as variable assignment, method call, or return. The direct source refers to the execution node that assigned the "abnormal state value" (such as null, illegal value, etc.) to the variable that caused the exception during the reverse data flow tracing process.

[0043] Specifically, the remediation suggestion generation system performs a targeted data dependency analysis in this step. The analysis starts at the precise line of code where the exception occurred. The system first identifies the variable that directly caused the exception and its "abnormal state," for example, in a NullPointerException, it's an object reference variable with a null value. Then, the system initiates a reverse data flow tracing engine, targeting this variable and analyzing backwards from the point of exception along the actual execution path (provided by the execution chain). At each step of the backtracking, the system checks if the current execution node is the definition point of the target variable. For example, if analyzing a null pointer exception caused by `user.getName()`, the system will reverse-search for the last assignment operation to the `user` variable, such as `user = findUserById(id)` or `user = anotherObject.user`. This tracing process crosses method boundaries, tracing upwards along the call chain until the assignment point of the abnormal state is found.

[0044] S105. When the current execution node is the direct source of the current abnormal problem, stop the tracing analysis and determine the current execution node as the direct cause node of the current abnormal problem.

[0045] The current execution node refers to the code instruction or operation being reviewed during the data flow backtracking analysis in S104; the direct source refers to the instruction that was first identified as introducing an abnormal data state through the data dependency analysis in S104; the traceability analysis refers to the entire reverse data flow tracing process starting from the point of anomaly; and the direct cause node is the confirmation and marking of the "direct source". It should be noted that: "direct source" refers to the operation itself, and "direct cause node" refers to the code node containing that operation. Specifically, this step defines precise termination conditions for the iterative data flow tracing process executed in S104. When tracing the source of the target variable value in reverse, the remediation suggestion generation system analyzes each upstream execution node to determine if that node is a "definition point" of the target variable and whether the definition operation directly produced the value that caused the anomaly. Once the system finds such a node—for example, an assignment statement "user=null;" or a findUserById(id) method call that returns null—the data flow tracing process terminates immediately. This termination mechanism ensures the accuracy and efficiency of the analysis because it precisely captures the location of the outlier. This finally identified execution node that introduced the outlier is formally marked as the "direct cause node" by the remediation suggestion generation system.

[0046] S106. Use a large language model to perform semantic analysis on the code sub-segments from the beginning to the direct cause node in the executed code segment to obtain the root cause of the abnormal problem and repair suggestions.

[0047] Large language models refer to advanced artificial intelligence models trained on massive amounts of text and code data, possessing deep language understanding and code generation capabilities; semantic analysis refers to a deep understanding of the logical intent and business meaning of code, not just its grammatical structure; root cause refers to the deep, logical reasons why an exception occurs; and repair suggestions refer to specific and actionable code modification plans proposed to resolve the exception problem.

[0048] Specifically, after accurately locating the "direct cause node," the remediation suggestion generation system integrates all key analysis outputs—the complete execution trajectory of the anomaly, the direct cause node, and the propagation path of the anomaly from its generation to its detonation—into a detailed, machine-readable contextual description. This description is injected into a prompt and submitted to the large language model. The large language model no longer receives isolated code, but rather structured contextual information containing detailed execution trajectories and key data flow paths. The core task of the large language model is to perform deep semantic analysis on the code at the "direct cause node." The large language model generates two key outputs: an analysis report explaining the root cause of the problem, and a remediation suggestion that can be directly applied to the code near the "direct cause node."

[0049] The global anomaly semantic analysis and repair suggestion generation method in this application involves a repair suggestion generation system that first transforms raw anomaly information into structured information to clarify the basic anomaly data, and then combines the anomaly type and stack trace to determine the specific location and execution chain of the anomaly. Next, the system extracts code snippets containing complete execution nodes and uses data flow tracing technology to reverse-engineer the direct cause node. Finally, the system leverages a large language model to perform semantic analysis on key code sub-snippets to uncover the root cause and generate repair suggestions. This achieves a complete process analysis of anomaly issues, from data structuring to root cause localization and repair suggestion generation, alleviating the technical challenge of developers quickly identifying anomaly causes in complex systems and effectively improving the efficiency of anomaly handling.

[0050] Based on the above, the following is a more detailed description of the process provided in this implementation. Please refer to [link / reference]. Figure 2 This is another flowchart illustrating the global anomaly semantic analysis and repair suggestion generation method in this application embodiment.

[0051] S201. Obtain the raw exception information for all exceptions in the project source code and convert the raw exception information into structured information. (This step has been explained in S101 and will not be repeated here.) S202. Based on the exception type and stack trace information in the structured information, determine the specific location and execution chain of each exception in the project source code.

[0052] Step S202 specifically includes steps S2021 to S2023, all of which are not shown in the figure.

[0053] S2021. Parse the stack trace information in the structured information to obtain an ordered list containing multiple stack frames.

[0054] Structured information refers to the data obtained by the repair suggestion generation system after standardizing the original, text-formatted exception log content according to a preset data model (such as JSON format); stack trace information refers to the original text data that specifically records the complete method call stack when the exception occurs within the structured information; ordered list refers to a list data structure that the repair suggestion generation system organizes all parsed stack frames according to their order of appearance in the original stack trace information (usually from the exception throwing point to the initial call point).

[0055] Specifically, the fix suggestion generation system launches a parser for the stack trace format specific to a programming language (e.g., Java, Python). This parser reads the stack trace string line by line, using preset rules (such as regular expressions) to identify and extract key information that conforms to the stack frame format in each line. For each valid call record, such as "at package.ClassName.methodName(FileName.java:LineNumber)", the fix suggestion generation system precisely extracts the class name "package.ClassName", the method name "methodName", and the line number "LineNumber". The system then uses this extracted information to create a structured "stack frame" object and adds it to a new list. This process continues until all lines of the stack trace information have been processed. The fix suggestion generation system strictly maintains the order of these stack frame objects in the list exactly as they appear in the original text, thus completely preserving the reverse call order from the exception occurrence point to the start of the call chain, forming an ordered list.

[0056] S2022. Extract the class name, method name, and line number of the first stack frame in the ordered list, and map the line number to the specific location of the exception.

[0057] A stack frame refers to the stack frame object that the fix suggestion generation system retrieves from the beginning of the ordered list (i.e., the position with index 0). This stack frame directly corresponds to the line of code in the program that initially throws the exception. The class name, method name, and line number refer to the precise coordinate information about the point where the exception occurred, recorded in the first stack frame object. The specific location refers to the coordinates in the project source code that the fix suggestion generation system determines based on the above information, which can uniquely identify the point where the exception occurred. It is usually composed of the file name and the line number, and it is the starting point for all subsequent code analysis.

[0058] Specifically, the repair suggestion generation system accesses an ordered list. Following the standard stack trace recording method, the call stack always records the most recent call (i.e., the point where the exception directly occurred) at the beginning. Therefore, the first element in this ordered list (the stack frame at index 0) inevitably contains the most critical information. The repair suggestion generation system extracts the filename, class name, method name, and crucial line number from this first stack frame object. Then, the system uses this line number, combined with its corresponding filename, to establish a precise, actionable coordinate and marks it as the specific location of the current exception issue.

[0059] S2023. Traverse all stack frames in the stack trace information, extract the class name and method name of each stack frame, and connect them in the order of invocation to form an execution chain from the initial call node to the specific location.

[0060] A stack frame is each call node that makes up the trajectory; the call order refers to the chronological order in which methods are actually executed in the program, that is, the order from the starting method of the call chain to the method that ultimately triggers the exception; the initial call node is the method that is located at the deepest point and is called first in the call stack related to the current exception; the execution chain is a structured ordered sequence built by the repair suggestion generation system, which stores the complete path from the "initial call node", through a series of intermediate method calls, to finally reach the specific location.

[0061] Specifically, the fix suggestion generation system iterates through each stack frame in the ordered list. For each stack frame, the system extracts its core identifiers—the class name and method name—and encapsulates this information into a structured object representing a node in the execution chain. Since the original stack trace is arranged back from the exception occurrence point to the call origin, this is the reverse of the actual "call order." Therefore, after extracting all nodes, the fix suggestion generation system must perform a reversal operation on this node sequence. This reversal rearranges the sequence, starting from the "initial call node" (the last element of the original list) and ascending step by step, ultimately pointing to the node containing the "specific location" (the first element of the original list). The resulting ordered list of nodes representing the actual call flow is the "execution chain."

[0062] S203. Based on the specific location and execution chain, extract the execution code fragment for each exception problem. The execution code fragment represents the code fragment that can fully present the execution node of the exception problem.

[0063] Step S203 specifically includes steps S2031 to S2033, all of which are not shown in the figure.

[0064] S2031. Extract the complete source code of the method at the specific location as the basic code fragment, and trace upwards along the execution chain to locate the line of code in each upstream calling method that calls the downstream method.

[0065] The basic code snippet refers to the complete method source code containing the point where the exception occurred, which is first captured by the repair suggestion generation system. Upward tracing means that the repair suggestion generation system follows the execution chain, starting from the method where the exception occurred, tracing back to its caller, then to the caller's caller, and finally to the starting node of the chain. Upstream and downstream methods are relative concepts. In the execution chain, if method B calls method A, then method B is the upstream calling method of method A, and method A is the downstream method of method B. A line of code refers to the one or more lines of code found by the repair suggestion generation system in the upstream calling method that specifically executed the call to the downstream method.

[0066] Specifically, the fix suggestion generation system accesses the project's source code repository based on the specific location information, opens the corresponding source file, and parses the file to identify the entire method body containing that specific location. The system then copies the entire source code of this method, from its declaration to its end, and stores it as a "base code snippet." Next, the system initiates an iterative process, traversing the "execution chain" backwards (i.e., upwards). For each pair of adjacent methods in the execution chain (e.g., upstream method B and downstream method A), the main fix suggestion generation system analyzes the source code of upstream method B, aiming to pinpoint exactly which line of code calls downstream method A. Finally, the system records this precise call point location information in each upstream method. This process continues until all upstream nodes in the execution chain have been analyzed.

[0067] S2032. Expand the interception range upwards based on the line of code until the intercepted content contains the definition and assignment statements of all parameter variables passed to the downstream method.

[0068] Extending the capture range upwards refers to the process by which the fix suggestion generation system scans and selects code from the current method's (i.e., upstream method's) source code, starting from the line of code, and moving upwards (i.e., to an earlier point in the code execution order). All parameter variables passed to downstream methods refer to all variables or expressions actually passed to the downstream method within the parentheses in the calling line of code. Definition and assignment statements refer to the lines of code in the program that declare the type of these parameter variables, allocate memory (definition), or assign them specific values.

[0069] Specifically, the fix suggestion generation system first parses the call line of code, identifying all variable names passed as parameters. Then, targeting these variable names, the system scans the code line by line backward within the method, starting from the line preceding the call line. During the scan, the system continuously examines each line of code to determine if it defines or assigns a value to one of the target parameter variables. Once such a statement is found, the system marks it as needing to be included in the intercepted scope and records it. This upward scanning and marking process does not blindly continue to the beginning of the file but has a clear termination condition: the scanning process stops when the most recent definition or assignment statement for all parameter variables appearing in the call line has been found and marked. In this way, the fix suggestion generation system determines a minimal but complete code scope for each upstream method, which precisely covers the complete logic for preparing and setting all the input data required by the downstream method.

[0070] S2033. Add all the code within the extended interception range to the basic code fragment, up to the starting node of the execution chain, to obtain the executable code fragment.

[0071] The base code snippet is the complete source code of the method containing the point where the exception occurred, extracted by the fix suggestion generation system. The starting node of the execution chain refers to the first method in the entire method call chain, i.e., the entry point of the business logic. The executable code snippet is a coherent and context-complete collection of code that aggregates all relevant code from the start of the call chain to the point where the exception occurred.

[0072] Specifically, the fix suggestion generation system initializes a content container whose initial content is the basic code snippets. Then, the system processes the extended cutoff range determined for each upstream method in S2032, following the reverse execution chain (starting from the upstream method closest to the exception point and proceeding to the furthest starting node). In each iteration, the system adds the code within the extended cutoff range of the current upstream method to the front of the existing code snippets in the content container. Logically, the code snippets are arranged according to their actual execution order: the code of the first executing starting node is at the front, followed by the code of the method it calls, and so on, ending with the code of the method where the exception occurred. This iterative and appending process continues until the starting node of the execution chain has also been processed, resulting in the final executable code snippets.

[0073] S204. Based on the executed code fragments and execution links, construct the control flow graph and data dependency graph corresponding to the executed code fragments.

[0074] A control flow graph (CFG) is a directed graph used to represent all possible paths a program can follow during execution; a data dependency graph (DDG) is another type of directed graph that describes the data flow relationships between statements in a program.

[0075] Specifically, the fix suggestion generation system invokes a built-in or third-party static code analysis engine. This engine first performs lexical and syntactic analysis on the entire executable code segment, parsing it into one or more Abstract Syntax Trees (ASTs). Based on the AST, the fix suggestion generation system can identify basic blocks in the code and control flow statements such as if, for, and while, thereby constructing a control flow graph. Next, also based on the AST, the fix suggestion generation system analyzes the definition (def) and usage (use) of variables in each statement. By analyzing where a variable is defined and used, the fix suggestion generation system can establish data dependencies between statements, thereby constructing a data dependency graph. During this process, the execution chain helps the fix suggestion generation system correctly connect the control flow (from the call point to the entry point of the called method) and data flow (parameter passing and return values) between different methods, forming a control flow graph and data dependency graph covering the entire executable code segment.

[0076] S205. Starting from a specific location, perform syntactic analysis on the code at the specific location based on the anomaly type in the structured information, identify one or more suspect variables that are directly related to the anomaly type, and mark the suspect variables as tainted variables.

[0077] Syntax analysis refers to the process by which a fix suggestion generation system parses the structure of a specific line of code; a suspect variable is a variable in a line of code whose state (such as a value of null or an out-of-bounds value) is most likely to directly cause an exception of that specific type; a tainted variable is a term in the field of program analysis. Once a suspect variable is identified, the fix suggestion generation system will mark it with a "taint" tag, indicating that the source of this variable is suspicious and needs to be closely investigated.

[0078] Specifically, the remediation suggestion generation system first focuses on the specific line of code at the location of the exception, then queries the exception type associated with that exception. Based on this exception type, the system applies a predefined rule base for judgment. For example, if the exception is a NullPointerException, the rule base instructs the system to look for object reference variables (i.e., the variable that executes a method call or accesses a field) in the line of code that caused the exception. Then, the system performs a small-scale, fine-grained syntax analysis on that specific line of code to precisely identify which variables(s) match the rules and designate them as suspect variables. Finally, the system formally marks these variables as tainted variables, which is equivalent to issuing an instruction: trace back the tainted variables(s) to find out where their values ​​came from.

[0079] S206. Backtrack the tainted variables along the control flow graph and data dependency graph.

[0080] Backtracking is the core action of the entire data flow analysis. It refers to the repair suggestion generation system starting from the location where the tainted variable is used (i.e. the point where the anomaly occurs), using the data dependency graph to find the previous statement that defines or affects the value of the variable, and using the control flow graph to verify the legality of the path. This process is repeated step by step, backtracking to the earlier stages of code execution.

[0081] Specifically, the remediation suggestion generation system starts at the point where the exception occurred. It queries the data dependency graph to find all incoming edges related to the current tainted variable that point of use. The source nodes of these edges are the definition points (def) that might provide values ​​for the tainted variable—that is, the statements that assign or modify the variable. The remediation suggestion generation system then follows this dependency edge to the statement containing the definition point. Next, based on the control flow graph, the system checks whether a valid execution path exists between the definition point and the point of use, ensuring that the tracing process follows the program's actual possible execution logic. This loop of "backtracking based on data dependencies and then verifying with control flow" continues, locating an earlier execution node that affected the state of the tainted variable at each step.

[0082] S207. When a single execution node is a statement that assigns or modifies a tainted variable, update the tainted variable according to the source of the assignment.

[0083] A single execution node refers to the line of code or statement currently being analyzed; the source of the assignment refers to the expression on the right side of the assignment statement, or the source value of the modification operation.

[0084] Specifically, the repair suggestion generation system analyzes the code of the execution node in detail. If the node is an assignment statement (e.g., x=y or x=someFunction()), the system parses its assignment source. At this point, the core logic of taint analysis comes into play: the direct cause of variable x being tainted is this assignment statement. Therefore, the focus of the investigation needs to shift. The repair suggestion generation system removes the taint mark from x and then identifies all variables or expressions in the assignment source (e.g., y or the return value of someFunction()). These new variables or expressions inherit the taint and are marked as new tainted variables. Then, the repair suggestion generation system targets these new tainted variables and continues executing the reverse tracing loop of S206.

[0085] S208. Determine whether the assignment source is the return value of an external method call.

[0086] The source of the assignment refers to the expression or value that the repair suggestion generation system analyzes in step S207 to assign a value to the tainted variable; an external method call refers to a call to a method defined outside the currently executing code segment, which may come from a third-party library, framework, or other module in the project. The return value refers to the result returned after these external methods are executed.

[0087] Specifically, the fix suggestion generation system first analyzes the expression on the right-hand side of the assignment statement. If this expression is a method call (usually in the form of object.methodName(parameters) or className.staticmethodName(parameters)), the fix suggestion generation system further checks whether this method is an external method. The system checks whether the currently executing code segment contains the complete definition of the method. If the method definition is not found, or if the method clearly comes from an external library that the project depends on (determined by package name or class name prefix), then the fix suggestion generation system determines that the assignment source is the return value of an external method call. This determination directly affects subsequent analysis: if it is an external method call, then this may be the direct source of the exception, because the internal logic of the external method is not visible to the current analysis context.

[0088] S209. If the assignment source is the return value of an external method call, then the execution node of the external method call is determined as the direct source of the current exception problem.

[0089] The execution node of an external method call refers to the line of code that actually initiates the call to the external method. It contains complete context information about the method call, such as the caller object, method name, and input parameters. The direct source refers to the code location closest to the point where the exception occurred, which can explain the cause of the exception state.

[0090] Specifically, the remediation suggestion generation system records complete information about this external method call, including: the specific line of code where the call occurred, the full signature of the method, the passed parameter values ​​or expressions, and the call's position in the execution chain. This information is crucial for understanding the source of the exception, as it reveals how the program state transitions from a controllable internal environment to a point where it depends on external behavior. Once this direct source is identified, the remediation suggestion generation system stops tracing the current tainted variable further, as deeper analysis would require access to external code that is currently inaccessible.

[0091] S210. If the source of the assignment is not the return value of an external method call, then determine whether the source of the assignment is an input parameter of an external method, or a constant value that is directly assigned in the code and can cause an exception.

[0092] Input parameters of an external method refer to the values ​​passed from the parameter list of the current method. The actual values ​​of these parameters are determined externally by the caller of the method. Constant values ​​that can cause exceptions are values ​​that are written directly in the code and have special meanings. These values ​​may cause exceptions in a specific context, such as null.

[0093] Specifically, the fix suggestion generation system first checks if the assignment source is one of the parameters declared in the current method. This requires the system to examine the method signature and match the assignment source with the parameter list. If it is a parameter, it means the source of the problem may be with the caller; if it is not a parameter, the fix suggestion generation system further checks if the assignment source is a literal constant and whether the value of this constant might cause an exception in the current context. For example, if an object that might be dereferenced is directly assigned null, or an array index is assigned a number that is clearly out of range, these are constant values ​​that could cause exceptions.

[0094] S211. If not, the source variable that assigned the tainted variable will be treated as the new tainted variable, and the upstream code will continue to be reverse-tracked for analysis with the new tainted variable as the target.

[0095] Source variables refer to other variables that appear on the right-hand side of the assignment expression and provide values ​​for tainted variables. New tainted variables refer to variables that need to be continued to be tracked and whose new tags are generated by the repair suggestion system. Upstream code refers to the code segment that is located before the current analysis point in the program execution sequence. Reverse tracing analysis refers to the process of repeatedly executing steps S206 to S210.

[0096] Specifically, this step is executed after the repair suggestion generation system confirms that the assignment source is neither an external method return value nor a method parameter. This indicates that the current assignment operation is merely an intermediate step in the internal data flow of the program, and the real source of the problem needs to be traced further back. The repair suggestion generation system analyzes the right-hand side of the assignment expression to identify all variables involved in calculating the new value of the tainted variable. These variables may appear directly in the assignment statement or may be nested in more complex expressions. Once these source variables are identified, the repair suggestion generation system marks them all as new tainted variables. Then, the repair suggestion generation system restarts a round of retrospective analysis targeting these new tainted variables. This process is repeated until an external source is found (as described in step S209).

[0097] S212. If so, the current execution node containing the assignment operation is determined as the direct source of the current exception problem.

[0098] Assignment operations represent program statements that set or modify the value of variables; the current execution node represents the code statement being analyzed during the data flow tracing process.

[0099] Specifically, after confirming that the assignment source of the current execution node is an input parameter of an external method or a constant value that can cause an exception, the repair suggestion generation system marks this execution node containing the assignment operation as the direct source of the exception problem. This is because the value of the external input parameter is determined by the calling environment, and the repair suggestion generation system cannot further trace its source; while for directly assigned abnormal constant values ​​(such as null), they are the root cause of the problem themselves. Through this judgment, the repair suggestion generation system locates the code position where the abnormal state initially occurred.

[0100] S213. When the current execution node is the direct source of the current anomaly, stop the tracing analysis and determine the current execution node as the direct cause node of the current anomaly. (This step has been explained in S105 and will not be repeated here.) S214. Use a large language model to perform semantic analysis on the code sub-segments from the beginning to the direct cause node in the executed code segment to obtain the root cause of the abnormal problem and repair suggestions.

[0101] Step S214 specifically includes steps S2141 to S2146, all of which are not shown in the figure.

[0102] S2141. Use a large language model to perform semantic analysis on the executed code fragment to obtain the code intent and business scenario description of the executed code fragment.

[0103] Code intent represents the goals and functions of program design; business scenario description represents the usage environment and purpose of code in actual application.

[0104] Specifically, the repair suggestion generation system first inputs the executable code snippet into a large language model. Leveraging the large language model's code understanding capabilities, the system analyzes the code's structure, logical flow, and key operations. Through comprehensive analysis of variable naming, method signatures, code structure, and control flow, the system can understand the specific functions and design intent implemented by the code. Simultaneously, the system combines business-related identifiers and comments in the code to infer the business scenario served by the code, forming a complete understanding of the code at the business level.

[0105] S2142. By analyzing the naming conventions, comment documentation, exception type annotations, and associated test cases of the executed code snippets, infer the expected behavior of the executed code snippets in the corresponding business scenarios.

[0106] Naming conventions indicate how variables, methods, and classes are named in the code; comments and documentation indicate descriptive text in the code; exception type annotations indicate possible exceptions declared in the code; associated test cases indicate test code used to verify the functionality of the code; expected behavior indicates the functionality and effects that the code should exhibit under normal circumstances.

[0107] Specifically, the fix suggestion generation system first analyzes the naming conventions in the code, extracting functional semantics from the names, and then parses the comments in the code to obtain direct explanations of the code's functionality from the developers. Next, the system checks exception type annotations to understand possible exception scenarios in the code. Finally, the system analyzes the associated test cases, extracting the expected input and output behaviors from the test code. Through comprehensive analysis of this information, the fix suggestion generation system can accurately infer the behavior the code should exhibit in the business scenario—that is, the expected behavior.

[0108] S2143. Integrate the code sub-snapshots, exception types, code intent, and business scenario descriptions from the start to the direct cause node in the execution code snippet of each exception problem to obtain the comprehensive analysis input for each exception problem.

[0109] The comprehensive analysis input represents a complete analysis object containing multi-dimensional information.

[0110] Specifically, the remediation suggestion generation system integrates analysis results from various dimensions. First, it extracts key code snippets, ensuring a complete code path from the exception propagation point to the direct cause. Then, it adds exception type information to clarify the specific manifestation of the problem. Finally, it incorporates the previously analyzed code intent and business scenario description, providing complete contextual information. Through this integration of multi-dimensional information, the remediation suggestion generation system forms a comprehensive analytical input containing the complete context of the problem.

[0111] In some embodiments, information integration can be achieved in multiple ways: Optionally, the repair suggestion generation system can construct structured analysis objects, organizing various types of information according to a predefined format; alternatively, the repair suggestion generation system can use knowledge graph technology to integrate information from different dimensions through semantic association. It is understood that other methods can also be used to achieve information integration, which are not limited here.

[0112] S2144. Use a large language model to perform semantic analysis on the comprehensive analysis input to obtain the actual execution logic of the code sub-segments from the beginning to the direct cause node in the execution code segment.

[0113] Semantic analysis represents a deep understanding of the code execution process; actual execution logic represents the specific behavior of the code and the data flow process during runtime.

[0114] Specifically, the repair suggestion generation system provides the integrated analytical input to the large language model for in-depth analysis. Leveraging the large language model's code understanding capabilities, the system progressively parses the code execution flow, including variable definition, assignment, passing, and usage. The system pays particular attention to exception-related code paths, analyzing how data flows from the code's beginning to the direct cause node, and what transformations and processing occur during this process. Through this analysis, the system can construct a clear understanding of the actual code execution path, i.e., the actual execution logic.

[0115] In some embodiments, execution logic analysis can be implemented in multiple ways: optionally, the repair suggestion generation system can construct a detailed data flow graph to track the complete lifecycle of each key variable; optionally, the repair suggestion generation system can simulate the code execution process and record the state changes of each key node. It is understood that other methods can also be used to implement execution logic analysis, which are not limited here.

[0116] S2145. Identify the logical conflicts or missing links between the actual execution logic and the expected behavior.

[0117] Logical conflict points indicate the locations where the actual logic contradicts the expected behavior; missing steps indicate necessary processing steps that have been omitted in the code.

[0118] Specifically, the repair suggestion generation system compares and analyzes the actual execution logic with the previously inferred expected behavior. The system first examines each key execution step to determine if it conforms to the expected business rules and processing logic. When it finds that the result of an execution step does not match expectations, or that certain necessary checks and processes are missing from the code, the system marks these points. These marked points represent the logical conflicts or missing links between the actual execution logic and the expected behavior, as identified by the system.

[0119] S2146. Based on logical conflict points or missing links, generate the root cause of the abnormal problem, and based on the root cause, generate repair suggestions that conform to the code intent and business scenario of the abnormal problem.

[0120] The root cause indicates the essential problem causing the exception; the suggested fix indicates the specific code modification plan to resolve the exception.

[0121] Specifically, the remediation suggestion generation system conducts in-depth analysis based on identified problem points (logical conflicts or missing components). First, the system analyzes the nature of these conflicts or missing components, understanding the root cause of the problem in the context of the business scenario. Then, the system considers the original design intent of the code, ensuring that the remediation plan is consistent with the overall code architecture and business objectives. Finally, the system generates specific code modification suggestions that not only solve technical problems but also ensure that the modified code still meets business requirements.

[0122] After step S214, there are steps S215 to S217, which are not shown in the figure.

[0123] S215. Create a structured diagnostic data object for each exception in the project source code.

[0124] A structured diagnostic data object represents a standardized data structure used to store information related to anomalies; a diagnostic data object represents a data entity containing complete analytical information about the anomaly.

[0125] Specifically, the remediation suggestion generation system initializes a standardized data structure for each detected anomaly. First, the system defines a structural template for the diagnostic data object, including fields across multiple dimensions such as basic anomaly information, analysis process, problem location, and solution. Then, the system instantiates an independent diagnostic data object for each anomaly in the project, ensuring that each anomaly has a dedicated information carrier. This structured design ensures the standardized storage and subsequent processing of anomaly information.

[0126] S216. Match the original exception information of each exception with the corresponding executed code snippet, exception type, root cause, and repair suggestions, and populate it into the diagnostic data object.

[0127] Specifically, the repair suggestion generation system systematically organizes all the information obtained during the anomaly analysis process. First, it associates the original anomaly information with the previously analyzed executable code snippets. Then, it adds the specific type of the anomaly and populates the corresponding fields with the identified root cause and generated repair suggestions. Through this information matching and population, the system ensures that each diagnostic data object contains a complete chain of information related to the anomaly.

[0128] In some embodiments, information matching and population can be achieved in multiple ways: Optionally, the repair suggestion generation system can use a mapping table to ensure that various types of information accurately correspond to the correct fields; alternatively, the repair suggestion generation system can employ a validation mechanism to ensure the integrity and consistency of the populated information. It is understood that other methods can also be used to achieve information matching and population, which are not limited here.

[0129] S217. Collect all diagnostic data objects of abnormal issues to form a diagnostic report of the project source code.

[0130] A diagnostic report represents a systematic analysis and summary of all anomalies in a project; a compilation represents the organization of multiple diagnostic data objects into a complete report document.

[0131] Specifically, the remediation suggestion generation system integrates and organizes diagnostic data for all anomalies. First, it collects all analyzed diagnostic data objects and organizes them according to a predefined report structure. The system may categorize and sort the diagnostic data based on dimensions such as the severity, type, or module of the anomaly. Through this systematic organization, the system ultimately generates a complete project diagnostic report.

[0132] To facilitate understanding, the following example of a Java NullPointerException illustrates the above method. (Those skilled in the art will understand that the above method is not only applicable to NullPointerException, but also to other common runtime exceptions, such as array out-of-bounds exceptions and type conversion exceptions. Similar data flow tracing logic can be used to locate the direct cause of improper assignment or initialization and perform subsequent semantic analysis.) Suppose the original exception message shows that a null pointer exception occurred on line 58 of OrderService.java, with the code: user.getProfile().getAddress().

[0133] 1. The system first converts the exception stack into structured information, determines the specific location as OrderService.java:58, and parses the execution chain as: Controller→OrderService→UserService.

[0134] 2. Fix suggestion: Generate relevant code snippets from Controller, OrderService, and UserService.

[0135] 3. Starting from "OrderService.java:58", trace back to the variable 'user'. It is found that the 'user' object is returned by the `UserService.findUser(userId)` method. Entering `UserService` and continuing to trace, it is discovered that this method may return null under certain conditions. This point is marked as the "direct cause node".

[0136] 4. The system will submit information such as the code snippets containing the UserService.findUser method body and the OrderService call, the exception type (NullPointerException), and the code intent (querying user information to create an order) to the artificial intelligence model.

[0137] 5. After analyzing the large language model, the root cause was found to be that the core business process of creating an order failed to handle the boundary case where the user does not exist (the query result is null), and a user object that may be null was used directly.

[0138] 6. Large Language Model Generation Fix Recommendation: Before calling user.getProfile(), add a check for null values ​​in the user object. If user is null, a custom business exception UserNotFoundException should be thrown or an error message should be returned instead of continuing to execute subsequent logic.

[0139] The global anomaly semantic analysis and repair suggestion generation method in this application involves a repair suggestion generation system that first obtains the original anomaly information from the project source code and converts it into structured information. Then, it combines the anomaly type and stack trace to determine the specific location and execution path of the anomaly. Next, the system extracts execution code segments containing complete parameter definitions and assignments along the execution path. Subsequently, it constructs a control flow graph and a data dependency graph, uses tainted variables to trace back and locate the direct cause node, and finally uses a large language model to analyze key code segments to generate root causes and repair suggestions. This information is then integrated to form a diagnostic report, achieving a closed-loop process for anomaly analysis from data structuring, path location, code extraction, cause tracing to repair suggestion generation and report summarization. This alleviates the problems of insufficient depth into code logic and low investigation efficiency. Furthermore, it can generate repair suggestions based on business scenarios and achieve orderly integration of multiple anomaly information through structured diagnostic reports, significantly improving the efficiency and accuracy of anomaly handling.

[0140] The method provided in the above embodiments can be executed by the server of the repair suggestion generation system. The repair suggestion generation system in the embodiments of this invention is described below from a hardware processing perspective; please refer to [link to relevant documentation]. Figure 3 This is a schematic diagram of a physical device structure of the repair suggestion generation system in this application embodiment.

[0141] It should be noted that, Figure 3 The structure of the repair suggestion generation system shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of the present invention.

[0142] like Figure 3 As shown, the repair suggestion generation system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 302 or programs loaded from storage portion 308 into Random Access Memory (RAM) 303, such as performing the methods described in the above embodiments. Various programs and data required for system operation are also stored in RAM 303. The CPU 301, ROM 302, and RAM 303 are interconnected via bus 304. Input / output (I / O) interface 305 is also connected to bus 304.

[0143] The following components are connected to I / O interface 305: input section 306 including audio input devices, push-button switches, etc.; output section 307 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 308 including a hard disk, etc.; and communication section 309 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 309 performs communication processing via a network such as the Internet. Drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0144] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the various functions defined in the present invention.

[0145] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0146] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0147] Specifically, the repair suggestion generation system of this embodiment includes a processor and a memory. The memory stores a computer program. When the computer program is executed by the processor, it implements the global anomaly semantic analysis and repair suggestion generation method provided in the above embodiment.

[0148] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the repair suggestion generation system described in the above embodiments; or it may exist independently and not assembled into the repair suggestion generation system. The storage medium carries one or more computer programs that, when executed by a processor of the repair suggestion generation system, cause the repair suggestion generation system to implement the global anomaly semantic analysis and repair suggestion generation method provided in the above embodiments.

[0149] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application 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 of the technical features. Such 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 this application.

[0150] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0151] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0152] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for global exception semantic analysis and repair suggestion generation, characterized in that, The method comprises the following steps: Obtain the original exception information of all abnormal problems in the project source code, and convert the original exception information into structured information; Determine the specific location and execution link of each abnormal problem in the project source code according to the exception type and stack trace information in the structured information; Based on the specific location and the execution link, intercept the execution code segment of each abnormal problem, which represents the code segment of the execution node that can completely present the abnormal problem; Based on the execution link, use the data flow tracing technology to analyze the execution operation of a single execution node in execution order from back to front, and determine whether the current execution node is the direct source of the current abnormal problem; When the current execution node is the direct source of the current abnormal problem, stop tracing analysis, and determine the current execution node as the direct cause node of the current abnormal problem; Use a large language model to perform semantic analysis on the code sub-segment from the beginning to the direct cause node in the execution code segment, and obtain the root cause and repair suggestion of the abnormal problem.

2. The method of claim 1, wherein, According to the exception type and stack trace information in the structured information, the specific location and execution link of each abnormal problem in the project source code are determined, specifically including: Parse the stack trace information in the structured information to obtain an ordered list containing multiple stack frames; Extract the class name, method name and code line number of the first stack frame in the ordered list, and map the code line number to the specific location of the abnormal problem; Traverse all stack frames in the stack trace information, extract the class name and method name of each stack frame, and concatenate them in the order of call to form an execution link from the initial call node to the specific location.

3. The method of claim 1, wherein, Based on the specific location and the execution link, the execution code segment of each abnormal problem is intercepted, specifically including: Extract the complete source code of the method where the specific location is located as a basic code segment, and trace upwards along the execution link to locate the code line that calls the downstream method in each upstream calling method; Based on the code line, expand the interception range upwards until the interception content contains the definition and assignment statements of all parameter variables passed to the downstream method; Add all the code in the expanded interception range to the basic code segment until the starting node of the execution link to obtain the execution code segment.

4. The method of claim 1, wherein, Based on the execution link, the execution operation of a single execution node is analyzed in execution order from back to front using the data flow tracing technology, specifically including: Based on the execution code segment and the execution link, construct the control flow graph and data dependency graph corresponding to the execution code segment; Take the specific location as the tracing starting point, perform syntax analysis on the code of the specific location according to the exception type in the structured information, identify one or more suspicious variables directly related to the exception type, and mark the suspicious variables as tainted variables; Trace the tainted variables in reverse along the control flow graph and the data dependency graph; updating the tainted variable according to a source of the assignment when a single execution node is a statement of assigning or modifying the tainted variable; determining whether the current execution node of the analysis is a direct source of the current abnormal problem.

5. The method of claim 4, wherein, The determining whether the current execution node of the analysis is a direct source of the current abnormal problem specifically includes: determining whether the source of the assignment is a return value of an external method call; if the source of the assignment is the return value of the external method call, determining an execution node of the external method call as the direct source of the current abnormal problem; if the source of the assignment is not the return value of the external method call, determining whether the source of the assignment is an input parameter of the external method or a constant value directly assigned in the code and capable of causing an exception; if yes, determining a current execution node containing an assignment operation as the direct source of the current abnormal problem; if no, taking a source variable of the assignment of the tainted variable as a new tainted variable, and continuing to perform the reverse trace analysis on upstream code with the new tainted variable as a target.

6. The method of claim 1, wherein, The utilizing the large language model to perform semantic analysis on the code sub-fragments from the start to the direct cause node in the execution code fragment to obtain the root cause and the repair suggestion of the abnormal problem specifically includes: utilizing the large language model to perform semantic analysis on the execution code fragment to obtain a code intention and a business scenario description of the execution code fragment; inferred expected behaviors of the execution code fragment under corresponding business scenarios by analyzing naming specifications, annotation documents, exception type annotations, and associated test cases of the execution code fragment; integrated the code sub-fragments from the start to the direct cause node in the execution code fragment of each abnormal problem, the exception type, the code intention, and the business scenario description to obtain comprehensive analysis inputs of each abnormal problem; utilized the large language model to perform semantic analysis on the comprehensive analysis inputs to obtain actual execution logic of the code sub-fragments from the start to the direct cause node in the execution code fragment; identified logical conflict points or missing links between the actual execution logic and the expected behaviors; generated the root cause of the abnormal problem based on the logical conflict points or the missing links, and generated repair suggestions conforming to the code intention and the business scenario of the abnormal problem based on the root cause.

7. The method of claim 1, wherein, After the step of utilizing the large language model to perform semantic analysis on the code sub-fragments from the start to the direct cause node in the execution code fragment to obtain the root cause and the repair suggestion of the abnormal problem, the method further includes: creating a structured diagnosis data object for each abnormal problem in the project source code; matching original abnormal information of each abnormal problem with corresponding execution code fragments, exception types, root causes, and repair suggestions, and filling into the diagnosis data object; collecting diagnosis data objects of all abnormal problems to form a diagnosis report of the project source code.

8. A repair recommendation generation system characterized by, comprises one or more processors and a memory; The memory is coupled with the one or more processors, the memory to store computer program code including computer instructions to be invoked by the one or more processors to cause the repair recommendation generation system to perform the method of any of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are run on a repair recommendation generation system, cause the repair recommendation generation system to perform the method of any of claims 1-7.

10. A computer program product, characterised in that, When the computer program product is run on a repair recommendation generation system, cause the repair recommendation generation system to perform the method of any of claims 1-7.

Images