A code debugging method and device, electronic equipment and storage medium

Abstract

The application provides a code debugging method and device, electronic equipment and storage medium, and belongs to the technical field of software engineering. The method comprises the following steps: injecting a first probe into a to-be-monitored method in target code, and collecting running data based on the first probe; whenever a debugging condition is triggered, constructing current to-be-analyzed data based on the running data of the to-be-monitored method, taking the to-be-monitored method as a current method, and executing the following abnormal reasoning processing: performing abnormal analysis on the current to-be-analyzed data by using a debugging reasoning model, generating a problem hypothesis chain; judging whether the problem hypothesis chain has been verified; if not, collecting running data of an upstream method based on a second probe, adding the running data of the upstream method to the current to-be-analyzed data, taking the upstream method as the current method, and returning to the abnormal reasoning processing; if yes, ending the abnormal reasoning processing, and generating an abnormal analysis result of the to-be-monitored method. By using the application, the problem positioning efficiency and the debugging accuracy can be improved.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and in particular to a code debugging method, apparatus, electronic device, and storage medium. Background Technology

[0002] Existing AI (Artificial Intelligence) programming tools (such as Claude Code, GitHub Copilot, Codex, etc.) can generate high-quality source code, but their capabilities for runtime debugging and program behavior analysis are extremely limited. These tools mainly rely on static code analysis and contextual semantic prediction, making it difficult to accurately capture the exception propagation chain in the dynamic execution path.

[0003] While existing debugging tools (such as IDE debuggers, JFR, JDB, etc.) allow manual setting of breakpoints and viewing of variables, they involve significant manual intervention, are complex to operate, and are unsuitable for locating dynamic problems in production environments. Furthermore, traditional log analysis struggles to meet the automated tracing needs of complex distributed systems with multi-layered function nesting and asynchronous calls.

[0004] Therefore, there is an urgent need for a code debugging method that combines the semantic reasoning capabilities of a Large Language Model (LLM) with a runtime sampling probe mechanism to achieve intelligent analysis and problem localization of the application's code execution process, thereby improving the efficiency of problem localization and the accuracy of debugging. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a code debugging method, apparatus, electronic device, and storage medium, which can improve the efficiency of problem location and the accuracy of debugging.

[0006] According to one aspect of the present invention, a code debugging method is provided, the method comprising: When debugging the target code, a first probe is injected into the method to be monitored in the target code, and the running data of the method to be monitored is collected based on the first probe; Whenever the debugging conditions of the monitored method are triggered, the current data to be analyzed is constructed based on the running data of the monitored method, and the monitored method is taken as the current method. The following abnormal reasoning processing is performed: abnormal analysis is performed on the current data to be analyzed through the debugging reasoning model to generate a problem hypothesis chain, which includes the upstream method that calls the current method. Determine whether the chain of assumptions in the problem has been verified; If not, then based on the second probe, the running data of the upstream method is collected, the running data of the upstream method is added to the current data to be analyzed, the upstream method is used as the current method, and the abnormal reasoning process is returned. If so, the abnormal reasoning process ends, and the abnormal analysis result of the method to be monitored is generated.

[0007] According to another aspect of the present invention, a code debugging apparatus is provided, the apparatus comprising: The probe acquisition unit is used to inject a first probe into the method to be monitored in the target code when debugging the target code, and to collect the running data of the method to be monitored based on the first probe. An anomaly analysis unit is used to construct current analysis data based on the runtime data of the monitored method whenever the debugging conditions of the monitored method are triggered, and to take the monitored method as the current method, and perform the following anomaly reasoning process: perform anomaly analysis on the current analysis data through a debugging reasoning model to generate a problem hypothesis chain, the problem hypothesis chain including the upstream method that calls the current method; determine whether the problem hypothesis chain has been verified; if not, then in the probe acquisition unit, collect the runtime data of the upstream method based on the second probe, add the runtime data of the upstream method to the current analysis data, take the upstream method as the current method, and return the anomaly reasoning process; if yes, then end the anomaly reasoning process and generate the anomaly analysis result of the monitored method.

[0008] According to another aspect of the present invention, an electronic device is provided, comprising: Processor; and Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the code debugging method.

[0009] According to another aspect of the present invention, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are used to cause a computer to execute the above-described code debugging method.

[0010] In this invention, during the debugging of target code, a first probe is injected into a specific method to be monitored, and runtime data of the monitored method is collected based on the first probe. Whenever a debugging condition is triggered, an anomaly analysis is performed on the current data to be analyzed based on the runtime data of the monitored method using a debugging inference model, generating a problem hypothesis chain. If the problem hypothesis chain is not verified, the process recursively backtracks to at least one upstream method, and runtime data of the upstream method is collected based on a second probe. This upstream method's runtime data is then added to the current data to be analyzed, enabling the debugging inference model to perform multiple rounds of anomaly inference. This continues until the problem hypothesis chain is verified, generating the corresponding anomaly analysis results. Based on this, the analysis scope is dynamically expanded at runtime, enabling bottom-up "on-demand backtracking" debugging, improving problem location efficiency and debugging accuracy. Attached Figure Description

