Resource leakage point positioning method, electronic equipment and storage medium

Abstract

The invention provides a resource leakage point positioning method, electronic equipment and a storage medium, and relates to the technical field of terminals. In the method, in a service process, when a service thread calls a resource application interface to apply for resources, corresponding resource calling information is obtained, and the resource calling information comprises function stack memory information and register information corresponding to the resource application interface; the business process comprises one or more business threads; according to the technical scheme, the target thread is newly added in the business process, the stack return is carried out on the nat ive layer based on the function stack memory information and the register information, and the backtracking from the nat ive layer to the java layer is not needed during the stack return, so that the performance overhead and the resource consumption caused by the stack return are reduced, and the technical effect of improving the positioning efficiency of the resource leakage point is realized.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of terminal technology, and in particular to a method for locating a resource leakage point, an electronic device, and a storage medium. Background Art

[0002] When running a program, an electronic device dynamically allocates resources such as memory, file handles, and threads to the program for use. If these allocated resources are not released after use, it results in resource waste, a phenomenon known as resource leakage.

[0003] Resource leakage is a common problem in software development. It can affect the stable operation of programs on electronic devices. Especially when programs run for extended periods, the device's resources are continuously consumed, leading to serious consequences such as slowdowns or even system crashes. Because resource leaks are often located randomly and intermingled with normal resource requests, capturing information about them is difficult.

[0004] Therefore, how to effectively locate the location where the resource is leaked, that is, the resource leakage point, is an issue that needs to be considered. Summary of the Invention

[0005] The embodiments of the present application provide a method for locating a resource leakage point, an electronic device, and a storage medium, which can improve the efficiency of locating the resource leakage point.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, a method for locating a resource leakage point is provided, the method comprising:

[0008] In a business process, when a business thread calls a resource application interface to apply for resources, it obtains corresponding resource call information through the resource application interface. The resource call information includes the function stack memory information and register information corresponding to the resource application interface. A business process includes one or more business threads.

[0009] A target thread is started within the business process. This target thread is distinct from the business thread. Through the target thread, resource call information corresponding to the business process is unwinded to generate a call stack result. This call stack result reflects the resource call relationships within the business thread. Resource leaks are identified based on this call stack result.

[0010] In this way, by intercepting the corresponding function stack memory information and register information when the resource request interface is called, a new target thread is added inside the business process, and the stack is returned at the native layer based on the function stack memory information and register information. When returning to the stack, there is no need to trace back from the native layer to the Java layer, thereby reducing the performance overhead and resource consumption brought by the stack return, and achieving the technical effect of improving the efficiency of locating resource leakage points.

[0011] In another possible implementation of the first aspect, the electronic device includes a native layer. In the native layer, when a service thread calls a resource request interface to request a resource, the service thread obtains corresponding resource call information. The resource call information includes function stack memory information and register information corresponding to the resource request interface. The service process includes one or more service threads.

[0012] A target thread is started within the business process. This target thread is distinct from the business thread. At the native layer, resource call information corresponding to the business process is processed back to the call stack, resulting in a call stack result. This call stack result is used to reflect the resource call relationship of the business thread.

[0013] Determine resource leak points based on call stack results.

[0014] In this way, since the resource application interface is located in the native layer of the electronic device, the resource application interface is proxied at the native layer, and the corresponding function stack memory information and register information are intercepted when the resource application interface is called, and the stack is directly returned at the native layer based on the function stack memory information and register information. There is no need to trace back from the native layer to the Java layer when returning to the stack, thereby reducing the performance overhead and resource consumption brought by the stack return, and achieving the technical effect of improving the efficiency of locating resource leakage points.

[0015] In another possible implementation of the first aspect, when a service thread calls a resource application interface to apply for a resource, obtaining corresponding resource call information includes:

[0016] When a business thread calls the resource application interface to apply for a resource, it obtains the resource type, resource call information corresponding to the resource, and the correspondence between the resource type and resource call information.

[0017] In this way, after obtaining the correspondence between resource types and resource call information, different types of resource call information can be stored in different caches. Since resources of different resource types have different access modes, storing resource call information separately by resource type can further improve the access speed of resource call information.

[0018] In another possible implementation of the first aspect, when a business thread calls a resource application interface to apply for a resource, the resource type of the resource is obtained, including: based on a hook function hook proxy operating system's resource application interface, when the business thread calls the resource application interface to apply for a resource, the resource type of the resource is obtained.

[0019] Obtaining resource call information corresponding to the resource, and the corresponding relationship between the resource type and the resource call information, including: obtaining the resource call information corresponding to the resource, and the corresponding relationship between the resource type and the resource call information based on a hook function hook.

[0020] In this way, the resource application interface can be proxied through the hook function. When the resource application interface is called, the resource type and resource call information of the resource can be obtained to intercept the resource call information.

[0021] In another possible implementation of the first aspect, the method further includes:

[0022] A corresponding client is created based on the resource type, wherein different resource types correspond to different clients. Based on the correspondence between the resource type and the resource call information, the resource call information is stored in the cache of the client of the corresponding resource type.

[0023] Through the target thread, resource call information of different resource types is obtained from the cache of each client according to the corresponding relationship; the resource call information of different resource types is used to locate the resource leakage point of the corresponding resource type.

[0024] In this way, since resources of different resource types correspond to different access modes, storing resource call information separately according to resource types can further improve the access speed of resource call information.

[0025] In another possible implementation of the first aspect, the method further includes:

[0026] Create a signal processing function; wherein the signal processing function is used to create a corresponding client based on the resource type; create a system proxy based on the signal processing function; wherein the system proxy is used to hook the proxy resource application interface based on the hook function to obtain the resource call information corresponding to the resource and the correspondence between the resource type and the resource call information.

[0027] In this way, through the signal processing function and system proxy, the resource call information of the resource application interface can be intercepted, and the resource call information can be returned to the stack through the target thread to obtain the call stack result, and then the resource leakage point can be located, which helps to realize the call stack backtracking at the native layer and improve the efficiency of locating the resource leakage point.

[0028] In another possible implementation of the first aspect, stack processing is performed on resource call information corresponding to the business process through the target thread to obtain a call stack result, including:

[0029] When the preset conditions are met, the resource call information corresponding to the business process is processed through the target thread to obtain a call stack result; the preset conditions include: the capacity of the cache occupied by the resource call information is greater than a first preset threshold, a first instruction indicating a stack return is received, a preset time point for stack return is reached, or the time interval from the last stack return is greater than a second preset threshold.

[0030] In this way, the target thread can retrieve the resource call information by backtracking the call stack, and then locate the resource leak point. This helps to implement call stack backtracing at the native layer and improve the efficiency of locating resource leak points.

[0031] In another possible implementation of the first aspect, stack processing is performed on resource call information corresponding to the business process through the target thread to obtain a call stack result, including:

[0032] The target thread reads the unwind table in the program binary based on the resource call information corresponding to the business process. The unwind table is used to perform stack unwinding to obtain the call stack result.

