Memory leak processing method and related device

Abstract

The invention discloses a memory leak processing method and a related device, and relates to the technical field of data processing, semantic analysis is performed on a reference chain of memory leak to obtain leak type diagnosis information, and the leak type diagnosis information is converted into a formatted diagnosis report; the formatted diagnosis report comprises a first report used for a large language model, the large language model is called based on a cue word to output repair information, the repair information is used for repairing a target code, and the cue word is obtained based on the diagnosis report and the target code. The reference chain of the memory leak is converted into the diagnosis report beneficial to understanding of the large language model, so that the repair information can be obtained based on the large language model, the degree of dependence of repair on manpower is reduced, and the processing mode of the memory leak is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and apparatus for handling memory leaks. Background Technology

[0002] Memory leaks refer to situations where, during program execution, memory objects that should have been released by the garbage collection (GC) mechanism are accidentally linked to the GC root node by a persistent reference chain, preventing the memory space they occupy from being reclaimed. As the program runs or the number of operations increases, this invalid memory will continue to accumulate, eventually leading to problems such as excessive application memory usage, lag, and memory overflow.

[0003] Currently, some tools can detect memory leaks, but fixing memory leaks still relies on manual intervention. Therefore, there is still room for improvement in how memory leaks are handled. Summary of the Invention

[0004] In view of the above problems, this application provides a method and related apparatus for handling memory leaks, so as to improve the handling of memory leaks. The specific solution is as follows:

[0005] The first aspect of this application provides a method for handling memory leaks, including:

[0006] Obtain the reference chain of the memory leak caused by the target code;

[0007] Semantic analysis is performed on the reference chain of the memory leak to obtain diagnostic information on the leak type;

[0008] The leak type diagnostic information is converted into a formatted diagnostic report, which includes a first report for the large language model;

[0009] The prompt words are used to call the large language model to output repair information, which is used to repair the target code. The prompt words are obtained based on the diagnostic report and the target code.

[0010] In one possible implementation, after invoking the large language model to output repair information based on the prompt word, the method further includes:

[0011] If the confidence level of the large language model is greater than a first threshold, the repair branch is connected to the target code, and the repair branch is obtained based on the repair information.

[0012] In one possible implementation, after invoking the large language model to output repair information based on the prompt word, the method further includes:

[0013] A notification is sent to remind the user to review the repair branch.

[0014] In one possible implementation, the formatted diagnostic report further includes:

[0015] The second report is for human reading.

[0016] In one possible implementation, the prompt includes: leak type diagnostic information and corresponding code snippets for each suspicious object from the diagnostic report, wherein the location information of the code snippets in the target code is obtained based on the diagnostic report.

[0017] A second aspect of this application provides a memory leak handling apparatus, comprising: a module for implementing the method of the first aspect or any implementation thereof.

[0018] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the method described in the first aspect or any implementation thereof.

[0019] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0020] The memory is used to store computer programs;

[0021] The processor is used to execute the computer program to enable the electronic device to implement the method of the first aspect or any implementation thereof.

[0022] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to perform the method described in the first aspect or any implementation thereof.

[0023] By employing the above technical solutions, the memory leak processing method and related apparatus provided in this application perform semantic analysis on the reference chain of the memory leak to obtain leak type diagnostic information, and convert the leak type diagnostic information into a formatted diagnostic report. The formatted diagnostic report includes a first report for a large language model, and the large language model is invoked based on prompt words to output repair information. The repair information is used to repair the target code. The prompt words are obtained based on the diagnostic report and the target code. It can be seen that by converting the reference chain of the memory leak into a diagnostic report that is conducive to the understanding of the large language model, repair information can be obtained based on the large language model, reducing the dependence on manual repair and improving the memory leak processing method. Attached Figure Description

[0024] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0025] Figure 1 A flowchart illustrating a memory leak handling method provided in this application;

[0026] Figure 2 A flowchart for obtaining a reference chain caused by a memory leak in the target code, provided in this application;

[0027] Figure 3 A schematic diagram of the structure of a memory leak handling device provided in this application;