[0011] Further details, features, and advantages of the invention are disclosed in the following description of exemplary embodiments in conjunction with the accompanying drawings, in which: Figure 1 A flowchart of a code debugging method according to an exemplary embodiment of the present invention is shown; Figure 2 This diagram illustrates the first stage of system initialization and JavaAgent injection according to an exemplary embodiment of the present invention. Figure 3 A flowchart of a probe data capture algorithm provided according to an exemplary embodiment of the present invention is shown; Figure 4 This diagram illustrates the second stage of method execution and sampling triggering according to an exemplary embodiment of the present invention. Figure 5 A flowchart of the intelligent sampling strategy algorithm provided according to an exemplary embodiment of the present invention is shown; Figure 6 A schematic diagram of the third stage of MCP coordination and AI triggering provided according to an exemplary embodiment of the present invention is shown; Figure 7 A schematic diagram of the fourth stage of AI analysis and debugging inference provided according to an exemplary embodiment of the present invention is shown; Figure 8 A schematic diagram of the fifth stage of call chain backtracking and progressive expansion provided according to an exemplary embodiment of the present invention is shown; Figure 9 A schematic diagram of the sixth stage of intelligent report generation and result display provided according to an exemplary embodiment of the present invention is shown; Figure 10 A schematic diagram of the seventh stage of continuous learning and policy adaptation provided according to an exemplary embodiment of the present invention is shown; Figure 11A schematic block diagram of a code debugging apparatus according to an exemplary embodiment of the present invention is shown; Figure 12 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0012] Embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the invention. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the invention.

[0013] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0014] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this invention are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0015] It should be noted that the terms "a" and "a plurality of" used in this invention are illustrative rather than restrictive. Those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0016] The names of the messages or information exchanged between the multiple devices in the embodiments of the present invention are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0017] This invention provides a code debugging method, which can be performed by a terminal, server, and / or other devices with processing capabilities. The method provided in this embodiment can be performed by any of the aforementioned devices, or by multiple devices working together; this invention does not limit this approach.

[0018] This embodiment uses a Java system as an example. This code debugging method can be completed collaboratively by JavaAgent, MCP (Model Context Protocol), and the large language model (hereinafter collectively referred to as the debugging inference model). Of course, the MCP layer design can also be extended to multi-language ecosystems (Python, Go, Rust, etc.), but this embodiment does not limit it to this.

[0019] The following will refer to Figure 1 A flowchart illustrating a code debugging method is provided, and the method is described below. The method includes the following steps 101-105.

[0020] Step 101: When debugging the target code, inject the first probe into the method to be monitored in the target code, and collect the running data of the method to be monitored based on the first probe.

[0021] In one possible implementation, such as Figure 2 The system initialization and the first phase of JavaAgent injection are illustrated. In this first phase, when debugging the target code of a Java application, the user can add the JavaAgent provided by this invention to the startup parameters of the Java application. At application startup, the JavaAgent intercepts the JVM (Java Virtual Machine) class loader through the premain method. The JavaAgent reads the initial debugging strategy (such as the package name, class name, method name, sampling rate, etc. to be monitored) issued by the configuration file or MCP. In this embodiment, dynamic injection of probes based on conditions such as function name, sampling rate, and thread name is supported.

[0022] Subsequently, the JavaAgent can dynamically enhance the bytecode of the target class using bytecode enhancement techniques, injecting probe logic into at least one selected method to be monitored. It also initializes local event channels (such as Socket, gRPC, or Named Pipe) for establishing communication with the MCP.

[0023] For ease of explanation, the probe injected into the method to be monitored here will be called the "first probe", and the probe dynamically injected into the upstream method in the subsequent tracing process will be called the "second probe".

[0024] Through probe logic, key runtime data can be collected during the execution of the method to be monitored, which serves as the method's runtime data. This allows for real-time monitoring and anomaly identification of the method's runtime status.

[0025] Optionally, to achieve data acquisition in a low-intrusive manner, this embodiment employs a lightweight probe, distributing the acquisition logic across method entry and exit. For example... Figure 3 The flowchart of the probe data acquisition algorithm shown includes the following steps 301-304: Step 301: Whenever the target code runs to the target method that has been injected with the target probe, capture the input parameters of the target method; Step 302: During the execution of the target method, asynchronously record the call stack information of the target method in the current thread; Step 303: When the target method exits, capture the return value and execution status of the target method; Step 304: Encapsulate the input parameters, call stack information, return value, and execution status of the target method into runtime data of the target method.

[0026] The target method for injecting the target probe can refer to the method to be monitored by injecting the first probe, i.e., the method determined by the pre-configured initial debugging strategy; or it can refer to the upstream method for injecting the second probe, i.e., the upstream method that is dynamically identified and enhanced during the source tracing analysis.