[0033] In this way, stack backing is performed at the native layer by unwinding the table to obtain the call stack result, without having to perform stack backing across execution layers. This helps improve stack backing efficiency and, in turn, helps improve the efficiency of locating resource leak points.

[0034] In another possible implementation of the first aspect, after obtaining the call stack result, the method further includes:

[0035] The call stack results indicating the same resource call relationship are deduplicated and saved, and the number of the same call stack results is recorded.

[0036] In this way, call stack information indicating the same resource call relationship is deduplicated and then saved, and the same call stack results can be aggregated together, which helps to save memory space and reduce unnecessary resource waste.

[0037] In another possible implementation of the first aspect, deduplicating call stack results indicating identical resource call relationships and saving them, and recording the number of identical call stack results, includes:

[0038] Perform hash calculation on the call stack results, remove duplicate call stack results with the same hash value and save them, and record the number of call stack results with the same hash value.

[0039] Thus, call stack information can be very large and complex, while hash values ​​are relatively short. Converting call stack information into hash values ​​can significantly reduce storage space requirements and facilitate quick comparison of call stack information for similarity. Call stack information with the same hash value is deduplicated and stored, saving memory space and reducing unnecessary resource waste.

[0040] In another possible implementation of the first aspect, after obtaining the call stack result, the method further includes:

[0041] Stop hooking proxy resource request interfaces based on hook functions. Store call stack results in the corresponding client.

[0042] In this way, after the stack capture is completed, the resource request interface based on the hook function proxy can be stopped and the call stack results can be stored to the client, so that potential resource leak points can be diagnosed more accurately based on the call stack results.

[0043] In another possible implementation of the first aspect, determining a resource leak point based on a call stack result includes:

[0044] Determine the number of resource applications and resource occupancy corresponding to the call stack result, and select call stack results whose corresponding number of resource applications is greater than a third preset threshold or whose resource occupancy is greater than a fourth preset threshold.

[0045] Determine the resource leak point based on the filtered call stack results.

[0046] In this way, the call stack results with a higher probability of resource leakage are screened out through the number of resource applications and resource occupancy size corresponding to the call stack results. The functions or code segments that may cause resource leakage are found according to the call stack results, and the resource leakage points where resource leakage occurs are determined, thereby improving the accuracy and efficiency of locating resource leakage points.

[0047] In a second aspect, an embodiment of the present application further provides a stack back processing method, the method comprising:

[0048] In a business process, when a business thread calls a resource application interface to apply for resources, it obtains corresponding resource call information, which includes function stack memory information and register information corresponding to the resource application interface; a business process includes one or more business threads.

[0049] A target thread is started within the business process. The target thread is different from the business thread. The target thread performs stack processing on the resource call information corresponding to the business process to obtain a call stack result. The call stack result is used to reflect the resource call relationship of the business thread.

[0050] In this way, by intercepting the corresponding function stack memory information and register information when the resource request interface is called, a new target thread is added inside the business process, and the stack is returned at the native layer based on the function stack memory information and register information. When returning to the stack, there is no need to trace back from the native layer to the Java layer, thereby achieving the technical effect of reducing the performance overhead and resource consumption caused by returning to the stack.

[0051] In a third aspect, an electronic device is provided, which includes at least a memory and one or more processors; the memory is used to store computer instructions, and when the one or more processors execute the computer instructions, the electronic device executes the method as described in any one of the first aspects above.

[0052] In a fourth aspect, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions or programs, and when the computer instructions or programs are run on a computer, the method of any one of the above-mentioned first aspects is executed.

[0053] In a fifth aspect, a computer program product is provided, which includes computer instructions; when part or all of the computer instructions are run on a computer, the method of any one of the above-mentioned first aspects is executed. BRIEF DESCRIPTION OF THE DRAWINGS

[0054] Figure 1 A schematic diagram of the call stack structure provided in an embodiment of the present application;

[0055] Figure 2 A hardware structure diagram of an electronic device provided in an embodiment of the present application;

[0056] Figure 3 A software structure diagram of an electronic device provided in an embodiment of the present application;

[0057] Figure 4 Schematic diagram of the method for locating resource leakage points provided in this embodiment of the application Figure 1 ;

[0058] Figure 5 A schematic diagram of resource call information storage provided in an embodiment of the present application;

[0059] Figure 6 Schematic diagram of the method for locating resource leakage points provided in this embodiment of the application Figure 2 . DETAILED DESCRIPTION

[0060] In the description of the embodiments of the present application, the terms "comprises", "comprising" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element limited by the statement "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In the absence of further restrictions, an element limited by the statement "comprising a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element.

[0061] In the following, the terms "first" and "second" are used for descriptive purposes only and should not be understood to indicate or imply relative importance or implicitly specify the number of the technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of the features. In the description of this embodiment, unless otherwise specified, "plurality" means two or more.

[0062] In order to facilitate understanding of the technical solutions of the embodiments of the present application, a brief introduction to the relevant technologies of the present application is first given as follows.

[0063] 1. Process: A computer program's activity on a set of data. A process is the basic unit of resource allocation in an operating system and forms the foundation of its architecture.

[0064] Electronic devices, such as mobile phones, rely on processes to run applications. The following briefly describes the application execution process.

[0065] When an application runs, the electronic device loads the application's execution code into memory and creates a process for the application. The electronic device allocates a memory area for the process. This memory area is used to store the application's execution code, static data, and other information.

[0066] When a process is running, the size of the process's memory area changes dynamically. In other words, when a process is running, the size of the memory occupied by the process changes dynamically. Specifically, a process can call a memory allocation function to request memory space from the operating system to store the data required for the process to run. This data may include data such as the function to be called during the process's operation, the function's local variables, the parameters required to run the function, and the function's return value. The memory allocation function can be used to request memory. For example, the memory allocation function can be the vmalloc function, the Malloc function family, etc. After executing the function, the process can release the requested memory space. The process can execute a memory release function to release the memory space. In some embodiments, a function can also be referred to as a method, an object, or code.

[0067] 2. Resources: In the computer field, resources generally include hardware or software components that can be used by programs or systems. These resources are essential for the normal and efficient operation of computer systems. Examples include memory, file handles, and threads.

[0068] 3. Resource leak: In a computer program, memory, file handles, threads, or other resources that have been allocated to the program are not released correctly, resulting in waste or exhaustion of system resources. This is considered a resource leak. Resource leaks may cause the program to run slower, the system to crash, or other undefined behaviors. For example, in programming languages ​​​​such as C and C++, programmers need to manually allocate and release memory. If they forget to release the allocated memory, a memory leak will occur, resulting in memory waste. Especially when the program is running for a long time, it will cause the memory to be continuously consumed, eventually leading to low system memory, or even a crash and restart.

[0069] 4. Resource leaks: These are code locations within a program where resources (such as memory, file handles, and database connections) may not be properly released or closed. This is typically caused by improper resource allocation and release management within a function or code block. Resource leaks can occur at the function level or at the specific line level.