[0028] Figure 4 A structural example diagram of an electronic device provided in this application. Detailed Implementation

[0029] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0030] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0031] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0032] The inventors' research revealed that relying on manual methods to fix memory leaks can lead to the following problems:

[0033] 1. Disconnect between detection and remediation: The tool is only responsible for detecting leaks and does not provide remediation solutions, which requires developers to spend extra time analyzing the causes and writing remediation code, resulting in low processing efficiency.

[0034] 2. Reliance on human experience: Locating the root cause of memory leaks depends on the developer's in-depth understanding of memory management and framework mechanisms. Insufficient experience of personnel can easily lead to misjudgment or incomplete repair.

[0035] 3. Non-automated process: From locating the root cause and obtaining code patches to code submission, multiple manual steps are involved, which are prone to errors and have a long cycle, making it unfavorable for continuous integration and rapid iteration.

[0036] 4. Lack of intelligent repair capabilities: Existing AI code tools are not deeply integrated with memory leak detection scenarios and cannot generate targeted repair code based on runtime memory behavior.

[0037] Based on the above issues, it is clear that there is room for improvement in how memory leaks are handled.

[0038] In view of this, Figure 1 This application provides an embodiment of a memory leak handling method, which includes the following steps:

[0039] S11. Obtain the reference chain of the memory leak caused by the target code.

[0040] The target code is the code that causes a memory leak at runtime.

[0041] A memory leak's reference chain refers to a persistent reference path that shouldn't exist between a target object (also known as a suspicious object such as an Activity / Fragment) and a GC root node in the directed object graph of the Android heap memory. This path prevents the target object from being garbage collected, ultimately leading to a memory leak. GC roots are special objects at the virtual machine level (such as system classes, local variables in active thread stacks, global references, etc.), and they are the anchor points for object survival.

[0042] The specific implementation process of S11 will be combined with Figure 2 Please provide a detailed explanation.

[0043] In existing technologies, target code cannot be automatically repaired based on the reference chain of memory leaks, and manual repair is required. In this embodiment, the following repair process is innovatively proposed.

[0044] S12. Perform semantic analysis on the reference chain of the memory leak to obtain leak type diagnostic information.

[0045] Examples of leak type diagnostic information for each suspected object include:

[0046] 1. Root cause classification: Specific leak type (e.g., STATIC_FIELD_LEAK);

[0047] 2. Key Evidence Chain: A simplified reference path that best reflects the characteristics of the pattern (e.g., leaked Activity -> SomeClass.sStaticContext -> GC Root). In this embodiment, multiple reference chains are scored for importance, and the key evidence chain that best reflects the leakage characteristics is output first, rather than simply listing all paths.

[0048] 3. Key Holder: The object or field in this path that is primarily responsible for the leak (such as SomeClass.sStaticContext in the example above).

[0049] Specifically, based on a pre-configured reference chain feature matching pattern library, the reference chains of memory leaks are converted into leak types. For example, the reference chain feature matching pattern library records the correspondence between first and second information. The first information includes key nodes and reference relationships, and the second information includes the leak type. For each reference chain, the key nodes and reference relationships are identified. For example, the key nodes and reference relationships to be identified include at least one of the following:

[0050] Static field chain: An object is directly or indirectly referenced by a static field of a class;

[0051] Singleton object chain: An object is held by a single global singleton instance;

[0052] Long-lifecycle component chain: such as an application context or a background service referencing an Activity (an Activity can be understood as a core page component);

[0053] Collection class holding chain: The object is placed in a global or long-lived collection such as a hash map (HashMap) or an array list (ArrayList) and is not removed;

[0054] Thread / message handler (Handler) association chain: The object is implicitly held by an asynchronous task (AsyncTask), a non-static inner class, a Handler, or a message, while the lifecycle of the associated thread or message queue is too long.

[0055] Based on the knowledge base, the identified key nodes and reference relationships are mapped to the leakage type.