[0027] In one possible implementation, such as Figure 4 The illustrated second phase of method execution and sampling triggering involves the first probe automatically activating and executing data acquisition logic whenever the target code reaches the monitored method injected with the first probe. Upon entering the monitored method, a timestamp and thread information (such as thread identifier and thread context) are recorded, and its input parameters (such as the method's primitive type and object type) are captured. If the method is an instance method, snapshots of object member variables can also be collected synchronously. After the input parameters are collected, the original logic of the method is executed, and during the method's execution, the current thread's call stack information is recorded asynchronously. This call stack information may include information about at least one upstream method that called the method, such as the upstream method's class name, method name, line number, and call order. When the monitored method completes execution and exits, the first probe is reactivated to capture the method's return value and execution status (such as success, exception, timeout).

[0028] The collected data is encapsulated into events in a unified JSON format and sent asynchronously to the debugging control layer of the debugging inference model via an event channel (such as Socket or MCP message interface).

[0029] As a concrete example, a structured JSON event object can include the following fields: { "method": "com.example.Service.processOrder", "args": { "orderId": 123, "user": "alice"}, "thread": "pool-1-thread-3", "stack": [...], "timestamp": 1735061991200 } Where method represents the method name, args represents the method parameters, thread represents the thread name, stack represents the call stack, and timestamp represents the timestamp.

[0030] The probe data capture algorithm described above can achieve method-level input / output and context tracking without blocking business threads.

[0031] Optionally, before being sent to the debugging control layer of the debugging inference model, the aforementioned events can be cached in memory by the event acquisition module. The corresponding processing may include: after acquiring the runtime data of the method to be monitored based on the first probe, caching the runtime data of the method to be monitored based on the current sampling rate of the method.

[0032] like Figure 5 The flowchart of the intelligent sampling strategy algorithm shown below indicates that the current sampling rate of the method to be monitored can be determined through the following process: Monitor the call frequency of the method to be monitored; Determine the target frequency range to which the call frequency of the method to be monitored belongs, and set the base sampling rate corresponding to the target frequency range to the method to be monitored. The target frequency range includes a first frequency range or a second frequency range. If the minimum value of the first frequency range is greater than the maximum value of the second frequency range, then the base sampling rate corresponding to the first frequency range is lower than the base sampling rate corresponding to the second frequency range. If an anomaly in system performance is detected, the current sampling rate of the method to be monitored is increased; Once the system performance returns to normal, restore the current sampling rate of the method to be monitored to the base sampling rate.

[0033] In one possible implementation, after encapsulating the collected data into a JSON event, the system can determine whether the sampling policy conditions are met based on the current sampling rate. For example, a random number is generated for the current JSON event. If the random number is less than the current sampling rate, the sampling policy conditions are met, and the JSON event is sent to the event acquisition module for caching. If the random number is greater than or equal to the current sampling rate, the JSON event is either discarded or cached later.

[0034] The event acquisition module can asynchronously push at least one cached JSON event to the MCP, which will then uniformly schedule it to the debugging control layer of the debugging inference model for analysis and anomaly attribution.

[0035] The current sampling rate can be dynamically adjusted by the system, or dynamically adjusted by receiving a sampling rate setting command from the debugging inference model. Specifically, for example... Figure 5 As shown, the invocation status of the methods to be monitored can be monitored, and the invocation frequency of each method to be monitored can be statistically analyzed. The invocation frequency of each method to be monitored can be categorized into three levels: high frequency (>100 times / second), medium frequency (10–100 times / second), and low frequency (<10 times / second). Alternatively, it can be categorized into two levels: high frequency (>50 times / second) and low frequency (≤50 times / second). This embodiment does not limit the specific frequency range division.

[0036] Each frequency range corresponds to a different base sampling rate, following the principle of "high frequency, low sampling; low frequency, high sampling." That is, the more frequently a method is called, the lower the base sampling rate, in order to balance monitoring overhead and data representativeness; conversely, the base sampling rate is increased when sparsely called methods to ensure that anomalies are not missed. For example, low-frequency called methods can use a high sampling rate (such as 90%), while high-frequency called methods can be sampled in stages (such as sampling once every 100 executions, i.e., a sampling rate of 1%).

[0037] Based on the statistically obtained call frequency, the method to be monitored can be automatically classified into the corresponding frequency range, and its base sampling rate can be dynamically loaded as the current sampling rate to make sampling decisions for the JSON events collected by the method. If abnormal system performance is detected (such as off-heap memory growth, frequent GC (Garbage Collection), or sudden increase in latency), the system temporarily increases the current sampling rate of the method to be monitored and enters enhanced monitoring mode to improve the ability to capture anomalies.

[0038] The system monitors the recovery status of anomalies in real time. Once the anomaly subsides and the performance returns to normal, and the system performance is confirmed to have returned to normal (e.g., if the abnormal indicator falls back to the threshold range and continues to stably exceed the preset observation window (e.g., 30 seconds), the current sampling rate of the monitored method will be automatically reverted to the corresponding basic sampling rate, returning to the low-intrusion mode.

[0039] The aforementioned intelligent sampling strategy algorithm performs sampling control based on multi-dimensional feedback from system operating status, method call frequency, and system anomaly indicators. It dynamically adjusts the sampling frequency and granularity under different operating loads to balance system performance and debugging accuracy.

[0040] Subsequently, based on historical sampling data and the analysis results of the debugging inference model, the priority of each method to be monitored and the threshold for dividing the above frequency range can be continuously optimized to form a feedback loop and realize the adaptive evolution of the intelligent sampling strategy.

[0041] The above describes the process of collecting runtime data for the method to be monitored. After that, whenever the debugging conditions for the method are triggered, you can jump to step 102 to perform anomaly analysis on the method.

[0042] Step 102: Whenever the debugging condition of the monitored method is triggered, the current data to be analyzed is constructed based on the running data of the monitored method. The monitored method is taken as the current method, and the following abnormal reasoning processing is performed: abnormal analysis is performed on the current data to be analyzed through the debugging reasoning model to generate a problem hypothesis chain.

[0043] The problem hypothesis chain includes the upstream methods that call the current method.

[0044] In one possible implementation, such as Figure 6 The diagram illustrates the third phase of MCP coordination and AI triggering. In this phase, MCP continuously monitors data streams or log streams from various probes (including the first and second probes) and detects abnormal patterns (such as abnormal stack traces, sudden increases in latency, and abnormal return values) in the monitored data streams or log streams. Whenever an abnormal pattern is detected, debugging conditions are triggered for the corresponding monitored method. Alternatively, debugging conditions are triggered for the corresponding monitored method whenever a user-initiated debugging request is received, or a debugging instruction is received from the debugging inference model.

[0045] At this point, MCP can activate the debug inference model collaboration process, construct the runtime data and related data of the method to be monitored into the current data to be analyzed, encapsulate it into a context request package, and send it to the debug inference model.

[0046] Optionally, the aforementioned current data to be analyzed may include the current running data of the method to be monitored, estimated anomaly metadata, and multiple cached historical running sample data. The process of constructing the current data to be analyzed may include: Obtain the estimated anomaly metadata, as well as multiple cached historical runtime sampling data; Based on the operational data of the method to be monitored, the estimated anomaly metadata, and multiple historical operational sampling data, the current data to be analyzed is constructed.

[0047] In one possible implementation, the estimated anomaly metadata may include relevant data corresponding to the detected anomaly patterns. Historical runtime sampling data may include multiple JSON events historically pushed to the MCP by the event acquisition module, not limited to JSON events corresponding to the runtime data of the method to be monitored. The current runtime data (including the method's current execution data (such as input parameters) and the most recent call stack) corresponding to the method to be monitored when the debugging condition is triggered is combined with the estimated anomaly metadata and multiple historical runtime sampling data to construct the current data to be analyzed, and then encapsulated into a context request package and sent to the debugging inference model.

[0048] Optionally, the debugging inference model can control the debugging behavior of the target code runtime through a preset instruction interface to verify the generated problem hypothesis chain. In order to enable the debugging inference model to actively control the runtime debugging behavior, rather than just passively receiving logs, MCP can provide a unified instruction interface for the debugging inference model. The debugging inference model can pre-register these interfaces so that corresponding instructions can be issued during the debugging process.

[0049] The default command interface may include any one or more of the following: The call stack instruction interface (such as GET_STACK(id)) is used to retrieve the call stack information of a specified method; The upstream method instruction interface (such as TRACE_UPSTREAM(id)) is used to request sampling of the upstream method in order to obtain the execution data of the upstream method; The Get Object Field Command Interface (such as GET_FIELD(objectId)) is used to retrieve the status information of a specified object field; The sampling rate setting command interface (such as SET_SAMPLING_RATE(class, rate)) is used to adjust the current sampling rate of a specified method.

[0050] After receiving the context request packet, the debugging inference model can parse the current data to be analyzed and construct prompts based on this data. These prompts then enable the debugging inference model to perform semantic analysis and logical reasoning, thereby inputting the corresponding chain of hypothesis statements. Specific processing may include: Based on the call stack information in the runtime data of the method to be monitored and at least one upstream method, the reference relationship between the method to be monitored and at least one upstream method is resolved; Based on multiple historical operational sampling data, the variable change trends of each variable in the method to be monitored and at least one upstream method are analyzed; Based on the estimated abnormal metadata, detect existing abnormal patterns; Generate a chain of hypotheses based on reference relationships, variable change trends, and anomaly patterns; In one possible implementation, such as Figure 7 The fourth stage of AI analysis and debugging inference is shown. In this stage, the current data to be analyzed includes the call stack information of the method to be monitored. After adding the execution data of at least one upstream method, it can also include the call stack information of the upstream method. Based on this, the debugging inference model can parse the reference relationship between the method to be monitored and at least one upstream method according to the call stack information, thereby analyzing the data flow and dependency path between methods and constructing a function call tree based on the method to be monitored.

[0051] Debugging inference models can also be based on multiple historical sampling data to extract the value sequences of each variable at different time points, thereby comparing the variable change trends of each variable in multiple samplings.

[0052] Meanwhile, the debugging inference model can also detect typical abnormal patterns in the estimated abnormal metadata, such as null pointer propagation, unreleased memory, and circular dependencies, thereby identifying the existing abnormal patterns.

[0053] Furthermore, the debugging inference model integrates reference relationships, variable change trends, and abnormal patterns to generate a hypothesis chain.

[0054] As a concrete example, the chain of assumptions generated by the debugging inference model can be as follows: Step 1: Method A calls method B with input parameter x = null (the input parameter is empty); Step 2: Method B failed to validate its call to method C; Step 3: A NullPointerException is thrown in method C. Root cause: Input parameters were not checked in method A.

[0055] Step 103: Determine whether the problem hypothesis chain has been verified.

[0056] In one possible implementation, the debugging inference model can validate the problem hypothesis chain based on multiple historical runtime sampling data. For example, for the aforementioned problem hypothesis chain example, the frequency of occurrence of method A with x being null in historical sampling, the coverage of unverified trigger conditions of method B, and the occurrence rate of exceptions thrown by method C can be statistically compared with stack consistency across multiple historical runtime sampling data. If all three are significantly higher than a threshold, the problem hypothesis chain passes validation and proceeds to step 105 to locate the root cause as the input parameters were not checked in method A. Otherwise, the problem hypothesis chain fails validation and requires more runtime data for verification, proceeding to step 104 to backtrack and progressively expand the call chain.

[0057] Step 104: If the problem hypothesis chain is not verified, the running data of the upstream method is collected based on the second probe, the running data of the upstream method is added to the current data to be analyzed, the upstream method is used as the current method, and the abnormal reasoning is returned.

[0058] In one possible implementation, such as Figure 8 The fifth stage of the call chain backtracking and progressive expansion is shown. In this fifth stage, the debugging inference model can send a backtracking request to the MCP via the upstream method tracing instruction interface. This backtracking request can include information about the upstream method to be backtracked, such as the name and identifier of the upstream method. The information about the upstream method can be obtained from the current method's call stack information. After receiving the backtracking request, the MCP can notify the JavaAgent via the upstream method tracing command, locate the upstream method using the information of the upstream method, and activate the second probe to collect the runtime data of the upstream method. The second probe can be pre-injected or dynamically injected on demand.

[0059] Optionally, to improve the accuracy of data acquisition, this embodiment employs progressive backtracking sampling, dynamically injecting the aforementioned second probe as needed, activating acquisition only when backtracking conditions are triggered, thus avoiding the performance loss caused by full data embedding. Accordingly, the process of dynamically injecting the second probe may include: Based on the execution data of the current method, obtain the call stack information of the current method; Based on the call stack information, determine the upstream method; Detect whether the upstream method has injected a probe; If not, a second probe is injected into the upstream method to collect the running data of the upstream method based on the second probe; If so, the second probe that has been injected into the upstream method is activated, and the running data of the upstream method is collected based on the second probe.

[0060] In one possible implementation, after locating the upstream method of the current method based on the call stack information, it can be checked whether the upstream method already has probe logic (i.e., a second probe). If it does exist, the existing second probe is directly activated to collect the runtime data of the upstream method; if it does not exist, the second probe is dynamically injected and activated, and the runtime data of the upstream method is collected through the second probe. The specific process of collecting the runtime data of the upstream method based on the second probe is the same as the collection process of the first probe described above, and will not be repeated here.

[0061] The collected runtime data of the upstream method is pushed to MCP. MCP can merge this data with the existing data to be analyzed to form a new context request packet, which is then sent to the debug inference model again. This returns to step 102 above, triggering a new round of anomaly inference and hypothesis verification, thereby achieving multi-round semantic analysis and logical reasoning.

[0062] If the problem hypothesis chain remains unverified, the process continues to backtrack upwards to the next upstream calling node until the system entry point is reached or the problem hypothesis chain is verified. Based on this, the analysis scope is dynamically expanded at runtime, enabling bottom-up "on-demand backtracking" debugging, thereby recursively constructing a complete upstream and downstream data link.

[0063] Step 105: If the problem hypothesis chain has been verified, the abnormal reasoning process ends and the abnormal analysis results of the method to be monitored are generated.

[0064] In one possible implementation, such as Figure 9 The sixth stage of the intelligent report generation and result display is shown. In this sixth stage, if the problem hypothesis chain has been verified, the anomaly reasoning process ends, the debugging reasoning model completes the full-link analysis, generates the anomaly analysis results of the method to be monitored, and pushes them to MCP. MCP encapsulates the results into a visualized intelligent report and pushes the report to the user interface, IDE (Integrated Development Environment) plugin, debugging console, etc., for users to view in real time.

[0065] Specifically, the process of generating anomaly analysis results for the method to be monitored may include: Based on reference relationships and verified problem hypothesis chains, construct function call trees and exception paths based on the methods to be monitored; Construct a timeline of variable changes based on the trend of variable changes; Based on the validated chain of problem hypotheses, the root cause of the problem is identified, and corresponding modification suggestions are generated. Based on the function call tree, exception path, variable change timeline, root cause of the problem, and corresponding modification suggestions, the exception analysis results are encapsulated.

[0066] In one possible implementation, during the AI ​​analysis and debugging inference process described above, the debugging inference model can parse the reference relationships between the monitored method and at least one upstream method based on the call stack information, thereby analyzing the data flow and dependency paths between methods and constructing a function call tree based on the monitored method. After the problem hypothesis chain is verified, the critical path leading to the propagation of the exception in the function call tree can also be determined, thus obtaining the corresponding exception path.

[0067] Debugging inference models can also be based on multiple historical sampling data to extract the value sequences of each variable at different time points, thereby comparing the variable change trends of each variable in multiple samplings, fitting change curves, and constructing variable change timelines.

[0068] Once the problem hypothesis chain is verified, the root cause of the problem can be determined. The debugging inference model can then generate a root cause description and targeted code modification suggestions based on the root cause, combined with the semantics of the code context and common repair patterns. For example, "The cause of the exception may be that the input parameters were not checked in method A. It is recommended to move the null pointer check to the method entry point."

[0069] The debugging inference model can push the above anomaly analysis results (i.e., function call tree, anomaly path, variable change timeline, root cause of the problem, and corresponding modification suggestions) to MCP, which will then encapsulate them into a structured intelligent report. As a specific example, this report may include an interactive call tree view, a timeline diagram highlighting the anomaly path, a variable trend comparison chart, root cause location markers, and a one-click adopted code snippet for fixing the issue. This embodiment does not limit the presentation format of the intelligent report.

[0070] After viewing the intelligent report, users can interact with it via natural language on the corresponding interface. For example, they can ask users to "show a snapshot of the input parameters when the anomaly occurred," "view the upstream call of method A," or "generate a code snippet for suggested repairs." MCP can upload the natural language input by the user to the debugging inference model. The model parses the semantic intent in real time, generates corresponding instructions, and issues the instructions through the aforementioned preset instruction interface. This allows the model to perform operations such as calling existing data or triggering new sampling, forming a closed-loop, conversational debugging experience and improving the intelligence level of the observability system.

[0071] Optionally, this embodiment also supports continuous model learning and policy adaptation, and the corresponding processing may include: Determine the actual root cause corresponding to the debugging conditions that trigger the monitored method; Determine the difference between the actual root cause and the root cause of the problem recorded in the anomaly analysis results; Based on the differences, the threshold and base sampling rate of the target frequency range are optimized; Based on the differences, the sampling priority and input prompts for the debugging inference model of each method to be monitored are adjusted; Debugging samples are constructed based on the target code and anomaly analysis results, and the debugging inference model is adjusted based on the debugging samples.

[0072] In one possible implementation, such as Figure 10 The seventh stage of continuous learning and policy adaptation is shown. In this stage, the actual root cause corresponding to the triggering of the above-mentioned debugging conditions can be determined by minimizing reproducible test cases. Alternatively, the actual root cause can be confirmed by manually labeling it. This embodiment does not limit the method of confirming the actual root cause.

[0073] After the actual root cause is identified, MCP can record the difference between the actual root cause and the root cause in the model's inference, and feed this information back to the aforementioned intelligent sampling strategy algorithm. This algorithm drives the algorithm to dynamically adjust the priority and sampling threshold of the monitored methods to improve data collection quality. Furthermore, it can optimize the prompt word engineering of the debugging inference model based on the differences, thereby optimizing the prompt word template to better fit the semantic habits of code debugging scenarios. Based on this, the accuracy of anomaly diagnosis can be improved.

[0074] Furthermore, it supports abstracting the debugging process data and sending it back to the fine-tuning system of the debugging inference model anonymously as debugging samples. This is used to continuously optimize the model's ability to identify and reason about similar anomalies, forming a "self-learning loop of debugging experience".

[0075] This embodiment can achieve the following beneficial effects: (1) During the debugging of the target code, a first probe is injected into a specific method to be monitored, and the running data of the method to be monitored is collected based on the first probe. Whenever a debugging condition is triggered, the debugging inference model can perform anomaly analysis on the current data to be analyzed based on the running data of the method to be monitored, and generate a problem hypothesis chain. When the problem hypothesis chain is not verified, it is recursively backtracked to at least one upstream method, and the running data of the upstream method is collected based on the second probe. The running data of the upstream method is added to the current data to be analyzed, so that the debugging inference model can realize multi-round anomaly inference. Until the problem hypothesis chain is verified, the corresponding anomaly analysis results are generated. Based on this, the analysis scope is dynamically expanded at runtime, realizing bottom-up "on-demand backtracking" debugging, improving the efficiency of problem location and the accuracy of debugging.

[0076] (2) In order to achieve data collection in a low-intrusive manner, a lightweight probe is used to execute the collection logic in a distributed manner when the method enters and exits, and asynchronously record the call stack information when the method is executed. This can achieve method-level input / output and context tracking without blocking the business thread, without the need for manual breakpoints.

[0077] (3) The debugging inference model can control the debugging behavior of the target code at runtime through a preset instruction interface to verify the generated problem hypothesis chain, so that the debugging inference model can actively control the runtime debugging behavior, rather than just passively receiving logs.

[0078] Based on the same inventive concept, embodiments of the present invention provide a code debugging apparatus for implementing the above-described code debugging method. For example... Figure 11 As shown, a code debugging device 1100 includes: a probe acquisition unit 1101 and an anomaly analysis unit 1102.

[0079] The probe acquisition unit 1101 is used to inject a first probe into the method to be monitored in the target code when debugging the target code, and to collect the running data of the method to be monitored based on the first probe. Anomaly analysis unit 1102 is used to construct current analysis data based on the running data of the monitored method whenever the debugging conditions of the monitored method are triggered, and to take the monitored method as the current method, and perform the following anomaly reasoning process: perform anomaly analysis on the current analysis data through a debugging reasoning model to generate a problem hypothesis chain, the problem hypothesis chain including the upstream method that calls the current method; determine whether the problem hypothesis chain has been verified; if not, then in the probe acquisition unit 1101, collect the running data of the upstream method based on the second probe, add the running data of the upstream method to the current analysis data, take the upstream method as the current method, and return the anomaly reasoning process; if yes, then end the anomaly reasoning process and generate the anomaly analysis result of the monitored method.

[0080] Optionally, the probe acquisition unit 1101 is used for: Based on the execution data of the current method, obtain the call stack information of the current method; Based on the call stack information, the upstream method is determined; Detect whether the upstream method injects a probe; If not, a second probe is injected into the upstream method, and the operation data of the upstream method is collected based on the second probe; If so, the second probe, which has been injected into the upstream method, is activated, and the running data of the upstream method is collected based on the second probe.

[0081] Optionally, the probe acquisition unit 1101 is used for: Whenever the target code runs to a target method that has been injected with the target probe, the input parameters of the target method are captured; During the execution of the target method, the call stack information of the target method in the current thread is recorded asynchronously; When the target method exits, capture the return value and execution status of the target method; The input parameters, call stack information, return value, and execution status of the target method are encapsulated into the runtime data of the target method.

[0082] Optionally, the anomaly analysis unit 1102 is configured to: acquire estimated anomaly metadata and multiple cached historical running sample data; and construct current data to be analyzed based on the running data of the method to be monitored, the estimated anomaly metadata, and the multiple historical running sample data. The anomaly analysis unit 1102 is configured to: parse the reference relationship between the monitored method and at least one upstream method based on the call stack information in the runtime data of the monitored method and at least one upstream method; parse the variable change trend of each variable in the monitored method and at least one upstream method based on multiple historical runtime sampling data; detect existing anomaly patterns based on the estimated anomaly metadata; and generate a problem hypothesis chain based on the reference relationship, the variable change trend, and the anomaly pattern. The anomaly analysis unit 1102 is configured to: construct a function call tree and anomaly path based on the reference relationship and the verified problem hypothesis chain; construct a variable change timeline based on the variable change trend; determine the root cause of the problem based on the verified problem hypothesis chain and generate corresponding modification suggestions; and encapsulate the anomaly analysis results based on the function call tree, the anomaly path, the variable change timeline, the root cause of the problem, and the corresponding modification suggestions.

[0083] Optionally, the device further includes a sampling unit, the sampling unit being used for: After collecting the running data of the method to be monitored based on the first probe, the running data of the method to be monitored is cached based on the current sampling rate of the method to be monitored. The current sampling rate of the method to be monitored is determined through the following process: Monitor the call frequency of the method to be monitored; Determine the target frequency range to which the call frequency of the method to be monitored belongs, and set the base sampling rate corresponding to the target frequency range to the method to be monitored. The target frequency range includes a first frequency range or a second frequency range. If the minimum value of the first frequency range is greater than the maximum value of the second frequency range, then the base sampling rate corresponding to the first frequency range is lower than the base sampling rate corresponding to the second frequency range. If an anomaly in system performance is detected, the current sampling rate of the method to be monitored is increased; Until the system performance returns to normal, the current sampling rate of the method to be monitored is restored to the base sampling rate.

[0084] Optionally, the debugging inference model controls the debugging behavior of the target code during runtime through a preset instruction interface to verify the problem hypothesis chain; The preset instruction interface includes any one or more of the following: The call stack instruction interface is used to retrieve the call stack information of a specified method. The upstream method instruction interface is used to request sampling of the upstream method in order to obtain the execution data of the upstream method; The `Get Object Fields` command interface is used to retrieve the status information of a specified object field. The sampling rate setting command interface is used to adjust the current sampling rate of a specified method.

[0085] Optionally, the device further includes a learning unit, the learning unit being used for: Determine the actual root cause corresponding to the debugging conditions that trigger the monitored method; Determine the difference between the actual root cause and the problem root cause recorded in the anomaly analysis results; Based on the aforementioned differences, the threshold for the target frequency range and the base sampling rate are optimized. Based on the aforementioned differences, the sampling priority and the prompt words input into the debugging inference model for each of the methods to be monitored are adjusted. A debugging sample is constructed based on the target code and the anomaly analysis results, and the debugging inference model is adjusted based on the debugging sample.

[0086] This embodiment can achieve the following beneficial effects: (1) During the debugging of the target code, a first probe is injected into a specific method to be monitored, and the running data of the method to be monitored is collected based on the first probe. Whenever a debugging condition is triggered, the debugging inference model can perform anomaly analysis on the current data to be analyzed based on the running data of the method to be monitored, and generate a problem hypothesis chain. When the problem hypothesis chain is not verified, it is recursively backtracked to at least one upstream method, and the running data of the upstream method is collected based on the second probe. The running data of the upstream method is added to the current data to be analyzed, so that the debugging inference model can realize multi-round anomaly inference. Until the problem hypothesis chain is verified, the corresponding anomaly analysis results are generated. Based on this, the analysis scope is dynamically expanded at runtime, realizing bottom-up "on-demand backtracking" debugging, improving the efficiency of problem location and the accuracy of debugging.

[0087] (2) In order to achieve data collection in a low-intrusive manner, a lightweight probe is used to execute the collection logic in a distributed manner when the method enters and exits, and asynchronously record the call stack information when the method is executed. This can achieve method-level input / output and context tracking without blocking the business thread, without the need for manual breakpoints.

[0088] (3) The debugging inference model can control the debugging behavior of the target code at runtime through a preset instruction interface to verify the generated problem hypothesis chain, so that the debugging inference model can actively control the runtime debugging behavior, rather than just passively receiving logs.

[0089] An exemplary embodiment of the present invention also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of the present invention.

[0090] An exemplary embodiment of the present invention also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of the present invention.

[0091] An exemplary embodiment of the present invention also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of the present invention.

[0092] refer to Figure 12 The present invention will now be described in the form of a structural block diagram of an electronic device 1200 that can serve as a server or client of the present invention, which is an example of a hardware device that can be applied to various aspects of the present invention. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0093] like Figure 12As shown, the electronic device 1200 includes a computing unit 1201, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1202 or a computer program loaded from a storage unit 1208 into a random access memory (RAM) 1203. The RAM 1203 may also store various programs and data required for the operation of the device 1200. The computing unit 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0094] Multiple components in electronic device 1200 are connected to I / O interface 1205, including: input unit 1206, output unit 1207, storage unit 1208, and communication unit 1209. Input unit 1206 can be any type of device capable of inputting information to electronic device 1200. Input unit 1206 can receive input digital or text information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 1207 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 1208 may include, but is not limited to, disk and optical disk. Communication unit 1209 allows electronic device 1200 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth devices, Wi-Fi devices, WiMax devices, cellular communication devices, and / or the like.

[0095] The computing unit 1201 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 1201 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1201 performs the various methods and processes described above. For example, in some embodiments, the above-described code debugging methods can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 1208. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 1200 via ROM 1202 and / or communication unit 1209. In some embodiments, the computing unit 1201 can be configured to perform the above-described code debugging methods by any other suitable means (e.g., by means of firmware).

[0096] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0097] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0098] As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0099] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0100] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0101] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A code debugging method, characterized in that, The code debugging method includes: When debugging the target code, a first probe is injected into the method to be monitored in the target code, and the running data of the method to be monitored is collected based on the first probe; Whenever the debugging conditions of the monitored method are triggered, the current data to be analyzed is constructed based on the running data of the monitored method, and the monitored method is taken as the current method. The following abnormal reasoning processing is performed: abnormal analysis is performed on the current data to be analyzed through the debugging reasoning model to generate a problem hypothesis chain, which includes the upstream method that calls the current method. Determine whether the chain of assumptions in the problem has been verified; If not, then based on the second probe, the running data of the upstream method is collected, the running data of the upstream method is added to the current data to be analyzed, the upstream method is used as the current method, and the abnormal reasoning process is returned. If so, the abnormal reasoning process ends, and the abnormal analysis result of the method to be monitored is generated.