[0070] 5. Call stack: Also known as the execution stack, control stack, runtime stack, or machine stack, it refers to a key data structure used to manage function calls and recursive processes in computer programs. The call stack is used to track the order of function calls during program execution. Whenever a function is called, it is pushed to the top of the call stack, making it the currently executing function. A stack is a special linear table that can only insert and delete data at one end. The stack can store data according to the last-in-first-out principle. Specifically, the data that enters first is pushed to the bottom of the stack, and the data that enters later is pushed to the top of the stack. When reading data, data is popped from the top of the stack, that is, the last data is read out first. The stack can be used to store function call information such as local variables, function parameters, and return addresses during process runtime.

[0071] When a process calls a function, it generates a call stack, also known as a call stack result. The call stack result can be used to track the process of function calls and reflect the execution logic of the code. When an application is running, its corresponding process will call the main function, which will call another function, which will call another function. This calling relationship between functions is the call stack result of the process. For example, Figure 1 The call stack structure diagram provided in the embodiment of the present application is as follows: the process calls function a, function a calls function b, and function b calls function c. The corresponding call stack structure is as follows: Figure 1 As shown in (a) in the figure. If function c gets stuck during execution, the call stack of the process at that time can be obtained. Based on the call stack, the above functions that call function c can be obtained, as well as the calling relationship between each function layer.

[0072] The call stack result can reflect the calling relationship of resource allocation functions. For example, the process calls function a, function a calls function b, function b calls the memory allocation function, and applies for a piece of memory. The corresponding call stack structure is as follows Figure 1 As shown in (b) in .

[0073] For example, when the memory usage of a process is too high, the call stack result can reflect the memory application of the process, specifically, the call status of the memory allocation function. For example, it can reflect which functions call the memory allocation function to apply for memory space, as well as the calling logic between functions. This information can be used to check whether the code has abnormal operation or unreasonable design. The structure of the obtained call stack result is as follows: Figure 1 Taking (b) as an example, we analyze the call stack layer by layer to find the initial call function a. We further analyze the entire code from the call function a to the call to the memory allocation function to see if there are any exceptions or if there is any failure to release memory in a timely manner.

[0074] 6. Call stack unwinding: This is also called "call stack unwinding," a method for analyzing function call relationships during program execution. The call stack unwinding process typically includes the following four steps:

[0075] Step 1: Determine the starting point, that is, find the stack frame base address of the currently executing function.

[0076] Step 2: Restore the stack frame, that is, starting from the current stack frame base address, backtrack along the stack frame one by one. Step 2 involves parsing the information of each stack frame, such as local variables, function parameters, return address, etc.

[0077] Step 3: Build the call stack. This involves integrating the stack frame information found during the backtrace into a call frame information (CFI). The call stack data structure can be a linked list or tree. Step 3 determines the hierarchy and order of function calls.

[0078] Step 4: Analysis and processing. Based on the call stack results obtained by backtracing, various analysis and processing operations can be performed, such as performance analysis, troubleshooting, and debugging.

[0079] In practical applications, stack back can be implemented using unwind technology, debuggers, or dynamic binary instrumentation frameworks.

[0080] Since the location of resource leakage points in electronic devices is relatively random, it is difficult for the system to distinguish whether resource consumption is required by normal business operations or resource leakage has occurred. Therefore, when a resource leakage problem occurs, it is often difficult for electronic devices to capture valid logs at the fault site of the resource leakage. For example, when a program crashes due to memory overflow (out of memory crash, OOM crash), because the memory is not enough to meet a certain resource request of the program, the operating system will interrupt the execution of the current program and throw an OOM error. At this time, the electronic device can only obtain the call stack of the resource request that caused the OOM crash, but cannot directly know which module or code segment caused the memory overflow. Especially for online probabilistic problems in products, if the resource allocation call chain cannot be obtained, the electronic device can hardly locate the resource leakage point.

[0081] In related technologies, electronic devices often need to obtain relatively detailed information to locate resource leaks, such as capturing the resource application call stack. For example, in the case of a memory leak, to locate the cause of the memory leak, the electronic device needs to capture detailed memory resource application information, including the resource application size and the resource application call stack. Capturing the application call stack is crucial for electronic devices to locate resource leaks.

[0082] On the Android system, the resource request interface is located in the native code layer, while the program code is often in the Java layer. Therefore, electronic devices need to trace back from the native layer to the Java layer when capturing the call stack. When the tool captures the call stack related to resource request, the electronic device will trace back from the native layer to the Java layer using an unwind table. However, this stack traceback method has relatively poor performance and will negatively impact the performance of the resource request interface. In addition, because memory requests within the program are often very frequent, it may cause the program to become unresponsive or freeze, which in turn renders the tool unusable.

[0083] In the relevant technology, Android applications can include multiple calling modes, such as: Java Native Interface (JNI) call execution, optimized Android application (OAT) local machine code execution, interpreted execution mode and just-in-time (JIT) execution mode. Different calling modes correspond to different resources. For example, the resources corresponding to the JNI execution call include but are not limited to JNI libraries, native code (C or C++), and Java code (interacting with it through the JNI interface). For another example, the resources corresponding to the OAT local machine code execution include but are not limited to decentralized exchange (DEX) bytecode, optimized local machine code, and OAT files (containing compiled local machine code). For another example, the resources corresponding to the interpreted execution mode include but are not limited to DEX bytecode and interpreter. For another example, the resources corresponding to the JIT execution mode include but are not limited to DEX bytecode, JIT compiler, and cache (storing compiled local machine code).

[0084] In the JNI call execution mode, the execution process of the electronic device tracing back from the native layer to the Java layer for stack back includes: setting the correct unwind rule for the JNI function in the unwind table to restore the specific register, so as to find the correct stack frame base address. Through the JNI interface, the stack frame is traced back one by one according to the stack frame base address to obtain the call stack result of the Java layer. The AOSP source code includes relevant definitions of the unwind table and examples of how to add unwind rules for JNI functions. For example, for the 32-bit advanced RISC machines (ARM) architecture, the specific register used to save the current stack frame base address is the r10 register; for the 64-bit ARM architecture, the specific register used to save the current stack frame base address is the x28 register.

[0085] In OAT native machine code execution mode, OAT is part of the Android Runtime (ART) and is responsible for compiling DEX bytecode into native machine code. In OAT native machine code execution mode, the electronic device's stack traceback from the native layer to the Java layer is similar to the execution process of Executable and Linkable Format (ELF) files. This can include dynamically attaching a debugger (such as GNU Debugger or Frida) at runtime to capture and analyze the call stack results during native machine code execution.

[0086] In interpreted execution mode, ART interprets and executes the DEX bytecode line by line. The execution process of the electronic device tracing back from the native layer to the Java layer for stack recovery can include: setting breakpoints in the interpreter to pause the execution of the application at runtime. Use a debugger to capture the call stack results. The debugger can access the values ​​in the registers, such as accessing the r4 register of the 32-bit ARM architecture or the x19 or x20 registers of the 32-bit ARM architecture, which store the address of the DEX instruction currently being executed. Restore the specific location of the DEX bytecode based on the DEX instruction address, and search for the corresponding function signature from the DEX file. In this way, when printing the stack, the corresponding function signature can be retrieved from the DEX file, thereby realizing stack recovery from the native layer to the Java layer.