[0056] Understandably, the diagnostic information obtained by semantic analysis of the reference chain, such as the key evidence chains and key holders of each suspicious object divided by the leakage type, is beneficial to the understanding of the large language model based on semantic analysis, and can lay the foundation for the large language model to use this information to obtain repair information in the future.

[0057] For example, after obtaining the leak type, the confidence level of the leak type is evaluated based on multiple dimensions, including: reference chain clarity (the ease of understanding and accuracy of presenting, parsing, and describing the reference path from the suspected object to the GC Root in memory leak analysis), pattern matching strength (the probability and credibility of the current reference chain matching a certain known leak pattern), retained size growth rate (the ratio of the increase in the total retained size of a certain type of object to the total retained size of that type of object at the beginning of the scenario, used to quantify the growth rate of object retained memory), and instance number change (the difference between the number of instances of a certain type of object at the end of the scenario and the number at the beginning of the scenario within a specified test scenario period (e.g., from "before entering the details page" to "after exiting the details page"), used to reflect the addition, reclamation, or retention of instances of that type of object). This confidence level can be included in the leak type diagnostic information for subsequent operational reference.

[0058] For example, the knowledge base is configured with an adaptive update mechanism: each time a new leak is detected, the feature vector of the leak is automatically extracted, and the similarity is calculated with the existing patterns. If the similarity exceeds the threshold, the pattern library is automatically updated to achieve self-evolution.

[0059] S13. Convert the leak type diagnostic information into a formatted diagnostic report.

[0060] The leak type diagnostic information obtained from the above steps is essentially fragmented, natural language or semi-structured text. This text cannot be accurately parsed by large language models. Therefore, it needs to be converted into a formatted diagnostic report (also known as the first report) that is suitable for large language models.

[0061] In addition to format conversion, this step can also supplement the leak type diagnostic information of any of the suspicious objects with some explanations. The purpose of adding explanations is to provide semantic context for the large language model. For example, without explanations, the large language model receives the message "STATIC_FIELD_LEAK". With explanations, the large language model receives the message and the corresponding explanation: "STATIC_FIELD_LEAK" + "The Activity instance is held by a static field, causing it to be unable to be garbage collected".

[0062] For example, the diagnostic report for this step is in JSON format. For instance, the diagnostic report includes the following:

[0063] {

[0064] "diagnosis_id": "DIAG_001", / / String, unique identifier for the diagnostic report; generated by the system and used to associate with subsequent processes;

[0065] "leaked_object": { / / Object, describing the core object instance where the leak occurred (i.e., the suspected object identified as leaking);

[0066] "class_name": "com.example.MainActivity", / / String, leaking the fully qualified class name of the object; derived from an object graph node attribute;

[0067] "object_id": "0x12a4b678" / / String, leaking the unique memory address identifier of the object in the heap; derived from an object graph node attribute;

[0068] },

[0069] "root_cause": { / / Object describing the root cause type and semantic information of the leak;

[0070] "pattern": "STATIC_FIELD_LEAK", / / String, leakage type classification code; derived by matching predefined pattern libraries based on reference chain features (such as STATIC_FIELD_LEAK, CONTEXT_LEAK, etc.).

[0071] "description": "The Activity instance is held by a static field, preventing it from being garbage collected" / / String, a natural language description of the leak type; automatically generated based on the pattern and key node information;

[0072] },

[0073] "key_holder": { / / Object that describes the key holder (object or field) in the reference chain that is primarily responsible for the leak;

[0074] "class_name": "com.example.AppManager", / / String, the class name to which the key holder belongs; from the key node;

[0075] "field_name": "sCurrentActivity", / / String, the field name in the key holder (if the holder is a field); if the holder is the object itself, this field can be null or omitted;

[0076] "field_type": "static" / / String, field type: static (static field) or instance (instance field); can be omitted if the holder is not a field;

[0077] },

[0078] "critical_chain": [ / / Array, a simplified reference path that best reflects the characteristics of this pattern, used to visually demonstrate the critical path from the leaked object to the GC Root;

[0079] "com.example.MainActivity (leaked object)", / / String, the first node in the path: the leaked object;

[0080] "com.example.AppManager.sCurrentActivity (static)", / / String, the second node in the path: key holder (static field);

[0081] "java.lang.Class (GC Root)" / / string, the last node in the path: GC Root];

[0082] "confidence": 0.95 / / Floating-point number, the confidence level of the diagnostic result (range 0.0 to 1.0); calculated based on factors such as the clarity of the reference chain and the strength of the pattern match;

[0083] }