2. The code debugging method according to claim 1, characterized in that, The acquisition of operational data from the upstream method based on the second probe includes: Based on the execution data of the current method, obtain the call stack information of the current method; Based on the call stack information, the upstream method is determined; Detect whether the upstream method injects a probe; If not, a second probe is injected into the upstream method, and the operation data of the upstream method is collected based on the second probe; If so, the second probe, which has been injected into the upstream method, is activated, and the running data of the upstream method is collected based on the second probe.

3. The code debugging method according to any one of claims 1-2, characterized in that, The process of collecting the operational data includes: Whenever the target code runs to a target method that has been injected with the target probe, the input parameters of the target method are captured; During the execution of the target method, the call stack information of the target method in the current thread is recorded asynchronously; When the target method exits, capture the return value and execution status of the target method; The input parameters, call stack information, return value, and execution status of the target method are encapsulated into the runtime data of the target method.

4. The code debugging method according to claim 1, characterized in that, The construction of the current data to be analyzed based on the operational data of the method to be monitored includes: Obtain the estimated anomaly metadata, as well as multiple cached historical runtime sampling data; Based on the operational data of the method to be monitored, the estimated anomaly metadata, and multiple historical operational sampling data, the current data to be analyzed is constructed. The step of performing anomaly analysis on the current data to be analyzed by debugging the inference model and generating a chain of problem hypotheses includes: Based on the call stack information in the runtime data of the method to be monitored and at least one of the upstream methods, the reference relationship between the method to be monitored and at least one of the upstream methods is resolved; Based on multiple historical operation sampling data, the variable change trends of each variable in the method to be monitored and at least one of the upstream methods are analyzed; Based on the estimated anomaly metadata, detect existing anomaly patterns; Based on the reference relationships, the variable change trends, and the anomaly patterns, a problem hypothesis chain is generated; The generation of anomaly analysis results for the method to be monitored includes: Based on the aforementioned reference relationships and the verified chain of problem hypotheses, a function call tree and anomaly path are constructed based on the method to be monitored. Based on the aforementioned variable change trends, a timeline of variable changes is constructed; Based on the verified chain of assumptions about the problem, the root cause of the problem is identified, and corresponding modification suggestions are generated. Based on the function call tree, the anomaly path, the variable change timeline, the root cause of the problem, and the corresponding modification suggestions, the anomaly analysis results are encapsulated.