[0087] In JIT execution mode, ART will compile hot code (i.e. frequently executed code, such as code executed more than 10,000 times) into native machine code at runtime and store it in the memory of the just-in-time compilation cache (JIT cache) to improve performance. Similar to the OAT native machine code execution mode, electronic devices need to trace back from the native layer to the Java layer to perform stack retracing in JIT execution mode. A debugger can be dynamically attached at runtime to capture and analyze call stack results during the execution of native machine code. Unlike OAT, the JIT cache is different from the ELF structure. The debug information (debug info) of the JIT cache is stored separately in a data structure called the JIT debug descriptor (JIT_debug_descriptor). This is a new feature introduced to the Android Open Source Project (AOSP) starting with Android 8.0 (API level 26).

[0088] To sum up, in the relevant technologies, although the methods for electronic devices to perform cross-execution layer stack back in different execution modes are different, in the above four execution modes, electronic devices need to trace back from the native layer to the Java layer when performing stack back, which brings certain performance overhead and resource consumption to the electronic devices, and the stack back efficiency is very low, resulting in low efficiency in locating resource leakage points based on relevant technologies.

[0089] In response to the above problems, an embodiment of the present application provides a method for locating resource leakage points. The resource application interface is located in the native layer of the electronic device. By proxying the resource application interface at the native layer, the corresponding function stack memory information and register information are intercepted when the resource application interface is called, and the stack is directly returned at the native layer based on the function stack memory information and register information. When returning to the stack, there is no need to trace back from the native layer to the Java layer, thereby reducing the performance overhead and resource consumption caused by the stack return, and achieving the technical effect of improving the efficiency of locating resource leakage points.

[0090] For example, the electronic devices described in the embodiments of the present application may be mobile phones, tablet computers, desktop computers, laptop computers, handheld computers, notebook computers, ultra-mobile personal computers (UMPCs), netbooks, as well as cellular phones, personal digital assistants (PDAs), augmented reality (AR) and virtual reality (VR) devices, media players, wearable devices, and the like. The embodiments of the present application do not impose any particular restrictions on the specific form of the electronic devices.

[0091] For the convenience of description, the embodiment of the present application takes the electronic device being a mobile phone as an example to introduce the technical solutions involved in the embodiment of the present application.

[0092] In the embodiment of the present application, the electronic device is taken as a mobile phone 100 as an example, and the hardware structure of the electronic device is introduced through the mobile phone 100. Figure 2 The hardware structure diagram of the electronic device provided in the embodiment of the present application is as follows: Figure 2 As shown, the mobile phone 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0093] The processor 110 may include one or more processing units, for example, the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU), a driver processor, etc. Different processing units may be independent devices or integrated into one or more processors. The processor 110 may be the nerve center and command center of the mobile phone 100. The processor 110 may generate an operation control signal based on the instruction opcode and timing signal to complete the control of instruction fetching and execution.

[0094] Processor 110 may also include a memory for storing instructions and data. In some embodiments, the memory in processor 110 is a cache memory. This memory can store instructions or data that have just been used or are being recycled by processor 110. If processor 110 needs to use the same instruction or data again, it can directly access the memory. This avoids duplicate accesses, reduces processor 110 latency, and thus improves system efficiency.

[0095] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to extend the storage capability of the mobile phone 100. The external memory card communicates with the processor 110 through the external memory interface 120 to implement a data storage function. For example, files such as music and videos are stored in the external memory card. In some implementations, debugging information used for stack backtracking can be stored in the external memory card.

[0096] The internal memory 121 can be used to store computer executable program codes, which include instructions. The processor 110 executes various functional applications and data processing of the mobile phone 100 by running the instructions stored in the internal memory 121. For example, in the embodiments of the present application, the processor 110 can execute the instructions stored in the internal memory 121, and the internal memory 121 can include a storage program area and a storage data area. The mobile phone 100 can allocate stack memory and heap memory for a process through the internal memory 121.

[0097] The storage program area can store an operating system, at least one application program required by a function (such as a sound playing function, an image playing function, etc.), a configuration file of the motor 191, etc. The storage data area can store data created during use of the mobile phone 100 (such as audio data, a phonebook, etc.), etc. In addition, the internal memory 121 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, a universal flash storage (UFS), etc.

[0098] The charging management module 140 is used to receive a charging input from a charger. The charger can be a wireless charger or a wired charger. The charging management module 140 charges the battery 142, and at the same time, can also supply power to the mobile phone 100 through the power management module 141.

[0099] The wireless communication function of the mobile phone 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, a modem processor, a baseband processor, etc. In some embodiments, the antenna 1 and the mobile communication module 150 of the mobile phone 100 are coupled, and the antenna 2 and the wireless communication module 160 are coupled, so that the mobile phone 100 can communicate with a network and other devices through a wireless communication technology.

[0100] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in mobile phone 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, the antennas can be used in conjunction with a tuning switch.

[0101] The mobile communication module 150 can provide wireless communication solutions for mobile phone 100, including 2G / 3G / 4G / 5G. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low-noise amplifier (LNA), etc. The mobile communication module 150 receives electromagnetic waves from antenna 1, filters and amplifies the received electromagnetic waves, and transmits them to the modem processor for demodulation.

