Memory leak detection method and apparatus
By storing the call identifier and address in the memory allocation information and combining it with hook functions to record memory allocation and release information, the problem of high performance overhead in memory leak detection in existing technologies is solved, and efficient memory leak detection is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HONOR DEVICE CO LTD
- Filing Date
- 2022-11-07
- Publication Date
- 2026-05-29
Smart Images
Figure CN117992263B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer programs, and more particularly to a method and apparatus for detecting memory leaks. Background Technology
[0002] If a program fails to release memory properly after requesting memory allocation, it will lead to a waste of memory resources. This is especially true when the program is running for a long time, as it will cause the available memory to decrease continuously, or even cause the program to crash and restart.
[0003] Currently, a common method for detecting memory leaks is to trace the memory call stack in reverse, that is, to find the call chain of the current function layer by layer. However, this method involves performing function push-back operations during program execution, and the performance overhead of push-back operations is very large, especially in the scenario of allocating memory, this performance overhead is unacceptable. Summary of the Invention
[0004] This application provides a memory leak detection method and apparatus to reduce the performance overhead of memory leak detection.
[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:
[0006] Firstly, a memory leak detection method is provided, comprising: when a program calls a memory request function to request memory allocation, storing memory allocation information, the memory allocation information including a call identifier, the address and size of the target memory allocated by the memory request function, the call identifier indicating the location where the memory request function is called; when the program calls a memory release function to release the target memory, deleting the address and size of the target memory from the memory allocation information; determining the existence of a memory leak based on the size of the unreleased target memory corresponding to the same call identifier in the memory allocation information; and determining the location where the memory leak occurs based on the call identifier.
[0007] The memory leak detection method provided in this application stores memory allocation information when a program calls a memory request function to request memory allocation. This information includes a call identifier, the address and size of the target memory allocated by the memory request function, and the call identifier indicating the location where the memory request function is called. When the program calls a memory release function to release the target memory, the address and size of the target memory are removed from the memory allocation information. Thus, the memory allocation information stores information about the unreleased target memory and its corresponding call identifier. Based on the size of the unreleased target memory corresponding to the same call identifier in the memory allocation information, a memory leak is determined. Furthermore, the location of the memory leak is determined based on the call identifier. Since the call identifier indicates the location of the memory request function call, the location of the memory leak can be easily determined when a memory leak exists in the unreleased target memory corresponding to that call identifier. Memory leak detection does not require reverse tracing of the memory call stack, thus reducing the performance overhead of memory leak detection.
[0008] In one possible implementation, the call identifier is the entry address of the memory request function called in the program. The entry address refers to the address in the binary file obtained after the source file is compiled by the compiler.
[0009] The call identifier can be used to determine the entry address of the memory request function, which makes it easier to pinpoint the location of a memory leak.
[0010] In one possible implementation, the call identifier also includes the access path to the aforementioned binary file.
[0011] The location where the memory request function is called can be determined by calling the access path of the binary file included in the identifier.
[0012] In one possible implementation, the call identifier is generated from the storage location information of the memory request function, which includes at least one of the following: the line of code in the source file where the memory request function is located, the name of the parent function that calls the memory request function, the name of the source file where the parent function is located, and the directory where the source file is located.
[0013] In one possible implementation, the memory allocation information may also include storage location information, where the storage location information corresponding to the same call identifier is used to determine the location where a memory leak occurs.
[0014] The aforementioned storage location information and the corresponding call identifier are stored in the memory allocation information, which makes it easy to find the corresponding storage location information by using the call identifier, thereby determining the location where the memory leak occurred.
[0015] In one possible implementation, storing memory allocation information includes storing memory allocation information via a hook function of the memory request function.
[0016] By creating hook functions for existing memory request functions in the system, it is easier to implement than creating new memory request functions to call existing ones without modifying the original program code.
[0017] In one possible implementation, when the program calls the memory release function to release the target memory, the address and size of the target memory are removed from the memory allocation information, including: when the program calls the memory release function to release the target memory, the address and size of the target memory are removed from the memory allocation information through the hook function of the memory release function.
[0018] By creating hook functions for existing memory release functions in the system, compared to creating new memory release functions to call existing ones, it is easier to implement without modifying the original program code.
[0019] In one possible implementation, determining the existence of a memory leak based on the size of the unreleased target memory corresponding to the same call identifier in the memory allocation information includes: if the sum of the sizes of the unreleased target memory corresponding to the same call identifier is greater than a threshold, then determining that a memory leak exists.
[0020] Since the same call identifier indicates the location of the same memory request function, and the same call identifier corresponds to multiple sets of target memory information, it indicates that the program has executed to this location multiple times and requested memory allocation. Whether there is a memory leak can be determined by whether the sum of the sizes of the unreleased target memory corresponding to the same call identifier is greater than a threshold. This threshold can be a value determined based on statistical data.
[0021] In a second aspect, a memory leak detection device is provided, including a processor and a memory, wherein instructions are stored in the memory, and when the processor executes the instructions, the method described in the first aspect and any embodiment thereof is executed.
[0022] Thirdly, a computer-readable storage medium is provided, including instructions that, when executed on a memory leak detection device, cause the memory leak detection device to perform the method as described in the first aspect and any embodiment thereof.
[0023] Fourthly, a computer program product containing instructions is provided, which, when executed on the memory leak detection device, cause the memory leak detection device to perform the method described in the first aspect and any embodiment thereof.
[0024] Fifthly, a chip system is provided, including a processor for supporting a memory leak detection device in implementing the functions described in the first aspect above. In one possible design, the device further includes interface circuitry for receiving signals from other devices (e.g., memory) or sending signals to other devices (e.g., a communication interface). The chip system may include a chip and may also include other discrete devices.
[0025] The technical effects of the second to fifth aspects refer to the technical effects of the first aspect and any of its embodiments, and will not be repeated here. Attached Figure Description
[0026] Figure 1 This is a schematic diagram of the structure of a memory leak detection device provided in an embodiment of this application;
[0027] Figure 2 A flowchart illustrating a memory leak detection method provided in an embodiment of this application;
[0028] Figure 3 A schematic diagram illustrating a call identifier that is the entry address of a memory request function in a program, provided as an embodiment of this application;
[0029] Figure 4 A schematic diagram illustrating how a call identifier can be generated from the storage location information of a memory request function, as provided in an embodiment of this application;
[0030] Figure 5 A schematic diagram illustrating the layers involved in memory allocation from a software layering perspective, as provided in this application embodiment;
[0031] Figure 6 A schematic diagram illustrating a method for obtaining a call identifier, provided in an embodiment of this application;
[0032] Figure 7 A schematic diagram illustrating a method for determining the location of a memory leak, as provided in an embodiment of this application;
[0033] Figure 8 This is a schematic diagram of a chip system provided in an embodiment of this application. Detailed Implementation
[0034] First, some concepts involved in this application will be described.
[0035] The terms "first" and "second" used in the embodiments of this application are only used to distinguish features of the same type and should not be construed as indicating relative importance, quantity, order, etc.
[0036] The terms "exemplary" or "for example" used in the embodiments of this application are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.
[0037] The terms "coupling" and "connection" used in the embodiments of this application should be interpreted broadly. For example, they can refer to a physical direct connection or an indirect connection achieved through electronic devices, such as a connection achieved through resistors, inductors, capacitors or other electronic devices.
[0038] As mentioned earlier, if a program requests memory allocation but then fails to release that memory properly after no longer using it, the amount of unusable memory will increase, leading to memory waste. This is especially problematic during long-term program execution, as it can cause available memory to continuously decrease and even result in system crashes and restarts. A common method for detecting memory leaks is to trace the memory call stack backwards, i.e., finding the call chain of the current function layer by layer. However, this method involves performing function push-back operations during program execution, and stack push-back operations have significant performance overhead, especially in memory allocation scenarios where this overhead is unacceptable.
[0039] To address this, this application provides a memory leak detection device for executing a memory leak detection method. During program compilation, call identifiers are assigned to indicate the location of memory request functions. When a program calls a memory request function, a mapping relationship is stored between the call identifier, the address and size of the target memory allocated by the memory request function, and the same call identifier may correspond to multiple sets of target memory addresses and sizes. When a program calls a memory release function to release target memory, the address and size of the target memory are removed from the memory allocation information. The presence of a memory leak is detected based on the remaining information in the memory allocation information. If the total target memory corresponding to a certain call identifier is greater than a threshold, the call identifier is decompiled to determine the code of the memory request function that caused the memory leak. This method records memory allocation information in a forward manner and does not require function stack push operations, thus reducing the performance overhead of memory leak detection.
[0040] like Figure 1 As shown, the memory leak detection device 100 provided in this embodiment includes at least one processor 101, a communication line 102, a memory 103, and at least one communication interface 104. The communication line 102 may include a path for transmitting information between the aforementioned components. The communication interface 104 uses any transceiver-like device for communicating with other devices. For example, the memory leak detection device 100 may be a computer, server, etc.
[0041] The processor 101 involved in this application embodiment can be a chip. For example, it can be a field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), system-on-chip (SoC), central processing unit (CPU), network processor (NP), digital signal processor (DSP), microcontroller unit (MCU), programmable logic device (PLD), or other integrated chip. The processor 101 can execute the memory leak detection method provided in this application embodiment.
[0042] The memory 103 involved in this application embodiment can be volatile memory or non-volatile memory, or it can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0043] like Figure 2 As shown, the memory leak detection method provided in this application includes:
[0044] S101. When the program calls the memory request function to request memory allocation, store the memory allocation information.
[0045] Memory request functions are used to request memory allocation. For example, in the C programming language, memory request functions in the system include: malloc, calloc, realloc, etc.
[0046] The prototype of the malloc function is void* malloc(unsigned int num_bytes), which means allocating space of size num_bytes. The space allocated by the malloc function is random and is not initialized.
[0047] The prototype of the calloc function is void* calloc(size_t n, size_t size), which means allocating n spaces of size size. The calloc function initializes the allocated space to 0.
[0048] The prototype of the realloc function is void realloc(void*ptr, size_t new_Size), which means allocating space of size new_Size after the base address pointed to by the pointer ptr.
[0049] Memory allocation information includes a call identifier, the address and size of the target memory allocated by existing memory request functions in the system. Optionally, the memory allocation information may also include: During program compilation, the compiler allocates a call identifier to indicate the location where the memory request function is called. This call identifier is unique.
[0050] The following explains how to obtain the call identifier.
[0051] Method 1 for obtaining the call identifier: The call identifier can be the entry address of the memory request function in the program. Specifically, this entry address refers to the address of the memory request function in the binary file (e.g., executable file, dynamic link library .so file, etc.) obtained after the source file is compiled by the compiler. For example, ... Figure 3 As shown, the main function written in C language is compiled into a binary file by the compiler. 67d is the entry address of the memory request function malloc called in the main function, so the call identifier can be 67d.
[0052] Optionally, for subsequent memory leak analysis during decompilation, to facilitate finding the binary file containing the memory request function corresponding to the call identifier, the call identifier may also include the access path of that binary file. The access path of the binary file can be obtained at runtime based on the mapping table and the program counter (PC) value: the mapping table maps the access path of the binary file to the process space, and the PC value indicates the address of the instruction to be executed.
[0053] For example, such as Figure 6 As shown, assuming there is a binary file c_test in the / home / test / folder, the mapping table maps the access path of the binary file c_test, / home / test / c_test, to the process space 0x1001-0x1FFF, with a PC value of 0x10F1, belonging to this process space. Therefore, the new call identifier / home / test / c_test67d can be obtained by combining the original call identifier 67d and the access path of the binary file, / home / test / c_test.
[0054] Method 2 for obtaining the call identifier: The call identifier can be generated from the storage location information of the memory request function. The storage location information of the memory request function includes at least one of the following: the line of code in the source file where the memory request function is located, the name of the parent function that calls the memory request function, the name of the source file where the parent function is located, and the directory where that source file is located. For example, such as... Figure 4 As shown, assuming the code line of the source file containing the memory request function is 60, the name of the parent function that calls the memory request function is retrive_dsp_capability, the name of the source file containing the parent function that calls the memory request function is multithreading.c, and the directory of the source file is workspace / app / src / native / , the call identifier 22cabca0e282ff12030d9153aa17e7da is obtained by using a hash algorithm on at least one of the above information.
[0055] Optionally, the memory allocation information may also include the storage location information of the memory request function corresponding to the call identifier, such as workspace / app / src / native / multithreading.c,retrieve_dsp_capability,60. That is, the storage location information of the corresponding memory request function can be found through the call identifier.
[0056] The following explains how to extend memory request functions to store memory allocation information.
[0057] Extended memory request function method 1: Users can create new memory request functions to call existing memory request functions in the system. When compiling the program, the compiler inputs the call identifier as an additional parameter into the new memory request function. When the program runs, if the program calls the new memory request function, the new memory request function calls the existing memory request function in the system to allocate memory (at this time, the address and size of the target memory to be allocated can be obtained), and stores the memory allocation information.
[0058] For example, suppose the original parent function `int main(void)` calls the existing memory request function `void* malloc(unsigned int num_bytes)` to request memory allocation. Now, it's modified so that the parent function `int main(void)` calls a new memory request function `void* malloc(unsigned int num_bytes, long id)`, where `id` represents the call identifier. This new memory request function then calls the existing memory request function `void* malloc(unsigned int num_bytes)` to request memory allocation and stores the memory allocation information. Figure 5 As shown, this illustrates the layers involved in memory allocation from a software layering perspective. Assume the compiler compiles the parent function `int main(void)` into the main program, `void* malloc(unsigned int num_bytes)` into `libc.so` (the operating system's memory allocation implementation library), and `void* malloc(unsigned int num_bytes, long id)` into `libleak.so`, with the kernel handling the actual physical memory allocation and management. This implementation is equivalent to modifying the main program's call to `libc.so` (which in turn calls the kernel) to a call to `libleak.so`, which in turn calls `libc.so` (which then calls the kernel).
[0059] Extended memory request function method 2: Users can create hook functions for existing memory request functions in the system. When compiling the program, the compiler inputs the call identifier as a parameter into the hook function. When the program runs, if the program calls an existing memory request function in the system, the hook function will intercept it, call the existing memory request function in the system to allocate memory, and store the memory allocation information.
[0060] For example, as shown in Table 1, memory allocation information can be stored in the form of a mapping table, where a call identifier can map multiple sets of target memory addresses and sizes.
[0061] Table 1
[0062] Call identifier target memory address target memory size Call identifier 1 0x71fc4f1000 2M Call identifier 1 0x71fc531000 4M Call identifier 1 0x720c4ec000 5M Call identifier 1 0x720c52c000 12M Call identifier 2 0x721c4ef000 400M Call identifier 2 0x721c52f000 300M Call identifier 2 0x722c4ec000 200M
[0063] It should be noted that creating hook functions for existing memory request functions in the system is easier to implement than creating new memory request functions to call existing ones without modifying the original program code.
[0064] It should also be noted that either Extended Memory Request Function Method 1 or Extended Memory Request Function Method 2 in step S101 can be combined with either Obtain Call Identifier Method 1 or Obtain Call Identifier Method 2.
[0065] S102. When the program calls the memory release function to release the target memory, the address and size of the target memory are removed from the memory allocation information.
[0066] Memory release functions are used to request the release of memory. For example, in the C language, the memory request functions in the system include the `free` function. The prototype of the `free` function is `void free(void*)`, where `void*` represents a pointer to the address of the memory to be released.
[0067] Similar to the memory request functions mentioned earlier, it is also necessary to extend the existing memory release functions in the system.
[0068] Extended memory release function method 1: Users can create new memory release functions that call existing memory release functions in the system. The new memory release function has the same input parameter as the existing memory release function, which is void*, representing a pointer to the address of the target memory to be released. The difference is that the new memory release function not only calls the existing memory release function in the system to release the target memory, but also removes the address and size of the target memory from the memory allocation information.
[0069] Extended memory release function method 2: Users can create hook functions for existing memory release functions in the system. When the program runs, if the program calls an existing memory release function in the system, the hook function will intercept it, call the existing memory release function in the system to release the target memory, and delete the address and size of the target memory from the memory allocation information.
[0070] For example, as shown in Table 2, assuming the memory release function releases the target memory at address 0x71fc4f1000 in Table 1, the address and size of the target memory can be removed from the memory allocation information.
[0071] Table 2
[0072]
[0073] It should be noted that creating a hook function for an existing memory release function in the system is easier to implement than creating a new memory release function to call an existing one, as it does not require modification to the original program code.
[0074] It should also be noted that either Extended memory release function mode 1 or Extended memory release function mode 2 in step S102 can be combined with either Extended memory request function mode 1 or Extended memory request function mode 2 in step S101.
[0075] S103. After the program exits, determine whether there is a memory leak based on the size of the unreleased target memory corresponding to the same call identifier in the memory allocation information.
[0076] When the program exits, the memory allocation information retains information about all unreleased target memory (address and size) and their corresponding call identifiers. Since the same call identifier represents the location of the same memory request function, and the same call identifier corresponds to multiple sets of target memory information, it indicates that the program has repeatedly executed to that location and requested memory allocation. Whether a memory leak exists can be determined by whether the sum of the sizes of the unreleased target memory corresponding to the same call identifier exceeds a threshold, which can be a value determined based on statistical data. If the sum of the sizes exceeds the threshold, a memory leak is determined to exist; otherwise, no memory leak is determined to exist. For example, in Table 2, the sum of the target memory sizes corresponding to call identifier 2 reaches (400+300+200)M = 900M, which exceeds the threshold (100M), therefore a memory leak can be determined.
[0077] S104. Determine the location where the memory leak occurred based on the call identifier.
[0078] Method 1 for determining the location of a memory leak: As mentioned in Method 1 for obtaining the call identifier in step S101, the call identifier can also include the access path of a binary file. Therefore, the program can be decompiled based on the call identifier to determine the location of the memory leak. The binary file in the call identifier can be decompiled based on the program's debug information (e.g., a dwarf file generated by the compiler during program compilation) to determine the location of the memory leak. For example, as... Figure 7 As shown, using the addr2line tool, the function and variables corresponding to the call identifier can be found based on the .debug_info information in the debug information, and the line of code corresponding to the call identifier can be found based on the .debug_line information. A specific example is as follows:
[0079] Run the command: aarch64-linux-android-addr2line-fCpie / home / test / c_test 67d.
[0080] The result is: main at / home / test / test.cpp:133.
[0081] Here, `aarch64-linux-android-addr2line` indicates that the `addr2line` tool should be run; `-fCpie` specifies the input parameters for the `addr2line` tool; ` / home / test / c_test` specifies the access path to the binary file; `67d` specifies the entry address of the memory request function; `main` specifies the name of the parent function that calls the memory request function; `test.cpp` specifies the name of the source file containing the parent function that calls the memory request function; and `133` specifies the line number of the source file containing the memory request function.
[0082] Method 2 for determining the location of a memory leak: As mentioned in Method 2 for obtaining the call identifier in step S101, the memory allocation information may also include the storage location information of the memory request function corresponding to the call identifier. Therefore, by using the same call identifier where the memory leak occurred, the storage location information of the corresponding memory request function can be found, thereby quickly determining the location of the memory leak.
[0083] The memory leak detection method and apparatus provided in this application, when a program calls a memory request function to request memory allocation, stores memory allocation information, including a call identifier, the address and size of the target memory allocated by the memory request function, and the call identifier indicating the location where the memory request function is called; when the program calls a memory release function to release the target memory, the address and size of the target memory are deleted from the memory allocation information. Thus, the memory allocation information stores information about the unreleased target memory and the corresponding call identifier. Based on the size of the unreleased target memory corresponding to the same call identifier in the memory allocation information, a memory leak is determined; furthermore, the location of the memory leak is determined. Since the call identifier indicates the location of the memory request function call, when a memory leak exists in the unreleased target memory corresponding to that call identifier, the location of the memory leak can be easily determined. It is not necessary to detect memory leaks by tracing the memory call stack in reverse, thus reducing the performance overhead of memory leak detection.
[0084] like Figure 8 As shown, this application embodiment also provides a chip system. The chip system 80 includes at least one processor 801 and at least one interface circuit 802. The at least one processor 801 and at least one interface circuit 802 are interconnected via lines. The processor 801 is used to support the memory leak detection device in implementing the various steps in the above method embodiments, for example... Figure 2 The method shown allows at least one interface circuit 802 to be used to receive signals from other devices (e.g., memory) or to send signals to other devices (e.g., a communication interface). The chip system may include a chip and may also include other discrete components.
[0085] This application also provides a computer-readable storage medium including instructions that, when executed on the memory leak detection device, cause the memory leak detection device to perform the steps in the method embodiments described above, such as executing... Figure 2 The method shown.
[0086] This application also provides a computer program product including instructions that, when executed on the memory leak detection device described above, cause the memory leak detection device to perform the various steps in the method embodiment described above, such as executing... Figure 2 The method shown.
[0087] The technical effects of the chip system, computer-readable storage medium, and computer program product are described in the preceding method embodiments.
[0088] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0089] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0090] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.
[0091] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or modules may be electrical, mechanical, or other forms.
[0092] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located on one device or distributed across multiple devices. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0093] In addition, the functional modules in the various embodiments of this application can be integrated into one device, or each module can exist physically separately, or two or more modules can be integrated into one device.
[0094] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another 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 can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs), etc.
[0095] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A method for detecting memory leaks, characterized in that, include: When a program calls a memory request function to request memory allocation, it stores memory allocation information, including a call identifier, the address and size of the target memory allocated by the memory request function, and the call identifier indicating the location of the memory request function call without performing a function pushback operation. The call identifier includes the address of the memory request function in the binary file obtained after the source file is compiled by the compiler, and the access path of the binary file. During program execution, the access path of the binary file is obtained by a mapping table and a program counter. The mapping table is used to map the access path of the binary file to the process space, and the program counter is used to indicate the address of the instruction to be executed, the address of which belongs to the process space. Alternatively, the call identifier is generated from the storage location information of the memory request function, which includes at least one of the following: the line of code of the source file where the memory request function is located, the name of the parent function that calls the memory request function, the name of the source file where the parent function is located, and the directory where the source file is located. When the program calls the memory release function to release the target memory, the address and size of the target memory are removed from the memory allocation information; Based on the size of the unreleased target memory corresponding to the same call identifier in the memory allocation information, a memory leak is determined to exist; By decompiling the binary file, the location of the memory leak can be determined based on the call identifier.
2. The method according to claim 1, characterized in that, The memory allocation information also includes the storage location information, and the storage location information corresponding to the same call identifier is used to determine the location where a memory leak occurs.
3. The method according to claim 1 or 2, characterized in that, The storage memory allocation information includes: The memory allocation information is stored through the hook function of the memory request function.
4. The method according to claim 1 or 2, characterized in that, When the program calls the memory release function to release the target memory, deleting the address and size of the target memory from the memory allocation information includes: When the program calls the memory release function to release the target memory, the address and size of the target memory are removed from the memory allocation information through the hook function of the memory release function.
5. The method according to claim 1 or 2, characterized in that, The step of determining the existence of a memory leak based on the size of the unreleased target memory corresponding to the same call identifier in the memory allocation information includes: If the sum of the sizes of unreleased target memory corresponding to the same call identifier is greater than a threshold, then a memory leak is identified.
6. A memory leak detection device, characterized in that, It includes a processor and a memory, wherein instructions are stored in the memory, and when the processor executes the instructions, the method described in any one of claims 1-5 is performed.
7. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a memory leak detection device, cause the memory leak detection device to perform the method as described in any one of claims 1-5.