5. The code debugging method according to claim 1, characterized in that, The code debugging method also includes: After collecting the running data of the method to be monitored based on the first probe, the running data of the method to be monitored is cached based on the current sampling rate of the method to be monitored. The current sampling rate of the method to be monitored is determined through the following process: Monitor the call frequency of the method to be monitored; Determine the target frequency range to which the call frequency of the method to be monitored belongs, and set the base sampling rate corresponding to the target frequency range to the method to be monitored. The target frequency range includes a first frequency range or a second frequency range. If the minimum value of the first frequency range is greater than the maximum value of the second frequency range, then the base sampling rate corresponding to the first frequency range is lower than the base sampling rate corresponding to the second frequency range. If an anomaly in system performance is detected, the current sampling rate of the method to be monitored is increased; Until the system performance returns to normal, the current sampling rate of the method to be monitored is restored to the base sampling rate.

6. The code debugging method according to claim 1, characterized in that, The debugging inference model controls the debugging behavior of the target code during runtime through a preset instruction interface in order to verify the problem hypothesis chain; The preset instruction interface includes any one or more of the following: The call stack instruction interface is used to retrieve the call stack information of a specified method. The upstream method instruction interface is used to request sampling of the upstream method in order to obtain the execution data of the upstream method; The `Get Object Fields` command interface is used to retrieve the status information of a specified object field. The sampling rate setting command interface is used to adjust the current sampling rate of a specified method.