[0102] The wireless communication module 160 can provide wireless communication solutions for the mobile phone 100, including wireless local area networks (WLAN) (such as Wi-Fi networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc.

[0103] It is to be understood that the interface connection relationship between the modules illustrated in this embodiment is merely a schematic illustration and does not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also include more or fewer modules than those provided in the above embodiments, and different interface connection methods or a combination of multiple interface connection methods may be used between the modules. The hardware structure of the electronic device provided in the embodiments of the present application may also refer to the hardware structure of the mobile phone 100 shown in the figure. The methods in the following embodiments can all be implemented in an electronic device having the above hardware structure.

[0104] In the embodiments of the present application, the software system of the electronic device may adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture or a cloud architecture. Figure 3 The software structure diagram of the electronic device provided in the embodiment of the present application is as follows: Figure 3 As shown, the embodiment of the present application takes the electronic device as the above-mentioned mobile phone 100 and the software system of the electronic device adopts the layered architecture of the Android system as an example to illustrate the software structure of the electronic device.

[0105] The layered architecture divides software into several layers, which communicate with each other through software interfaces. In some embodiments, the Android system is divided into five layers: application layer, application framework layer, system runtime layer, hardware abstraction layer (HAL), and kernel layer.

[0106] The application layer can include a series of application packages, including camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, video, short message and other applications.

[0107] The application framework layer provides an application programming interface (API) and programming framework for applications in the application layer. The application framework layer includes predefined functions. The application framework layer may include a window manager, content provider, view system, resource manager, notification manager, activity manager, input manager, and so on.

[0108] In some embodiments, the application layer and the application architecture layer may also be collectively referred to as the Java layer.

[0109] The system runtime layer includes the Android runtime (ART) and native C / C++ libraries. The system runtime layer is also called the native layer.

[0110] The Android runtime includes core libraries and a virtual machine. It converts source code into machine code. It primarily utilizes ahead-of-time (AOT) and just-in-time (JIT) compilation technologies.

[0111] The core library is mainly used to provide basic Java class library functions, such as basic data structures, mathematics, IO, tools, databases, networks, etc. The core library provides an API for users to develop Android applications.

[0112] The application layer and application framework layer run in a virtual machine. The virtual machine executes Java files in the application layer and application framework layer as binary files. The virtual machine manages object lifecycles, stack management, thread management, security and exception management, and garbage collection.

[0113] Native C / C++ libraries can include multiple functional modules, such as surface manager, media framework, libc, OpenGL ES, SQLite, Webkit, etc.

[0114] The Hardware Abstraction Layer (HAL) runs in user space, encapsulating kernel drivers and providing a calling interface to upper layers. For example, the HAL layer may include display modules, audio modules, camera modules, Bluetooth modules, etc.

[0115] The kernel layer is the layer between hardware and software. The kernel layer includes drivers and operating system programs. The kernel layer includes display drivers, camera drivers, audio drivers, Bluetooth drivers, etc.

[0116] The following describes the workflow of the software and hardware of the mobile phone 100 in conjunction with an image display scenario. In this scenario, the mobile phone 100 displays image data in response to a user's touch operation.

[0117] The touch sensor of the mobile phone 100 receives the user's touch operation and sends a hardware interrupt of the touch operation to the kernel layer of the mobile phone 100. In response to the hardware interrupt of the touch operation, the kernel layer of the mobile phone 100 processes the touch operation into an original input event (including touch coordinates, timestamp of the touch operation, and other information). The kernel layer of the mobile phone 100 reports the original input event. The application framework layer obtains the original input event from the kernel layer and identifies the control corresponding to the original input event. Taking the control corresponding to the original input event as the control of the gallery application icon as an example, the gallery application process calls the interface of the application framework layer and calls the kernel layer to load the stored image data. The display driver in the kernel layer of the mobile phone 100 will eventually send the image data to the display screen 194, and the display screen 194 will display the image data. In this way, the mobile phone 100 displays the image data in response to the user's touch operation.

[0118] In the following embodiments, the electronic device is as follows Figure 2 The software structure of the mobile phone is as follows: Figure 3 Taking the Android system architecture as an example, the method for locating resource leakage points provided by the embodiment of the present application is introduced. Figure 4 Schematic diagram of the method for locating resource leakage points provided in this embodiment of the application Figure 1 .like Figure 4 As shown, the method for locating a resource leakage point provided in an embodiment of the present application includes the following steps:

[0119] Step 401: In a business process, when a business thread calls a resource application interface to apply for resources, the business thread obtains corresponding resource call information, which includes function stack memory information and register information corresponding to the resource application interface; a business process includes one or more business threads.

[0120] A business process may include one or more business threads, such as business thread 1, business thread 2, business thread 3, ..., business thread i, ..., business thread n. The corresponding resource call information may refer to the resource call information corresponding to the business thread. The resource request interface, for example, may be the application programming interface (API) corresponding to the mobile phone system library (i.e., the operating system). Corresponding to the resource request interface, the operating system also includes a resource release interface. Business threads may request resources when processing various business logic. For example, when a business thread needs to create an object, array, or other data structure, it requests memory resources. When a business thread needs to read, write, or manipulate a file, it requests a file handle. When a business thread needs to access a database to execute SQL queries, update database records, etc., it requests a database connection. When a business thread needs to communicate over the network, it requests a network socket. When the logic of a business thread needs to execute concurrently, a new business thread is created. The function stack is a data structure used to store information such as local variables, function parameters, and return addresses during program execution. Each thread has its own stack, and each function call allocates a block of memory on the stack (called a stack frame). Registers are fast storage areas within the CPU, used to store instructions, data, and address information. Register information can include, but is not limited to, general-purpose registers for storing data and addresses, special registers with specific functions, floating-point registers for storing floating-point numbers, status registers for storing CPU status information, and instruction registers for storing the currently executing instruction. By analyzing function stack memory and register information, we can understand the program's execution status, call relationships, and the values ​​of local variables and parameters, which is crucial for locating resource leaks through stack unwinding.

[0121] Step 402: Start a target thread in the service process, where the target thread is different from the service thread.

[0122] The target thread can be alternatively described as a service thread, server, or multi-threaded mode (work thread). The target thread is a separate thread in the business process that is different from the business thread and is used to perform stack processing using function stack memory information and register information.

[0123] Step 403: Through the target thread, the resource call information corresponding to the business process is back stacked to obtain a call stack result; the call stack result is used to reflect the resource call relationship of the business thread.

[0124] The target thread can be used to execute a stack back operation on the resource call information (ie, function stack memory information and register information) saved in step 301 to obtain a call stack result reflecting the resource call relationship.

[0125] This application does not further limit the method for the target thread to return to the stack. For example, the return to the stack operation can be performed by reading the unwind table in the program binary.

[0126] Step 404: Determine the resource leak point based on the call stack result.

[0127] The specific method of determining the resource leakage point based on the call stack result can be to perform stack back processing through the resource call information to obtain the call stack result when the program is running, and analyze the allocation and release of resources (such as memory, file handles, database connections, etc.) for the collected call stack results. Check whether there are functions or code blocks that do not release resources correctly. Find the location that may cause resource leakage in the call stack. In particular, when resources are allocated in the function but not correctly released before the function exits, recursive calls or circular references prevent resources from being released, or improper exception handling causes resources to not be released when an exception occurs, the probability of resource leakage is relatively high. After locating the suspected resource leakage point, verify whether the resource is indeed leaked by writing test cases, using debuggers or performance analysis tools, etc. This application does not further limit the specific method of determining the resource leakage point based on the call stack results.

[0128] Figure 4 In the example, two different types of arrows represent control flow and data flow, respectively. Control flow describes the order in which business processes are executed, while data flow describes the data transfer and processing within the program. The business thread calling the resource request interface to request resources and the target thread performing stack callback processing based on the resource call information constitute data flow. Obtaining the corresponding resource call information constitutes control flow, performing stack callback processing based on the resource call information constitutes control flow, obtaining the call stack result after stack callback processing constitutes control flow, and determining the resource leak point based on the call stack result constitutes control flow.

[0129] It should be noted that a resource leak point is a location or code segment in a program that may cause a resource leak. By analyzing the call stack results, the code location that caused the resource leak can be determined.

[0130] In this way, by intercepting the corresponding function stack memory information and register information when the resource request interface is called, a new target thread is added inside the business process, and the stack is returned at the native layer based on the function stack memory information and register information. When returning to the stack, there is no need to trace back from the native layer to the Java layer, thereby reducing the performance overhead and resource consumption brought by the stack return, and achieving the technical effect of improving the efficiency of locating resource leakage points.

[0131] In one possible implementation, determining a resource leakage point based on a call stack result may include: determining the number of resource applications and the size of resource occupancy corresponding to the call stack result; screening out call stack results whose corresponding number of resource applications is greater than a third preset threshold or whose resource occupancy size is greater than a fourth preset threshold; and determining a resource leakage point based on the screened call stack results.

[0132] It is understandable that the call stack logs of various resource applications can be determined based on the call stack result list on the server side, and information such as each call stack result and the corresponding number of resource applications and resource occupancy size can be obtained based on the call stack logs.

[0133] In this way, the call stack results with a higher probability of resource leakage are screened out through the number of resource applications and resource occupancy size corresponding to the call stack results. The functions or code segments that may cause resource leakage are found according to the call stack results, and the resource leakage points where resource leakage occurs are determined, thereby improving the accuracy and efficiency of locating resource leakage points.

[0134] In one possible implementation, the resources requested by the business process include multiple different types. In step 401 above, when the business thread calls the resource request interface to request a resource, obtaining the corresponding resource request information may include the following two steps:

[0135] Step 1: When the business thread calls the resource application interface to apply for resources, the resource type of the resource is obtained.

[0136] There are many types of resources, such as memory, file handles, threads, etc.

[0137] Step 2: Obtain the resource call information corresponding to the resource, as well as the correspondence between the resource type and the resource call information.

[0138] In this way, after the correspondence between resource types and resource calling information is obtained, different types of resource calling information can be stored in different caches respectively.

[0139] For example, a separate data structure (such as a hash table, list, or tree) can be designed for each resource type to store call information related to that resource type. These data structures can be stored in the same container (such as a dictionary or map) to facilitate fast access based on resource type. For example, each resource type can correspond to a cache list: cache list 1 for memory resources, cache list 2 for file handle resources, and cache list 3 for thread resources.

[0140] Since resources of different resource types have different access modes, storing resource call information separately according to resource type can further improve the access speed of resource call information.

[0141] In another possible implementation, when a service thread calls a resource request interface to request a resource, obtaining the corresponding resource call information may include associating the resource call information with the service thread and storing the resource call information corresponding to different service threads in different caches. For example, a separate data structure (such as a hash table, list, tree, etc.) may be designed for each service thread to store the resource call information related to that service thread. These data structures may be stored in the same container (such as a dictionary, map, etc.) to facilitate fast access based on the service thread.

[0142] In another possible implementation, when a business thread calls a resource application interface to apply for resources, obtaining corresponding resource call information can include establishing a correspondence between resource call information, resource type, and business thread, and storing resource call information corresponding to different resource types and different business threads in different caches.

[0143] In one possible implementation, when a service thread calls a resource application interface to apply for a resource, obtaining the resource type of the resource includes: hooking the resource application interface of the proxy operating system based on a hook function, and obtaining the resource type of the resource when the service thread calls the resource application interface to apply for the resource. Obtaining resource call information corresponding to the resource, and the corresponding relationship between the resource type and the resource call information, includes: obtaining the resource call information corresponding to the resource based on the hook function, and the corresponding relationship between the resource type and the resource call information.

[0144] The hook function can proxy the resource request interface and intercept resource call information when the resource request interface is called. For example, the mobile phone can implement a memory allocation proxy function through the hook function. When the mobile phone's service process calls the memory allocation function through the memory allocation function interface, the mobile phone implements the memory allocation proxy function through the hook function to intercept the resource call information.

[0145] In this way, the resource application interface can be proxied through the hook function. When the resource application interface is called, the resource type and resource call information of the resource can be obtained to intercept the resource call information.

[0146] In one possible implementation, the resource leakage point location method provided in the embodiment of the present application involved in step 404 further includes the following three steps:

[0147] Step 1: Create a corresponding client based on the resource type; different resource types correspond to different clients.

[0148] It is understandable that a separate client is created for each resource type, and the client can be identified by assigning a unique identity document (ID) to each client. For example, Figure 5 The resource call information storage diagram provided in the embodiment of this application is as follows: Figure 5 As shown, the client ID of the memory resource application type is 1, the client ID of the file handle (fd) application type is 2, and the client ID of the thread application type is 3.

[0149] Step 2: Based on the correspondence between the resource type and the resource call information, the resource call information is stored in the cache of the client of the corresponding resource type.

[0150] The client of the mobile phone native layer usually refers to the program code that runs directly at the bottom layer of the operating system. This part of the code does not rely on any specific application framework, but directly interacts with the hardware and operating system kernel.

[0151] Continue reading Figure 5 Each client corresponds to a cache list. For example, the client with client ID 1 corresponds to cache list 1, the client with client ID 2 corresponds to cache list 2, and the client with client ID 3 corresponds to cache list 3. When applying for the resource application interface, the resource call information corresponding to each resource type, namely the function stack memory information and register information, can be stored in the client's cache list respectively.

[0152] Step 3: Through the target thread, according to the corresponding relationship, resource call information of different resource types is obtained from the cache of each client; the resource call information of different resource types is used to locate the resource leakage point of the corresponding resource type.

[0153] Please continue reading Figure 5The target thread can obtain resource call information of different resource types from the client cache according to the corresponding relationship, and then perform stack back processing according to the resource call information of different resource types, and store the obtained call stack results in the call stack result list corresponding to each resource type in the server (i.e., the target thread).

[0154] In this way, since resources of different resource types correspond to different access modes, storing resource call information separately according to resource types can further improve the access speed of resource call information.

[0155] Moreover, in a multi-threaded or concurrent environment, if different types of resource call information are stored in the same cache, the probability of conflict may increase. Separate storage can reduce the probability of conflict. Figure 6 Schematic diagram of the method for locating resource leakage points provided in this embodiment of the application Figure 2 .like Figure 6 As shown, in a possible implementation manner, the method for locating a resource leakage point provided in an embodiment of the present application further includes: creating a signal processing function.

[0156] Among them, the signal processing function is used to create the corresponding client based on the resource type, initialize the client, create the system agent, manage the system agent, etc. Among them, the system agent is used to hook the agent resource application interface based on the hook function to obtain the resource call information corresponding to the resource and the correspondence between the resource type and the resource call information.

[0157] The external process can send a signal to the business process to trigger the execution of a function, thereby creating a signal processing function to control the start and end of a stack capture request. For example, the external process can initiate a stack capture request when it detects that the memory usage of the business process exceeds a preset threshold. For another example, the external process can initiate a stack capture request at a preset time point. For another example, the external process can initiate a stack capture request when a preset time interval has elapsed since the last stack capture request.

[0158] The signal processing function responds to the resource stack capture request within the application process and creates the corresponding client based on the resource type. The client ID corresponding to each client is different. A system proxy is created based on the signal processing function, and the signal processing function can manage the system proxy, including enabling and stopping the proxy. When the mobile phone detects the execution of the system proxy, the system proxy can start the target thread, that is, the server. It can be understood that one business process corresponds to one target thread, and the target thread can perform stack processing on the resource call information in the business process. The target thread is a newly started independent thread that can perform stack processing on the resource call information of each business thread in the current business process.

[0159] When the signal processing function enables the proxy, it can hook the proxy resource request interface through the hook function. Each time the business thread requests a resource from the resource request interface, the hook function intercepts the resource call information in the request interface function and saves the resource call information to the client's corresponding cache list. When the stack capture is completed, the signal processing function stops executing the system proxy and stops intercepting resource call information based on the hook function. It also saves the call stack results that have been returned to the stack to the call stack result list, obtaining the call stack results of all resources during the stack capture. The call stack results can be used to locate resource leaks.

[0160] In this way, through the signal processing function and system proxy, the resource call information of the resource application interface can be intercepted, and the resource call information can be returned to the stack through the target thread to obtain the call stack result, and then the resource leakage point can be located, which helps to realize the call stack backtracking at the native layer and improve the efficiency of locating the resource leakage point.

[0161] In one possible implementation, performing stack unwinding on resource call information corresponding to a business process via a target thread to obtain a call stack result includes: performing stack unwinding on resource call information corresponding to the business process via the target thread to obtain a call stack result when preset conditions are met. For example, the preset conditions include: the capacity of a cache occupied by the resource call information is greater than a first preset threshold, a first instruction instructing stack unwind is received, a preset time point for stack unwind is reached, or a time interval since the last stack unwind is greater than a second preset threshold.

[0162] In this way, the target thread can retrieve the resource call information by backtracking the call stack, and then locate the resource leak point. This helps to implement call stack backtracing at the native layer and improve the efficiency of locating resource leak points.

[0163] In one possible implementation, a target thread performs stack unwinding on resource call information corresponding to a business process to obtain a call stack result. This includes: reading an unwind table in the program binary based on the resource call information corresponding to the business process through the target thread, and performing stack unwinding based on the unwind table to obtain a call stack result.

[0164] It should be noted that the call stack result is information generated during the program compilation process, concurrently with machine instruction execution, and is used to provide push information for the application process's call stack. This push information indicates the location of the data stored in the call stack. The mobile phone can obtain the call stack result corresponding to the business process. Because the call stack result records the push information, the mobile phone can unwind the application process's call stack using the location of the return address in the call stack provided by the call stack result.

[0165] It is understood that when an application process is running, the mobile phone temporarily stores various data required for the application process in registers to enable fast data access and writing. For example, the mobile phone can temporarily store the execution instructions, execution instruction addresses, calculation results, etc. of the application process in registers. In order to record the function call relationships during the application process, the mobile phone also stores the data in the registers in the call stack. For example, the mobile phone can store the execution instruction address, function return address, stack top address (also called stack pointer), stack bottom address, etc. recorded in the registers in the call stack. The call stack result can provide the position of the data in these registers in the call stack.

[0166] For example, the call stack result includes a call stack unwind table (an example of stack information). The call stack result can be formatted using the debug with arbitrary record format (DWARF). The phone can obtain the call stack result in the ".eh_frame" data segment or the ".debug_frame" data segment of the ELF file.

[0167] It's understandable that by analyzing the program counter (PC) value, the phone can query the unwindtable to determine how each register should be restored when exiting the current function stack, thereby determining the structure and state of the function call stack. For example, the PC value may describe the current stack location where the register value should be read back.

[0168] In this way, stack backing is performed at the native layer by unwinding the table to obtain the call stack result, without having to perform stack backing across execution layers. This helps improve stack backing efficiency and, in turn, helps improve the efficiency of locating resource leak points.

[0169] In the case where resource call information is stored separately by resource type, backtracking can be performed based on different resource types. When backtracking based on a specific resource type is required, the data structure corresponding to that resource type is first found in the container. Then, based on the characteristics of that data structure (such as the key-value pairs in a hash table or the order of a list), the corresponding backtracking operation is performed. For example, searching for a specific key-value pair in a hash table or traversing a list in reverse order to find the most recent call record.

[0170] When a program uses the malloc interface to request memory, if there is dynamically allocated memory that is not properly released using the free function, this memory will no longer be usable by the program. Even after the program ends, the operating system must reclaim this memory. Memory leaks can reduce available memory. This may occur when there is sufficient overall memory but too much fragmentation prevents the program from allocating sufficient contiguous memory space.

[0171] A program uses the open interface to open a file, but does not use the close interface to close it after the file operation is completed. This will cause the number of available file descriptors in the system to decrease. When other processes or threads need to open new files, they may fail due to file descriptor exhaustion.

[0172] A thread leak occurs when threads created using pthread_create are not properly recycled after completing their tasks. This can cause thread resource usage, resulting in a reduction in system resources and performance degradation. When the system's thread limit is reached, new threads cannot be created, impacting program functionality.

[0173] In the case where the resource call information corresponding to different business threads is stored in different caches, the stack can be backtracked based on different business threads to determine the resource leakage point. When it is necessary to backtrack based on a specific business thread, first find the data structure corresponding to the business thread from the container. Then, according to the characteristics of the data structure (such as the key-value pairs of the hash table, the order of the list, etc.), perform the corresponding backtracking operation. For example, search for a specific key-value pair in the hash table, or traverse the list in reverse order to find the most recent call record.

[0174] In a possible implementation, after obtaining the call stack result, the method further includes: deduplicating the call stack results indicating the same resource call relationship and saving them, and recording the number of the same call stack results.

[0175] For example, key information such as function name, resource name, and line number can be extracted from each call stack result. This key information can be used to represent resource call relationships. Call stack information indicating identical resource call relationships is deduplicated and saved. This allows identical call stack results to be grouped together, saving memory space and reducing unnecessary resource waste.

[0176] In one possible implementation, the call stack results indicating the same resource call relationship are deduplicated and saved, and the number of identical call stack results is recorded, including: performing hash calculation on the call stack results, deduplicating the call stack results with the same hash value and saving them, and recording the number of call stack results with the same hash value.

[0177] In this way, the call stack information can be very large and complex, while the hash value is relatively short. After converting the call stack information into a hash value, the storage space requirement can be significantly reduced, and it is beneficial to quickly compare whether the call stack information is the same. After deduplication of the call stack information with the same hash value, the memory space can be saved, and unnecessary resource waste can be reduced.

[0178] In a possible implementation, after obtaining the call stack result, the method further includes: stopping the hook function-based proxy resource application interface. The call stack result is stored to the corresponding client.

[0179] For example, when the total capacity of all cache lists stored in the client exceeds a certain size, the target thread can perform the backstack operation on the resource call information in the cache list, and save the call stack result to the corresponding backstack result list in the client respectively.

[0180] For example, the external process can initiate the end-of-grabbing-stack request when detecting that the memory occupancy of the business process is greater than a preset threshold. For another example, the external process can initiate the end-of-grabbing-stack request when reaching a preset time point. For yet another example, the external process can initiate the end-of-grabbing-stack request when reaching a preset time interval from the last grabbing-stack request or the end-of-grabbing-stack request.

[0181] In this way, after the end of grabbing the stack, the hook function-based proxy resource application interface can be stopped, and the call stack result can be stored to the client, so that the potential resource leakage point can be more accurately diagnosed based on the call stack result.

[0182] The embodiment of the application further provides a backstack processing method, which includes:

[0183] In the business process, when a business thread calls a resource application interface to apply for a resource, corresponding resource call information is acquired, and the resource call information includes function stack memory information and register information corresponding to the resource application interface. The business process includes one or more business threads. A target thread is started in the business process, and the target thread is different from the business thread. The target thread is used to perform backstack processing on the resource call information corresponding to the business process, to obtain a call stack result. The call stack result is used to reflect the resource call relationship of the business thread.

[0184] The specific implementation can refer to the description in the foregoing embodiments, which will not be described herein.

[0185] In this way, by intercepting the corresponding function stack memory information and register information when the resource application interface is called, a target thread is newly added in the business process, and the backstack is performed based on the function stack memory information and the register information in the native layer. The backstack does not need to trace back from the native layer to the java layer, so that the technical effects of reducing the performance overhead and resource consumption caused by the backstack are achieved.

[0186] The embodiment of the present application further provides an electronic device, comprising at least a memory and one or more processors; the memory is used to store computer instructions, when the one or more processors execute the computer instructions, the electronic device executes each function or step in the above method embodiment.

[0187] The embodiment of the present application further provides a computer readable storage medium, comprising computer instructions, when the computer instructions run on the above electronic device, the electronic device executes each function or step in the above method embodiment.

[0188] The embodiment of the present application further provides a computer program product, when the computer program product runs on the electronic device, the electronic device executes each function or step in the above method embodiment.

[0189] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the convenience and brevity of description, only the above-mentioned division of each functional module is taken as an example, and in actual application, the above-mentioned functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0190] In several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules or units is only a logical function division, and actual implementation can have another division manner, for example, a plurality of units or components can be combined or integrated into another device, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed each other can be through some interface, indirect coupling or communication connection between devices or units, which can be electrical, mechanical or other forms.