[0084] Existing technologies lack semantic enhancement mechanisms for prompt words in large language models. This step utilizes a predefined semantic description template library to effectively convert diagnostic information into semantically understandable information for large language models. The explanatory notes are used to extract prompt words from the large language model, thus laying the foundation for subsequent prompt word acquisition. For example, explanatory notes are generated based on the semantic description template library.

[0085] From the aforementioned diagnostic information to the diagnostic report, in addition to adding explanations, the following operations are performed: 1. Field extraction: extract key fields from the diagnostic information; 2. Path pruning: simplify the reference chain; 3. Confidence calculation: obtain the confidence score using a multi-dimensional weighted scoring algorithm; 4. JSON encapsulation: convert to JSON format.

[0086] In some implementations, in addition to generating diagnostic reports for use with large models, human-readable diagnostic reports, such as those in Markdown format, are also generated for easier viewing. For example, these human-readable diagnostic reports are integrated into CI / CD comments or email notifications to present the information in a more user-friendly way, potentially accompanied by simple repair suggestions.

[0087] For example, the above diagnostic report can be generated by the model.

[0088] S14. Obtain prompt words based on the diagnostic report, and call the large language model to output repair information based on the prompt words.

[0089] The repair information is used to repair the target code; for example, the repair information includes repair suggestions and code patches.

[0090] In some implementations, the prompts for inputting a large language model include: diagnostic information on the leakage type of each suspicious object and code snippets.

[0091] For any suspicious object, its diagnostic information is extracted from the diagnostic report. For example, "leaked_object" in the diagnostic report represents a suspicious object, and examples of its diagnostic information include: leak type, problem description, key holder, and reference chain. "pattern" in the diagnostic report represents the leak type, "description" represents the problem description, "key_holder", "class_name", and "field_name" in the diagnostic report can be used to extract the key holder, and "critical_chain", "com.example.MainActivity (leaked object)", "com.example.AppManager.sCurrentActivity (static)", and "java.lang.Class (GC Root)" in the diagnostic report can be used to extract the reference chain.

[0092] The code snippet is a portion of the target code that corresponds to the leak type diagnostic information of the suspected object. For example, based on the class name (leaked_object.class_name) and object ID (leaked_object.object_id) of the leaked object provided in the diagnostic report, the corresponding source file path and line number information are found using a source code association engine. The source file path is obtained through the mapping relationship between the class name and the project source code, and the object allocation line number information is extracted from the object allocation call stack in the HPROF file. Then, based on the target code file path and line number, a code snippet is extracted from the target code. This code snippet includes the suspected object (leak point) and its surrounding methods, class definitions, and import statements.

[0093] For example, the prompt word is:

[0094] "You are an Android memory leak fixing expert. Please generate a fix patch based on the following leak report and code context."

[0095] Leak type: STATIC_FIELD_LEAK;

[0096] Problem description: The Activity instance is held by a static field, preventing it from being garbage collected;

[0097] Key holder: com.example.AppManager.sCurrentActivity (static);

[0098] Reference chain: com.example.MainActivity (leaked object) -> com.example.AppManager.sCurrentActivity (static) -> java.lang.Class (GC Root);

[0099] Code snippet (AppManager.java):

[0100] public class AppManager {

[0101] private static Activity sCurrentActivity;

[0102] public static void setCurrentActivity(Activity activity) {

[0103] sCurrentActivity = activity; / / Leak point

[0104] }

[0105] }

[0106] Please generate a repair suggestion and output the complete code block.

[0107] For example, based on the above prompt words, the large language model outputs the following repair suggestions and code patches:

[0108] Java

[0109] / / Recommended fix: Use Application Context or weak references

[0110] public class Utils {

[0111] private static WeakReference <context>contextRef

[0112] public static void init(Context context) {

[0113] contextRef = new WeakReference<>(context.getApplicationContext());

[0114] }

[0115] In some implementations, the large language model is pre-trained. For example, a pre-created Android memory leak repair dataset is used as labeled data to train the large language model. The Android memory leak repair dataset includes thousands of paired samples of leaked code snippets and corresponding repair codes to achieve supervised fine-tuning of the large language model.

[0116] In some implementations, after the large language model outputs a code patch, the code patch is verified. If the verification passes, subsequent steps are executed. If the verification fails, error messages can be output. For example, the code patch is first checked for compliance using static code analysis tools (such as Checkstyle or PMD). After the compliance check passes, a temporary branch is automatically created to run unit tests and regression tests to ensure that the fix does not introduce compilation errors or functional defects.

[0117] S15. Based on the correction information, correct the target code.

[0118] For example, first create a fix branch based on the code patch, such as by operating the code repository through the Git command line or GitHub REST API: 1. Create a fix branch: A fix branch can be understood as a branch outside the target code, which enables the target code to switch from the first branch that may be causing memory leaks to the fix branch.

[0119] 2. Apply the code patch to the fix branch. If the code patch is applied successfully, the fix branch will contain the code changes to fix the memory leak.

[0120] 3. Submit code changes.

[0121] For example, a pull request (PR) can be created by calling some interfaces (such as the GitHub API or the corresponding interfaces of GitLab and Bitbucket) and automatically associated with the task list in the project management system (such as JIRA).

[0122] For example, unlike existing PR creation methods, this step automatically populates the PR description with a summary of the diagnostic report, remediation instructions, test results, and model confidence levels. This information is customized specifically for this memory leak issue, providing reviewers with detailed background and credibility references, enabling them to quickly understand the remediation intent and reliability.

[0123] In some implementations, a pull request (PR) is made when the confidence level of the Large Language Model (LLM) exceeds a first threshold. A pull request merges the patch branch into the target code's main branch (such as main / master or the development branch develop). In other words, if the model's confidence level is greater than a first threshold, such as 0.9, it indicates a high degree of reliability for the code patch, and the patch branch is automatically integrated into the target code, enabling unattended target code repair. This mechanism, which dynamically decides based on the reliability of the patch, demonstrates a high level of intelligence from detection to repair and integration, going beyond simple "automated commits."

[0124] In some implementations, instead of automatically merging the fix branch, a notification is sent to inform the reviewer to review the fix branch. After the review is approved, the reviewer can merge the fix branch into the target code.

[0125] The method provided in this embodiment performs semantic analysis on the reference chain to obtain leakage type diagnostic information for each suspicious object. Then, it performs standardized format conversion on the leakage type diagnostic information of each suspicious object to obtain a diagnostic report that can be accurately parsed by a large language model. Therefore, based on the diagnostic report and the target code, it can generate prompt words suitable for the large language model to obtain the repair information output by the large language model based on the prompt words. Compared with manually locating the root cause of the problem based on the reference chain and repairing it, it has higher efficiency and accuracy. Furthermore, automatically repairing the target code based on the repair information can further improve efficiency and accuracy and facilitate unattended operation.

[0126] In summary, the method provided in this embodiment can automatically output repair information, thus achieving effective integration of detection and repair without relying on personnel to locate faults and obtain repair information. This improves the efficiency of obtaining repair code, the accuracy of code patches, and enables a fully automated repair process. Furthermore, it facilitates the deep integration of large language models with memory leak scenarios, thereby improving the relevance of repair information and enabling continuous integration and rapid iteration of automated systems.

[0127] It is understood that this embodiment does not use the reference chain as input to the large language model, but rather uses it after semantic recognition and format conversion to extract prompt words, thus improving the accuracy of the repair information output by the large model.

[0128] Figure 2 The specific process for obtaining the reference chain of the memory leak caused by the target code includes the following steps:

[0129] S21. Collect relevant data on the execution of the target code.

[0130] For example, the runtime environment configured in this embodiment is: using the continuous integration tool Jenkins or the automated workflow GitHub Actions as the continuous integration and continuous delivery (CI / CD) scheduling platform (i.e. Figure 1 and Figure 2 The process shown is executed by the Android emulator. After triggering the test task, it automatically creates and configures an Android emulator (via the Android SDK's Android Virtual Device Manager avdmanager and the Android emulator tool) or connects to an authorized physical device (via the Android Debug Bridge ADB protocol). The test device's system version, screen size, and other parameters can be dynamically set according to the project configuration.

[0131] For example, integrate the mobile application automation testing framework Appium or Google's official Android UI automation testing tool UI Automator 2.0 as the automation testing framework to execute preset UI test scripts. The scripts include target code (target code includes scenarios such as user login, page navigation, list scrolling, data loading, etc.) to simulate real user operations and trigger potential memory leak paths.

[0132] After the testing process begins, tools are used to monitor the memory status in real time and automatically export the target code's runtime data to the storage device at specified times.

[0133] S22. Preprocess the relevant data of the target code execution to obtain preprocessed data.

[0134] For example, the relevant data includes raw logs, heap dump files, and probe data, and preprocessing includes format standardization and timestamp alignment to form a structured stream of memory events.

[0135] S23. Convert the preprocessed data into an HPROF file.

[0136] For example, the Android SDK's built-in hprof-conv command-line tool (i.e., the HPROF file conversion command-line tool) is invoked to convert the preprocessed data into an HPROF file (i.e., a heap dump file) conforming to the standard Java Virtual Machine (JVM) format. This file can then be directly parsed by subsequent general-purpose analysis libraries.

[0137] S24. Based on the HPROF file, construct a directed graph of memory objects.

[0138] Each object (instance) in the HPROF file is abstracted as a node in the graph. Node attributes include: a unique object identifier (ID), the class name, and the shallow heap size. Reference relationships between objects (such as instance fields pointing to another object, array element references, and static field holding) are abstracted as directed edges connecting nodes. Edge attributes may include the referenced field name and reference type. The specific process for constructing the directed graph of in-memory objects can be found in existing technologies and will not be elaborated here.

[0139] S25. Based on the directed graph of memory objects, obtain the reference chain of the memory leak caused by the target code.

[0140] In some implementations, suspicious objects are first filtered out from the objects based on the directed graph of memory objects, and then the reference chain of memory leaks for each suspicious object is obtained.

[0141] For example, a two-level concatenated filtering strategy can be used to filter out suspicious objects from the objects:

[0142] The first level of filtering is based on class names. This involves matching each object in the directed object graph against predefined class name rules that are prone to memory leaks. If an object in the directed object graph belongs to a class name rule, that object is considered suspicious. Class name rules include: android.app.Activity (Android's core page component base class) and all its subclasses, androidx.fragment.app.Fragment (Android's page component class) and all its subclasses, and user-configured custom singleton classes and management classes (such as...). , ), is an implementation class of android.content.Context (Android context object class).

[0143] The second level of filtering is based on statistical analysis of instance count changes. This involves combining the phase markers of the test scenario (e.g., a heap snapshot taken before the "Enter Details Page" operation begins is marked as a "Previous Snapshot," and a heap snapshot taken after the "Exit Details Page" operation completes is marked as a "Post-Snapshot") to compare the number of instances of the same object type and its total retained size in the previous and post-shots. If the number of instances of a certain class does not decrease compared to the previous snapshot in the post-shot after the scenario ends, or if the total retained size increases abnormally, these objects are marked as suspicious.

[0144] For example, starting with a suspicious object, the reference edges are traversed in reverse on the directed graph of memory objects, using breadth-first search (BFS) or depth-first search (DFS) algorithms to find all paths leading to the GC Root.

[0145] Figure 3 This application provides an example structural diagram of a memory leak processing device, comprising: an acquisition module, a semantic analysis module, a conversion module, and a repair module.

[0146] The module includes an acquisition module for acquiring the reference chain of the memory leak caused by the target code; a semantic analysis module for performing semantic analysis on the reference chain of the memory leak to obtain leak type diagnostic information; a conversion module for converting the leak type diagnostic information into a formatted diagnostic report, which includes a first report for a large language model; and a repair module for calling the large language model to output repair information based on prompt words, which is used to repair the target code, and the prompt words are obtained based on the diagnostic report and the target code.

[0147] In some implementations, the repair module is further configured to: after the large language model is invoked based on the prompt word to output repair information, and if the confidence level of the large language model is greater than a first threshold, connect the repair branch to the target code, wherein the repair branch is obtained based on the repair information.

[0148] In some implementations, the repair module is further configured to: after the large language model is invoked based on the prompt word to output repair information, send a notification to remind the user to review the repair branch.

[0149] In some implementations, the specific method by which the conversion module converts the leak type diagnostic information into a formatted diagnostic report includes: adding explanatory notes to the leak type diagnostic information based on a predefined semantic description template library, wherein the explanatory notes are used to extract prompt words from the large language model.

[0150] In some implementations, the formatted diagnostic report also includes a second report for human reading.

[0151] In some implementations, the prompt includes: leak type diagnostic information and corresponding code snippets for each suspicious object from the diagnostic report, wherein the location information of the code snippets in the target code is obtained based on the diagnostic report.

[0152] The device improves memory leak handling methods, such as reducing reliance on manual intervention.

[0153] This application also provides an electronic device in its embodiments. (See reference...) Figure 4 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0154] like Figure 4 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage device 608 into a random access memory (RAM) 603. When the electronic device is powered on, the RAM 603 also stores various programs and data required for the operation of the electronic device. The processing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0155] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, memory cards, hard drives, etc.; and communication devices 609. Communication device 609 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0156] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the memory leak handling methods provided in this application.