7. The code debugging method according to claim 5, characterized in that, The code debugging method also includes: Determine the actual root cause corresponding to the debugging conditions that trigger the monitored method; Determine the difference between the actual root cause and the problem root cause recorded in the anomaly analysis results; Based on the aforementioned differences, the threshold for the target frequency range and the base sampling rate are optimized. Based on the aforementioned differences, the sampling priority and the prompt words input into the debugging inference model for each of the methods to be monitored are adjusted. A debugging sample is constructed based on the target code and the anomaly analysis results, and the debugging inference model is adjusted based on the debugging sample.

8. A code debugging device, characterized in that, The code debugging device includes: The probe acquisition unit is used to inject a first probe into the method to be monitored in the target code when debugging the target code, and to collect the running data of the method to be monitored based on the first probe. An anomaly analysis unit is used to construct current analysis data based on the runtime data of the monitored method whenever the debugging conditions of the monitored method are triggered, and to take the monitored method as the current method, and perform the following anomaly reasoning process: perform anomaly analysis on the current analysis data through a debugging reasoning model to generate a problem hypothesis chain, the problem hypothesis chain including the upstream method that calls the current method; determine whether the problem hypothesis chain has been verified; if not, then in the probe acquisition unit, collect the runtime data of the upstream method based on the second probe, add the runtime data of the upstream method to the current analysis data, take the upstream method as the current method, and return the anomaly reasoning process; if yes, then end the anomaly reasoning process and generate the anomaly analysis result of the monitored method.

9. An electronic device, comprising: processor; as well as Stored program memory, The program includes instructions that, when executed by the processor, cause the processor to perform the method according to any one of claims 1-7.

10. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-7.

Images