[0191] The units described as separate components may or may not be physically separate, and the components shown as units can be one physical unit or multiple physical units, that is, they can be located in one place, or they can be distributed in multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0192] In addition, each functional unit in each embodiment of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The above integrated unit can be realized in the form of hardware or in the form of software functional unit.

[0193] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a device (which can be a single-chip microcomputer, chip, etc.) or a processor (processor) to execute all or part of the steps of the various embodiments of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0194] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for locating a resource leakage point, characterized in that: include: In a business process, when a business thread calls a resource application interface to apply for resources, corresponding resource call information is obtained, where the resource call information includes function stack memory information and register information corresponding to the resource application interface; the business process includes one or more business threads; Starting a target thread in the business process, where the target thread is different from the business thread; Through the target thread, the resource call information corresponding to the business process is processed back to the stack to obtain a call stack result; The call stack result is used to reflect the resource call relationship of the business thread; The resource leak point is determined based on the call stack result.

2. The method according to claim 1, characterized in that When the service thread calls the resource application interface to apply for resources, the corresponding resource call information is obtained, including: When the service thread calls the resource application interface to apply for resources, the resource type of the resource is obtained; The resource calling information corresponding to the resource and the corresponding relationship between the resource type and the resource calling information are obtained.

3. The method according to claim 2, characterized in that When the service thread calls the resource application interface to apply for the resource, obtaining the resource type of the resource includes: Based on the hook function, hook the resource application interface of the proxy operating system, and when the service thread calls the resource application interface to apply for resources, obtain the resource type of the resource; The acquiring the resource calling information corresponding to the resource, and the corresponding relationship between the resource type and the resource calling information, includes: The resource calling information corresponding to the resource and the corresponding relationship between the resource type and the resource calling information are obtained based on the hook function hook.