[0157] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the memory leak handling methods provided in this application.

[0158] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0159] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the memory leak handling method described in the various embodiments of this application.

[0160] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0161] 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 may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).< / context>

Claims

1. A method for handling memory leaks, characterized in that, include: Obtain the reference chain of the memory leak caused by the target code; Semantic analysis is performed on the reference chain of the memory leak to obtain diagnostic information on the leak type; The leak type diagnostic information is converted into a formatted diagnostic report, which includes a first report for the large language model; The prompt words are used to call the large language model to output repair information, which is used to repair the target code. The prompt words are obtained based on the diagnostic report and the target code.

2. The method for handling memory leaks according to claim 1, characterized in that, After invoking the large language model to output repair information based on the prompt words, the method further includes: If the confidence level of the large language model is greater than a first threshold, the repair branch is connected to the target code, and the repair branch is obtained based on the repair information.

3. The method for handling memory leaks according to claim 2, characterized in that, After invoking the large language model to output repair information based on the prompt words, the method further includes: A notification is sent to remind the user to review the repair branch.

4. The method for handling memory leaks according to any one of claims 1-3, characterized in that, The process of converting leak type diagnostic information into a formatted diagnostic report includes: Based on a predefined semantic description template library, explanatory notes are added to the leak type diagnostic information, and these explanatory notes are used to extract prompt words from the large language model.

5. The method for handling memory leaks according to any one of claims 1-3, characterized in that, The formatted diagnostic report also includes: The second report is for human reading.

6. The method for handling memory leaks according to any one of claims 1-3, characterized in that, The prompts include: leakage type diagnostic information and corresponding code snippets for each suspicious object from the diagnostic report, wherein the location information of the code snippets in the target code is obtained based on the diagnostic report.

7. A memory leak handling apparatus, characterized in that, include: A module for implementing the memory leak handling method according to any one of claims 1 to 6.

8. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the memory leak handling method as described in any one of claims 1 to 6.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the memory leak handling method as described in any one of claims 1 to 6.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the memory leak handling method as described in any one of claims 1 to 6.

Images