4. The method according to claim 2 or 3, characterized in that The method further comprises: Creating a corresponding client based on the resource type; wherein different resource types correspond to different clients; Based on the correspondence between the resource type and the resource calling information, storing the resource calling information in a cache of the client corresponding to the resource type; The resource call information of different resource types is obtained from the cache of each client through the target thread according to the corresponding relationship; the resource call information of different resource types is used to locate the resource leakage point of the corresponding resource type.

5. The method according to claim 4, characterized in that The method further comprises: Create a signal processing function; wherein, the signal processing function is used to create a corresponding client based on the resource type; create a system agent based on the signal processing function; wherein, the system agent is used to hook the resource application interface based on the hook function to obtain the resource call information corresponding to the resource and the correspondence between the resource type and the resource call information.

6. The method according to any one of claims 1 to 5, characterized in that The target thread performs stack back processing on the resource call information corresponding to the business process to obtain a call stack result, including: When the preset conditions are met, the resource call information corresponding to the business process is stacked back through the target thread to obtain the call stack result; the preset conditions include: the capacity of the cache occupied by the resource call information is greater than a first preset threshold, a first instruction instructing stack back is received, a preset time point for stack back is reached, or the time interval from the last stack back is greater than a second preset threshold.

7. The method according to any one of claims 1 to 6, characterized in that The target thread performs stack back processing on the resource call information corresponding to the business process to obtain a call stack result, including: Reading an unwind table in the program binary based on the resource call information corresponding to the business process through the target thread; A stack back process is performed based on the unwind table to obtain the call stack result.

8. The method according to any one of claims 1 to 7, characterized in that After obtaining the call stack result, the method further includes: The call stack results indicating the same resource call relationship are deduplicated and saved, and the number of the same call stack results is recorded.

9. The method according to claim 8, characterized in that Deduplicating and saving the call stack results indicating the same resource call relationship, and recording the number of the same call stack results, including: A hash calculation is performed on the call stack results, the call stack results with the same hash value are deduplicated and saved, and the number of the call stack results with the same hash value is recorded.

10. The method according to any one of claims 4 to 9, characterized in that After obtaining the call stack result, the method further includes: Stop proxying the resource application interface based on the hook function hook; The call stack result is stored in the corresponding client.

11. The method according to claims 1 to 10, characterized in that The determining the resource leakage point based on the call stack result includes: Determine the number of resource applications and resource occupancy corresponding to the call stack result; Filter out the call stack results whose corresponding number of resource applications is greater than a third preset threshold or whose resource occupancy size is greater than a fourth preset threshold; The resource leakage point is determined according to the filtered call stack result.

12. An electronic device, characterized in that: The electronic device comprises at least a memory and one or more processors; the memory is used to store computer instructions, and when the one or more processors execute the computer instructions, the electronic device executes the method according to any one of claims 1 to 11.

13. A computer-readable storage medium, characterized in that The method comprises computer instructions, which, when executed on an electronic device, cause the control device and / or the terminal device to execute the method according to any one of claims 1 to 11.

14. A computer program product, characterized in that When the computer program product is run on an electronic device, the electronic device is caused to execute the method according to any one of claims 1 to 11.

Images