Shared memory leak location method and location device

Abstract

The present application provides a method and device for locating a shared memory leak, which is conducive to locating the process that leaks the shared memory and improving the performance of the electronic device. The method includes: setting an identity tag for a file descriptor of at least one shared memory; when a first shared memory leak is detected in at least one shared memory, determining a first process that is currently using the first shared memory; based on the identity tag of the file descriptor of the first shared memory, determining a second process, wherein the identity tag of the file descriptor of the first process corresponding to the first shared memory is the same as the identity tag of the file descriptor of the second process corresponding to the first shared memory; obtaining and displaying call stack information of the file descriptor of the second process corresponding to the first shared memory, the call stack information including information on applying for and / or releasing the first shared memory.

Description

Technical Field

[0001] The present application relates to the field of electronic devices, and more specifically, to a method and device for locating a shared memory leak. Background Art

[0002] With the development of electronic devices, various applications (APPs) continue to emerge. Users can use applications to perform various tasks, such as listening to music, chatting, and playing games. Applications can request system resources, such as shared memory resources. Shared memory allows two running processes to share and transfer data.

[0003] However, after an application requests shared memory, it may leak shared memory, where it remains unused and unreleased for an extended period. This leak can lead to insufficient system memory, impacting system performance. This can cause performance issues such as lags when using the application, negatively impacting the user experience. Therefore, accurately locating the process that leaks shared memory is a pressing technical challenge. Summary of the Invention

[0004] The present application provides a shared memory leak locating method and locating device, which are helpful for locating the process of leaking shared memory and improving the performance of electronic equipment.

[0005] In a first aspect, a method for locating a shared memory leak is provided, the method comprising: setting an identity tag for a file descriptor of at least one shared memory. When a first shared memory leak is detected in the at least one shared memory, determining a first process currently using the first shared memory. Based on the identity tag of the file descriptor of the first shared memory, determining a second process, wherein the identity tag of the file descriptor of the first process corresponding to the first shared memory is the same as the identity tag of the file descriptor of the second process corresponding to the first shared memory. Acquiring and displaying call stack information of the file descriptor of the second process corresponding to the first shared memory, the call stack information including information on applying for and / or releasing the first shared memory.

[0006] In this application, each shared memory is associated with a file descriptor, and an identity tag is set for each file descriptor. This identity tag can be used to identify the shared memory, and the identity tag is passed between processes along with the file descriptor. This allows the identification of at least one second process that shares memory with the first process through the identity tag, and the precise location of the process leaking the shared memory from the at least one second process based on the call stack information of the at least one second process. This helps to solve the problem of insufficient system memory caused by shared memory leaks, which affects system operation, thereby improving the performance of electronic devices.

[0007] In conjunction with the first aspect, in certain implementations of the first aspect, before obtaining and displaying call stack information of the second process's file descriptor corresponding to the first shared memory, the method further includes: recording call stack information of the first shared memory's file descriptor during transfer between the first process and the second process, and storing the call stack information of the first shared memory's file descriptor in memory. Obtaining and displaying the call stack information of the second process's file descriptor corresponding to the first shared memory includes: obtaining and displaying the call stack information of the second process's file descriptor corresponding to the first shared memory from memory.

[0008] In this application, an electronic device can use a file descriptor of a first shared memory to transfer call stack information between a first process and a second process. If a leak in the first shared memory is detected, the electronic device can output the call stack information of the second process corresponding to the file descriptor of the first shared memory. This facilitates obtaining the call stack information of the second process and accurately locating the code line that allocates or releases the shared memory through the call stack information.

[0009] In conjunction with the first aspect, in certain implementations of the first aspect, after setting an identity tag for at least one shared memory file descriptor, the method further includes: indicating the identity tag of the at least one shared memory file descriptor through a pointer of the at least one shared memory file descriptor to an open file table, and recording the identity tag of the at least one shared memory file descriptor in the open file table.

[0010] In the present application, the electronic device can record the identity tag of the file descriptor of the shared memory through the open file table, which is conducive to obtaining the identity tag and thus determining the second process that shares the memory with the first process.

[0011] In conjunction with the first aspect, in certain implementations of the first aspect, determining the second process based on the identity tag of the file descriptor of the first shared memory includes: traversing the file descriptors corresponding to the first shared memory of all processes, and obtaining the identity tags of the file descriptors corresponding to the first shared memory of all processes by opening a file table. Determining the second process based on the identity tag of the file descriptor corresponding to the first shared memory of the first process among all processes.

[0012] In conjunction with the first aspect, in certain implementations of the first aspect, before obtaining and displaying call stack information of the second process corresponding to the file descriptor of the first shared memory, the method further includes: determining whether a function for obtaining call stack information is enabled. If the function for obtaining call stack information is enabled, obtaining and displaying the call stack information of the second process corresponding to the file descriptor of the first shared memory.

[0013] In this application, the function for obtaining call stack information is exemplarily the fdtrack function. In order not to terminate the ongoing process, the electronic device needs to determine whether the fdtrack function is enabled before obtaining the call stack information of the file descriptor, which is conducive to improving the fault tolerance of the system.

[0014] In a second aspect, a device for locating a shared memory leak is provided, comprising: a module for executing the method in any possible implementation of the first aspect. Specifically, the device comprises a module for executing the method in any possible implementation of the first aspect.

[0015] In a third aspect, another device for locating a shared memory leak is provided, comprising a processor coupled to a memory and configured to execute instructions in the memory to implement the method of any possible implementation of the first aspect. Optionally, the device further comprises a memory. Optionally, the device further comprises a communication interface, the processor coupled to the communication interface.

[0016] In one implementation, the shared memory leak location device is an electronic device. When the shared memory leak location device is an electronic device, the communication interface may be a transceiver, or an input / output interface.

[0017] In another implementation, the shared memory leak location device is a chip configured in the electronic device. When the shared memory leak location device is a chip configured in the electronic device, the communication interface may be an input / output interface.

[0018] In a fourth aspect, a processor is provided, comprising: an input circuit, an output circuit, and a processing circuit. The processing circuit is configured to receive a signal through the input circuit and transmit a signal through the output circuit, so that the processor executes the method of any possible implementation of the first aspect.

[0019] In a specific implementation, the processor may be a chip, the input circuit may be an input pin, the output circuit may be an output pin, and the processing circuit may be a transistor, a gate circuit, a trigger, or various logic circuits. The input signal received by the input circuit may be, for example, but not limited to, received and input by a receiver, and the signal output by the output circuit may be, for example, but not limited to, output to and transmitted by a transmitter. The input circuit and the output circuit may be the same circuit, which functions as an input circuit and an output circuit at different times. This application does not limit the specific implementation of the processor and various circuits.

[0020] In a fifth aspect, a processing device is provided, comprising a processor and a memory. The processor is configured to read instructions stored in the memory and receive signals via a receiver and transmit signals via a transmitter to execute the method of any possible implementation of the first aspect.

[0021] Optionally, there are one or more processors and one or more memories.

[0022] Optionally, the memory may be integrated with the processor, or the memory may be provided separately from the processor.

[0023] In the specific implementation process, the memory can be a non-transitory memory, such as a read-only memory (ROM), which can be integrated on the same chip as the processor or be set on different chips. This application does not limit the type of memory and the setting method of the memory and the processor.

[0024] It should be understood that related data interaction processes, such as sending indication information, can be the process of outputting indication information from the processor, and receiving capability information can be the process of receiving input capability information from the processor. Specifically, the output data of the processing can be output to the transmitter, and the input data received by the processor can come from the receiver. The transmitter and receiver can be collectively referred to as a transceiver.

[0025] The processing device in the above-mentioned fifth aspect can be a chip. The processor can be implemented by hardware or by software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, etc.; when implemented by software, the processor can be a general-purpose processor, which is implemented by reading the software code stored in the memory. The memory can be integrated in the processor or can be located outside the processor and exist independently.

[0026] In a sixth aspect, a computer program product is provided, which includes: a computer program (also referred to as code, or instructions), which, when executed, enables a computer to execute the method in any possible implementation of the first aspect.

[0027] In the seventh aspect, a computer-readable storage medium is provided, which stores a computer program (also referred to as code, or instructions) which, when run on a computer, enables the computer to execute the method in any possible implementation of the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] Figure 1 It is a schematic diagram of the communication principle of shared memory;

[0029] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application;

[0030] Figure 3 This is a software structure diagram of an electronic device to which the embodiments of the present application are applicable;

[0031] Figure 4 This is a schematic flow chart of a method for locating a shared memory leak provided in an embodiment of the present application;

[0032] Figure 5 This is a schematic diagram of the relationship between a file descriptor and an open file table provided in an embodiment of the present application;

[0033] Figure 6 is a schematic flow chart of another method for locating a shared memory leak provided in an embodiment of the present application;

[0034] Figure 7 is a schematic block diagram of a shared memory leak location device provided by an embodiment of the present application;

[0035] Figure 8 This is a schematic block diagram of another shared memory leak location device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] The technical solution in this application will be described below with reference to the accompanying drawings.

[0037] To facilitate a clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first" and "second" are used to distinguish between identical or similar items with substantially the same functions and effects. For example, the first process and the second process are used to distinguish different processes and do not limit their order. Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or execution order, and the words "first" and "second" do not necessarily mean that they are different.

[0038] It should be noted that, in this application, words such as "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described in this application as "exemplary" or "for example" should not be construed as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplarily" or "for example" is intended to present the relevant concepts in a concrete manner.

[0039] In addition, "at least one" means one or more, and "more" means two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b and c can mean: a, or b, or c, or a and b, or a and c, or b and c, or a, b and c, where a, b, c can be single or multiple.

[0040] In order to better understand the embodiments of the present application, the terms involved in the embodiments of the present application are first introduced.

[0041] 1. Kernel state and user state

[0042] When a process (or task) executes a system call and falls into the kernel code for execution, the process is generally said to be in the kernel running state, or simply kernel state.

[0043] When a process is executing the user's own code, it is said to be in user running state, or simply user state.

[0044] 2. File descriptor (FD)

[0045] Usually the kernel uses file descriptors to access files. File descriptors are non-negative integers. When opening an existing file or creating a new file, the kernel returns a file descriptor. Each file descriptor corresponds to an open file, and different file descriptors can point to the same file. The same file can be opened by different processes or multiple times in the same process. The system maintains a file descriptor table (FD table) for each process. The values ​​of this table start at 0, so the same file descriptor can be seen in different processes. In this case, the same file descriptor may point to the same file or different files.

[0046] 3. Shared memory

[0047] Shared memory allows two unrelated processes to access the same virtual memory, providing a highly efficient inter-process communication (IPC) method for sharing and transferring data between two running processes. The memory shared between different processes is typically allocated to the same physical memory segment. Each process can link the same shared memory segment into its own address space, allowing all processes to access addresses in the shared memory. If a process writes to the shared memory, the changes immediately affect any other processes that have access to the same shared memory segment.

[0048] The following combination Figure 1 , taking the Android system as an example, the communication principle of shared memory is introduced.

[0049] Figure 1 This is a schematic diagram of the communication principle of shared memory. Figure 1 As shown in the figure, each process A and process B has its own process control block (PCB) and address space, and each has a corresponding page table, which is responsible for mapping the virtual addresses of the processes to physical addresses and is managed by the memory management unit (MMU). Two different virtual addresses are mapped to the same area of ​​physical space through the page table. The area they point to is shared memory.

[0050] When process A and process B map virtual addresses to physical addresses through the page table, there is a common memory area in the physical address, that is, shared memory, which can be seen by process A and process B at the same time. In this way, inter-process communication can be achieved by one process performing a write operation and the other process performing a read operation.

[0051] Shared memory is used for data communication in many scenarios on the Android system. Shared memory methods include anonymous shared memory (ashmem), memfd, and ion. The following uses anonymous shared memory as an example to explain.

[0052] Anonymous shared memory is based on Linux shared memory. It can create virtual files on the temporary file system (tmpfs) and then map them to different processes. It allows multiple processes to operate on the same memory area, and there are no size restrictions other than physical memory limitations. The Java layer requires the use of shared memory files, which encapsulate native code. Nodes in the Java layer that use anonymous shared memory include:

[0053] (1) Open up memory space through shared memory files and obtain file descriptors.

[0054] (2) Pass the file descriptor to other processes.

[0055] (3) Write data to shared memory.

[0056] (4) Read data from shared memory.

[0057] Among them, each shared memory is associated with an FD. The shared memory file can transmit the shared memory FD through the binder mechanism. The shared memory can be shared through the transmission of FD, and the conversion of FD is completed in the binder driver.

[0058] Binder is a unique IPC mechanism of Android. The underlying technical principle of binder is Linux's memory mapping technology, that is, user-mode processes and kernel-mode processes can share the same memory, thus reducing the number of memory read and write operations.

[0059] In the Android system, when multiple processes use shared memory, electronic devices need to pass the shared memory file descriptor to other processes. This process is implemented using the binder mechanism. In addition, when electronic devices use shared memory, they need to transfer control information between processes. This transfer can only be achieved through the binder mechanism in Android.

[0060] Shared memory leaks can occur when using shared memory. For example, shared memory is allocated by process A and should be released by process B. However, due to some reason in process B, such as a code error or forgetting to call the release function, the shared memory remains occupied, resulting in a shared memory leak.

[0061] The processes that apply for and release shared memory may be different. It is impossible to know which processes use the shared memory. It is possible that the shared memory is applied for in process A, used in process B, and released in process C. In this way, it is impossible to locate which process is occupying the shared memory.

[0062] Currently, the industry can determine which processes are sharing the same shared memory by naming the shared memory, such as using anonymous shared memory to call the ashmem_create_region function in libcutils.

[0063] However, not all shared memory can be named. If it cannot be named, it is difficult to locate the process that leaks the shared memory.

[0064] In view of this, an embodiment of the present application provides a method and apparatus for locating a shared memory leak. The method can set an identity tag for each shared memory file descriptor, and the shared memory can be identified by the identity tag. Since file descriptors are passed between processes when using shared memory for communication, the identity tag of the shared memory is also passed between processes. For leaked shared memory, the allocation path of the shared memory can be tracked using the identity tag of the leaked shared memory, and the processes in which the leaked shared memory is shared can be determined. This helps developers locate the process that leaked the shared memory and improves the performance of electronic devices.

[0065] The electronic devices involved in the embodiments of the present application may be electronic devices with an operating system, such as mobile phones, tablet computers, personal computers (PCs), wearable electronic devices such as smart watches, various teaching auxiliary tools (such as learning machines, early education machines), smart toys, portable robots, personal digital assistants (PDAs), augmented reality (AR) devices, virtual reality (VR) devices, etc.

[0066] In order to better understand the embodiments of the present application, the hardware structure of the electronic device of the embodiments of the present application is introduced below. Figure 2 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0067] The electronic device 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, 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, a sensor module 180, a button 190, an indicator 192, a camera 193, and a display screen 194, etc.

[0068] Optionally, the above-mentioned sensor module 180 may include a pressure sensor 180A, a gyroscope sensor 180B, an air pressure sensor 180C, a magnetic sensor 180D, an acceleration sensor 180E, a distance sensor 180F, a proximity light sensor 180G, a fingerprint sensor 180H, a temperature sensor 180J, a touch sensor 180K, an ambient light sensor 180L, a bone conduction sensor 180M, etc.

[0069] It is understood that the structures illustrated in the embodiments of the present application do not constitute specific limitations on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0070] The processor 110 may include one or more processing units. The different processing units may be independent devices or integrated into one or more processors. The processor 110 may also be provided with a memory for storing instructions and data.

[0071] USB port 130 is an interface that complies with USB standards and may be a Mini USB port, a Micro USB port, a USB Type-C port, or the like. USB port 130 can be used to connect a charger to charge an electronic device, transfer data between the electronic device and peripherals, connect headphones to play audio, and connect other electronic devices, such as augmented reality devices.

[0072] The charging management module 140 is used to receive charging input from a charger. The charger can be a wireless charger or a wired charger. The power management module 141 is used to connect the charging management module 140 to the processor 110.

[0073] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor.

[0074] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Antennas in electronic devices can be used to cover single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization.

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

[0076] The wireless communication module 160 can provide wireless communication solutions for electronic devices, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), etc.

[0077] The electronic device implements display functionality through a GPU, display screen 194, and an application processor. The GPU is a microprocessor for image processing that connects the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering.

[0078] The display screen 194 is used to display images, videos, etc. The display screen 194 includes a display panel. In some embodiments, the electronic device may include one or N display screens 194, where N is a positive integer greater than one.

[0079] The electronic device can realize the shooting function through the ISP, camera 193, video codec, GPU, display 194 and application processor.

[0080] The camera 193 is used to capture still images or videos. In some embodiments, the electronic device may include 1 or N cameras 193, where N is a positive integer greater than 1.

[0081] The external memory interface 120 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 110 via the external memory interface 120 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0082] The internal memory 121 can be used to store computer executable program codes, which include instructions. The internal memory 121 can include a program storage area and a data storage area.

[0083] The electronic device can implement audio functions such as music playback and recording through the audio module 170, the speaker 170A, the receiver 170B, the microphone 170C, and the application processor.

[0084] The audio module 170 is used to convert digital audio information into analog audio signal output, and is also used to convert analog audio input into digital audio signals. The speaker 170A, also known as a "speaker", is used to convert audio electrical signals into sound signals. The electronic device can listen to music or listen to hands-free calls through the speaker 170A. The receiver 170B, also known as a "handset", is used to convert audio electrical signals into sound signals. When the electronic device answers a call or voice message, the voice can be heard by placing the receiver 170B close to the human ear. The microphone 170C, also known as a "microphone" or "microphone", is used to convert sound signals into electrical signals.

[0085] The pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, the pressure sensor 180A can be provided on the display screen 194. The gyroscope sensor 180B can be used to determine the motion posture of the electronic device. The air pressure sensor 180C is used to measure air pressure. The magnetic sensor 180D includes a Hall effect sensor. The acceleration sensor 180E can detect the magnitude of the acceleration of the electronic device in various directions (generally three axes). The distance sensor 180F is used to measure distance. The proximity light sensor 180G can include, for example, a light-emitting diode (LED) and a light detector, such as a photodiode. The ambient light sensor 180L is used to sense the brightness of ambient light. The fingerprint sensor 180H is used to collect fingerprints. The temperature sensor 180J is used to detect temperature. The touch sensor 180K, also known as a "touch control device," can be provided on the display screen 194. The touch sensor 180K and the display screen 194 form a touch screen, also known as a "touch screen." The bone conduction sensor 180M can obtain vibration signals.

[0086] Keys 190 include a power button, volume button, and other buttons. Keys 190 can be mechanical or touch-sensitive. The electronic device can receive key inputs and generate key signal inputs related to user settings and function control of the electronic device. Indicator 192 can be an indicator light that can be used to indicate charging status, battery level changes, messages, missed calls, notifications, and the like.

[0087] The software system of the electronic device can adopt a layered architecture, an event-driven architecture, a micro-kernel architecture, a microservice architecture, or a cloud architecture. The layered architecture can adopt the Android system, the iOS system, or other operating systems, which are not limited in the embodiments of the present application.

[0088] The following uses the layered architecture of the Android system as an example to illustrate the software structure of an electronic device.

[0089] Figure 3 This is a software structure diagram of an electronic device to which embodiments of the present application are applicable. A layered architecture divides the software system of an electronic device into several layers, each with clear roles and division of labor. Layers communicate with each other through software interfaces. In some embodiments, the Android system can be divided into four layers: the application layer, the application framework layer, the Android runtime and system libraries, and the kernel layer.

[0090] The application layer can include a series of application packages, and the application layer runs applications by calling the application programming interface (API) provided by the application framework layer. Figure 3 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, Bluetooth, music, video, short message, etc.

[0091] The application framework layer provides API and programming framework for the applications in the application layer. The application framework layer includes some predefined functions. Figure 3 As shown, the application framework layer may include a window manager, a content provider, a view system, a phone manager, a resource manager, a notification manager, and the like.

[0092] The window manager manages windowed applications. It can determine the display size, determine whether a status bar is present, lock the screen, and take screenshots. Content providers store and retrieve data and make it accessible to applications. This data can include video, images, audio, incoming and outgoing calls, browsing history and bookmarks, and the phone book. The view system includes visual controls, such as those for displaying text and images. The view system is used to build applications. A display interface can consist of one or more views. For example, a display interface containing a text notification icon might include a view for displaying text and a view for displaying images. The phone manager provides communication functions for electronic devices, such as managing call states (including connected and ended calls). The resource manager provides applications with various resources, such as localized strings, icons, images, layout files, and video files. The notification manager enables applications to display notifications in the status bar. These messages can be displayed briefly and then disappear automatically, without requiring user interaction. For example, the notification manager is used to notify users of download completions and message reminders. The notification manager can also be a notification that appears in the system's top status bar in the form of an icon or scrolling text bar, such as a notification from an application running in the background, or a notification that appears on the screen in the form of a dialog window. For example, a text message may be displayed in the status bar, a notification sound may be emitted, an electronic device may vibrate, an indicator light may flash, etc.

[0093] The Android system runtime consists of core libraries and a virtual machine. The Android system runtime is responsible for scheduling and management of the Android system. The core library consists of two parts: one for the functional functions required by the Java language, and the other for the Android core library. The application layer and the application framework layer run in the virtual machine. The virtual machine executes the Java files in the application layer and application framework layer as binary files. The virtual machine is responsible for performing functions such as object lifecycle management, stack management, thread management, security and exception management, and garbage collection. The system library, also known as a native service, can include libraries written in C or C++ and can be used by different components in the Android system. The system library can also provide services to developers through the application framework layer. The system library can include modules with multiple functions, such as the surface manager, shared memory leak detection module, shared memory leak location module, file descriptor tracking (fdtrack) module, and function export module.

[0094] Optionally, the system library may further include an output module, also referred to as a dump module, for outputting call stack information of a file descriptor.

[0095] The surface manager manages the display subsystem and provides fusion of 2D and 3D layers for multiple applications. The shared memory leak detection module detects shared memory leaks. The shared memory leak location module locates the process causing the leak if the shared memory leak detection module detects one. The file descriptor tracking (fdtrack) module records call stack information for file descriptors. The function export module exports the _android_fdtrack_hook function for other libraries to call.

[0096] Optionally, the shared memory leak location module may include multiple modules, such as an associated process acquisition module and a log acquisition module. The associated process acquisition module is used to acquire processes that use the same shared memory as the current process. A process that uses the same shared memory as the current process can be referred to as an associated process of the current process. The log acquisition module is used to acquire file descriptor tracking (fdtrack) logs of the associated process.

[0097] The kernel layer is the layer between hardware and software. It drives the hardware, enabling it to operate. The kernel layer includes at least camera drivers and sensor drivers, though this is not a limitation in the present embodiment. The kernel layer also serves as an abstraction layer between the hardware and software stacks and can include multiple library modules. These library modules can include file descriptor identification modules, which record the identification tags of the file descriptors corresponding to each process.

[0098] For example, for the libion ​​library, the identity tag of the file descriptor transferred between processes can be obtained from the kernel layer by calling the FDTRACK_CREATE function through ion_map, ion_share, and ion_alloc_fd.

[0099] The shared memory leak location module mentioned above may also be called a hiview module, the file descriptor tracking module may also be called a libion / libbinder / libhwbinder module, and the function export module may also be called a libc module.

[0100] It should be understood that the above Figure 3 The names of the modules are merely examples given for the convenience of introduction in the embodiments of the present application, and the embodiments of the present application do not limit the names of these modules.

[0101] Figure 4 400 is a schematic flow chart of a method 400 for locating a shared memory leak provided by an embodiment of the present application. The method 400 can be applied to an electronic device, and the hardware structure diagram of the electronic device can be as follows: Figure 2 As shown, the software structure diagram of the electronic device can be as follows Figure 3As shown, but this embodiment of the present application is not limited to this. Method 400 includes the following steps:

[0102] S401: Set an identity tag for at least one shared memory file descriptor.

[0103] Each shared memory is associated with a file descriptor, and an identity tag is set for each file descriptor. The shared memory can be identified by the identity tag, and the identity tag is passed between processes along with the file descriptor.

[0104] S402: When a first shared memory leak is detected in the at least one shared memory, determine a first process currently using the first shared memory.

[0105] The electronic device can detect whether there is a shared memory leak through the shared memory leak detection module.

[0106] S403: Determine a second process based on the identity tag of the file descriptor of the first shared memory, where the identity tag of the file descriptor of the first process corresponding to the first shared memory is the same as the identity tag of the file descriptor of the second process corresponding to the first shared memory.

[0107] Exemplarily, the number of the second process is at least one.

[0108] It should be understood that the first process can apply for multiple shared memories and communicate with multiple processes. Each time a process applies for shared memory, it generates a file descriptor corresponding to the requested shared memory. When the processes communicate using shared memory, the file descriptor's identity tag is passed between the processes by passing the file descriptor. The electronic device can use the file descriptor file to record which processes each process uses the shared memory with, and use the shared memory leak locating module to identify the second process from the kernel-level file descriptor file.

[0109] In the embodiment of the present application, the second process may be described as an associated process of the first process.

[0110] S404: Acquire and display call stack information of the second process corresponding to the file descriptor of the first shared memory, where the call stack information includes information on applying for and / or releasing the first shared memory.

[0111] In an embodiment of the present application, the electronic device can set an identity tag for each shared memory file descriptor. When a shared memory leak is detected, the electronic device can determine the second process based on the file corresponding to the file descriptor of the first shared memory by the first process, that is, the first process and the second process are in the shared memory. The call stack information includes information on applying for and / or releasing the first shared memory. The backend developer can locate the specific code position of the first shared memory leak through the call stack information of the second process applying for and / or releasing the first shared memory. This is conducive to timely locating the shared memory leak problem of the electronic device and improving the performance of the electronic device.

[0112] For example, the first process may correspond to multiple file descriptors. Because some shared memories are applied for but not released, resulting in shared memory leaks, the first process may correspond to a large number of file descriptors for the multiple shared memories. If the shared memories applied for by the first process are released, the number of file descriptors for the first process will also decrease.

[0113] For example, a first process with a process ID of 1354 may share memory with second processes with process IDs of 1589, 2842, 2856, and 3058. The shared memory leak location module may obtain process information of the second processes with process IDs of 1589, 2842, 2856, and 3058, where the process information of the second processes may include file descriptors of the second processes.

[0114] Optionally, the process information of the second process may further include at least one of a process ID of the second process, a name of the second process, or a name of a file descriptor of the second process.

[0115] As an optional embodiment, before S404, method 400 further includes: recording call stack information during the transfer of the file descriptor of the first shared memory between the first process and the second process, and storing the call stack information of the file descriptor of the first shared memory in the memory. S404 includes: obtaining and displaying the call stack information of the second process corresponding to the file descriptor of the first shared memory from the memory.

[0116] In an embodiment of the present application, the electronic device can record the call stack information of the file descriptor of the first shared memory during the transfer between the first process and the second process through the above-mentioned file descriptor tracking module. When a leak of the first shared memory is detected, the electronic device can output the call stack information of the second process corresponding to the file descriptor of the first shared memory.

[0117] For example, the process number of the second process is 1589, and the file descriptor of the second process with process number 1589 is 8. The electronic device can obtain the file descriptor tracking (fdtrack) log with file descriptor 8 through the log acquisition module. The file descriptor tracking log includes the call stack information of the file descriptor.

[0118] For example, backend developers can decompile the call stack information of the file descriptor to locate in which process the shared memory is applied. The shared memory leak may be caused by forgetting to call the release function in the process that applied for the shared memory.

[0119] As an optional embodiment, S403 includes: traversing the file descriptors of all processes corresponding to the first shared memory, obtaining, through the kernel, identity tags of the file descriptors of all processes corresponding to the first shared memory, and determining the second process based on the identity tag of the file descriptor of the first process corresponding to the first shared memory among all the processes.

[0120] In an embodiment of the present application, the electronic device may provide the identity tag information of the file descriptor through the file descriptor identity tag module of the kernel layer, and determine the second process according to the identity tag of the file descriptor.

[0121] Exemplarily, the electronic device may cyclically use the kcmp system call to determine whether two file descriptors are associated with the same open file table (open file table), which may also be called an open file description table (open file description, OFD).

[0122] Figure 5 This is a schematic diagram of the relationship between a file descriptor and an open file table provided in an embodiment of the present application. Figure 5 The three core data structures of the file descriptor are shown: the file descriptor table (FD table), the system-wide open file table, and the system-wide index node table (i-node table).

[0123] The file descriptor table may include a file descriptor flag and a file pointer. The open file table may include a file offset, a status indication, and an index node pointer. The index node table may include a file type and a file lock.

[0124] like Figure 5As shown, both process A and process B have a file descriptor table, and the outer FD is an index into the file descriptor table. Each entry in the file descriptor table contains a pointer to the open file table. The open file table also has a pointer to the inode table. The number outside the open file table indicates the index into the inode table. Each entry in the inode table indicates a file type, and the number outside the inode table indicates the index into the inode table.

[0125] Multiple file descriptors of the same process can be associated with the same open file table. For example, file descriptor 1 of process A and file descriptor 20 of process A can point to open file table 23, for example, by duplicating the file descriptors using dup or dup2. Open file table 23 then points to inode table 224.

[0126] The file descriptors of different processes can be associated with the same open file table. For example, the file descriptor 2 of process A and the file descriptor 2 of process B point to the open file table 73, and the open file table 73 points to the index node table 5139.

[0127] File descriptors of different processes can be associated with different open file tables. For example, file descriptor 0 of process A points to open file table 0, and file descriptor 3 of process B points to open file table 86. File descriptor 0 of process A and file descriptor 3 of process B point to different open file tables, but different open file tables can point to the same inode table. For example, open file table 0 and open file table 086 point to inode table 1976.

[0128] The electronic device can indicate the identity tag of the shared memory through the pointer corresponding to the file descriptor, and record the identity tag of the file descriptor of process A and the identity tag of the file descriptor of process B in the open file table. If the shared memory leak detection module detects a shared memory leak, the electronic device obtains the corresponding shared information log through the shared memory leak location module, that is, obtains process information of the second process that shares memory with the first process.

[0129] As an optional embodiment, before S404, method 400 further includes: determining whether a function for obtaining call stack information is enabled. If the function for obtaining call stack information is enabled, obtaining and displaying call stack information of the second process corresponding to the file descriptor of the first shared memory.

[0130] In an embodiment of the present application, exemplarily, the function for obtaining call stack information is the fdtrack function. In order to ensure that the ongoing process is not terminated, it is necessary to determine whether the fdtrack function is turned on before obtaining the call stack information of the file descriptor, for example, the electronic device scans whether the libfdtrack library exists. If the libfdtrack library exists, the electronic device can send an acquisition signal to the user state process (such as the first process mentioned above) through the shared memory leak locating module, and the user state process responds to the acquisition information and obtains the call stack information recorded during the file descriptor transmission process from the memory through the function export module.

[0131] For example, sending the acquisition signal may be calling a kill signal. If the libfdtrack library does not exist in the system, then the shared memory leak location module calling the kill signal may cause the user mode process to exit. Therefore, the embodiment of the present application is conducive to improving the fault tolerance of the system.

[0132] Figure 6 600 is a schematic flow chart of another shared memory leak location method provided by an embodiment of the present application. The method 600 can be applied to an electronic device, and the hardware structure diagram of the electronic device can be as follows: Figure 2 As shown, the software structure diagram of the electronic device can be as follows Figure 3 As shown, but this embodiment of the present application is not limited to this. Method 600 includes the following steps:

[0133] S601: The file descriptor identity tag module records the identity tag of the file descriptor.

[0134] The file descriptor identity tag module can set an identity tag for the file descriptor when generating the file descriptor, and indicate the identity tag through the file descriptor pointing to the open file table pointer. The file descriptor identity tag module records the identity tag of the file descriptor through the open file table.

[0135] For example, the file descriptor may be generated by opening or creating a subroutine of the electronic device, or by inheriting from a parent process.

[0136] Exemplarily, the identity tag may be represented by a hash value.

[0137] S602: The function export module calls a newly added application programming interface (API) to export a first interface.

[0138] For example, the first interface may be an Android native interface for tracking file descriptors. Exporting the first interface may be achieved by exporting the _android_fdtrack_hook function.

[0139] S603: The function export module sends the first interface to the file descriptor tracking module. Correspondingly, the file descriptor tracking module receives the first interface.

[0140] S604: The file descriptor tracking module tracks and records the call stack information of the file descriptor based on the first interface.

[0141] S605: The shared memory leak detection module detects whether there is a shared memory leak. If a shared memory leak is detected, S606 is executed.

[0142] S606: The shared memory leak detection module sends indication information to the associated process acquisition module, where the indication information is used to indicate that a shared memory leak has occurred. Correspondingly, the associated process acquisition module receives the indication information.

[0143] S607: Based on the indication information, the associated process acquisition module sends a request to the file descriptor identity tag module to obtain the associated process information. Correspondingly, the file descriptor identity tag module receives the request to obtain the associated process information.

[0144] S608: The file descriptor identification module sends the process information of the associated process to the associated process acquisition module. Correspondingly, the associated process acquisition module receives the process information of the associated process.

[0145] Taking the shared memory where the shared memory leak occurs as the first shared memory, the process currently using the first shared memory as the first process, and the associated process of the first process as the second process as an example, the file descriptor identity marking module can determine the second process that shares the first shared memory with the first process through the identity marking of the recorded file descriptor.

[0146] The process information of the associated process may include a file descriptor of the associated process.

[0147] Optionally, the process information of the associated process may further include at least one of a process number of the associated process, a name of the associated process, or a name of a file descriptor of the associated process.

[0148] S609: The associated process acquisition module sends the process information of the associated process to the log acquisition module. Correspondingly, the log acquisition module receives the process information of the associated process.

[0149] S610: The log acquisition module sends a request to the file descriptor tracking module for obtaining call stack information of the file descriptor. Correspondingly, the file descriptor tracking module receives the request for obtaining call stack information of the file descriptor.

[0150] S611, the file descriptor tracking module calls the output function to output and display the call stack information of the file descriptor.

[0151] Exemplarily, the output function may be a dump function.

[0152] In the method for locating a shared memory leak provided in an embodiment of the present application, the electronic device can set an identity tag for the file descriptor of the shared memory and transmit the identity tag during the process of transmitting the file descriptor between processes. During the file descriptor transmission process, the electronic device can record the identity tag of the shared memory, and track the file descriptor through an external interface and record the call stack information of the file descriptor. In the case of detecting a shared memory leak, the electronic device can locate the associated process in the shared memory with the current process based on the identity tag of the shared memory used by the process, and display the call stack information of the associated process for the developer to locate the code location for the application and / or release of the shared memory, which is beneficial to improving the performance of the electronic device.

[0153] The order of execution of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application.

[0154] Combined with the above Figures 1 to 6 , describes in detail the method for locating shared memory leaks according to an embodiment of the present application, and will now be combined with Figure 7 and Figure 8 A device for locating a shared memory leak according to an embodiment of the present application is described in detail.

[0155] Figure 7 A schematic block diagram of a shared memory leak location device 700 provided in an embodiment of the present application is shown. The device 700 includes a processing module 710 and an acquisition module 720 .

[0156] The processing module 710 is configured to: set an identity tag for at least one shared memory file descriptor; upon detecting a first shared memory leak in at least one shared memory, determine a first process currently using the first shared memory; and, based on the identity tag of the file descriptor of the first shared memory, determine a second process, where the identity tag of the file descriptor of the first process corresponding to the first shared memory is the same as the identity tag of the file descriptor of the second process corresponding to the first shared memory. The acquisition module 720 is configured to: acquire and display call stack information of the file descriptor of the second process corresponding to the first shared memory, where the call stack information includes information on allocating and / or releasing the first shared memory.

[0157] Optionally, the processing module 710 is configured to record call stack information of the file descriptor of the first shared memory during transfer between the first process and the second process, and store the call stack information of the file descriptor of the first shared memory in the memory. The acquiring module 720 is configured to acquire and display the call stack information of the file descriptor of the second process corresponding to the first shared memory from the memory.

[0158] Optionally, the processing module 710 is used to: indicate the identity tag of the at least one shared memory file descriptor through a pointer of the at least one shared memory file descriptor pointing to the open file table; and record the identity tag of the at least one shared memory file descriptor through the open file table.

[0159] Optionally, the processing module 710 is used to: traverse the file descriptors of all processes corresponding to the first shared memory, and obtain the identity tags of the file descriptors of all processes corresponding to the first shared memory by opening the file table; and determine the second process based on the identity identifier of the file descriptor of the first process corresponding to the first shared memory among all processes.

[0160] Optionally, the processing module 710 is configured to determine whether a function for obtaining call stack information is enabled. The obtaining module 720 is configured to obtain and display the call stack information of the second process corresponding to the file descriptor of the first shared memory if the function for obtaining call stack information is enabled.

[0161] In an optional example, those skilled in the art will appreciate that the apparatus 700 may be specifically the electronic device in the above-mentioned embodiments, or the functions of the electronic device in the above-mentioned embodiments may be integrated into the apparatus 700. The above-mentioned functions may be implemented by hardware, or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-mentioned functions. The apparatus 700 may be used to execute the various processes and / or steps corresponding to the electronic device in the above-mentioned method embodiments.

[0162] It should be understood that the apparatus 700 herein is embodied in the form of a functional module. The term "module" herein may refer to an application specific integrated circuit (ASIC), an electronic circuit, a processor (e.g., a shared processor, a dedicated processor, or a group processor, etc.) and memory for executing one or more software or firmware programs, a combined logic circuit, and / or other suitable components that support the described functions. In the embodiments of the present application, Figure 7 The device 700 may also be a chip or a chip system, such as a system on chip (SoC).

[0163] Figure 8 A schematic block diagram of another shared memory leak location device 800 provided in an embodiment of the present application is shown. The device 800 includes a processor 810, a transceiver 820, and a memory 830. The processor 810, the transceiver 820, and the memory 830 communicate with each other via an internal connection path. The memory 830 is used to store instructions, and the processor 810 is used to execute the instructions stored in the memory 830 to control the transceiver 820 to send and / or receive signals.

[0164] It should be understood that the device 800 can be specifically the electronic device in the above-mentioned embodiment, or the functions of the electronic device in the above-mentioned embodiment can be integrated into the device 800, and the device 800 can be used to execute the various steps and / or processes corresponding to the electronic device in the above-mentioned method embodiment. Optionally, the memory 830 may include a read-only memory and a random access memory, and provide instructions and data to the processor. A portion of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type. The processor 810 can be used to execute instructions stored in the memory, and when the processor executes the instruction, the processor can execute the various steps and / or processes corresponding to the electronic device in the above-mentioned method embodiment.

[0165] It should be understood that in the embodiment of the present application, the processor 810 may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0166] Those skilled in the art will appreciate that the modules and algorithm steps of each example 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 performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel 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.

[0167] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and modules described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0168] 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 schematic. For example, the division of the modules is merely a logical function division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or modules, which can be electrical, mechanical or other forms.

[0169] The modules described as separate components may or may not be physically separate, and the components shown as modules may or may not be physical modules, that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules may be selected to achieve the purpose of the present embodiment according to actual needs.

[0170] In addition, each functional module in each embodiment of the present application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0171] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment 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.

[0172] The above description is merely a specific embodiment of the present application, but the scope of protection of the embodiments of the present application is not limited thereto. Any person skilled in the art can easily conceive of changes or substitutions within the technical scope disclosed in the embodiments of the present application, and such changes or substitutions should be included in the scope of protection of the embodiments of the present application. Therefore, the scope of protection of the embodiments of the present application should be based on the scope of protection of the claims.

Claims

1. A method for locating a shared memory leak, characterized in that: include: Set the identity flag on at least one shared memory file descriptor; In a case where a first shared memory leak is detected in the at least one shared memory, determining a first process currently using the first shared memory; determining a second process based on an identity tag of a file descriptor of the first shared memory, wherein the identity tag of the file descriptor of the first shared memory corresponding to the first process is the same as the identity tag of the file descriptor of the second process corresponding to the first shared memory; Acquire and display call stack information of the second process corresponding to the file descriptor of the first shared memory, where the call stack information includes information on applying for and / or releasing the first shared memory.

2. The method according to claim 1, characterized in that Before acquiring and displaying call stack information of the second process corresponding to the file descriptor of the first shared memory, the method further includes: Recording call stack information of the file descriptor of the first shared memory during a transfer between the first process and the second process, and storing the call stack information of the file descriptor of the first shared memory in a memory; The acquiring and displaying call stack information of the second process corresponding to the file descriptor of the first shared memory includes: Acquire and display call stack information of the second process corresponding to the file descriptor of the first shared memory from the memory.

3. The method according to claim 1 or 2, characterized in that After setting the identity tag for the file descriptor of at least one shared memory, the method further includes: Indicating an identity tag of the file descriptor of the at least one shared memory by a pointer of the file descriptor of the at least one shared memory to the open file table; The identity tag of the file descriptor of the at least one shared memory is recorded in the open file table.

4. The method according to claim 3, characterized in that The determining of the second process based on the identity tag of the file descriptor of the first shared memory includes: Traversing the file descriptors of all processes corresponding to the first shared memory, and obtaining identity tags of the file descriptors of all processes corresponding to the first shared memory through the open file table; The second process is determined according to an identity identifier of a file descriptor of the first process corresponding to the first shared memory among all the processes.

5. The method according to any one of claims 1 to 2 and 4, characterized in that: Before acquiring and displaying call stack information of the second process corresponding to the file descriptor of the first shared memory, the method further includes: Determine whether the function for obtaining the call stack information is enabled; The acquiring and displaying call stack information of the second process corresponding to the file descriptor of the first shared memory includes: When the function of obtaining the call stack information is enabled, the call stack information of the second process corresponding to the file descriptor of the first shared memory is obtained and displayed.

6. A shared memory leak location device, characterized in that: include: A processing module, configured to set an identity tag for at least one file descriptor of a shared memory; The processing module is further configured to: upon detecting a first shared memory leak in the at least one shared memory, determine a first process currently using the first shared memory; The processing module is further configured to: determine a second process based on an identity tag of a file descriptor of the first shared memory, wherein the identity tag of the file descriptor of the first shared memory corresponding to the first process is the same as the identity tag of the file descriptor of the second process corresponding to the first shared memory; An acquisition module is used to acquire and display call stack information of the second process corresponding to the file descriptor of the first shared memory, where the call stack information includes information on applying for and / or releasing the first shared memory.

7. The device according to claim 6, characterized in that The processing module is used for: Recording call stack information of the file descriptor of the first shared memory during a transfer between the first process and the second process, and storing the call stack information of the file descriptor of the first shared memory in a memory; The acquisition module is used to acquire and display call stack information of the second process corresponding to the file descriptor of the first shared memory, where the call stack information includes information on applying for and / or releasing the first shared memory.

8. The device according to claim 6 or 7, characterized in that The processing module is used for: Indicating an identity tag of the file descriptor of the at least one shared memory by a pointer of the file descriptor of the at least one shared memory to the open file table; The identity tag of the file descriptor of the at least one shared memory is recorded in the open file table.

9. The device according to claim 8, characterized in that The processing module is used for: Traversing the file descriptors of all processes corresponding to the first shared memory, and obtaining identity tags of the file descriptors of all processes corresponding to the first shared memory through the open file table; The second process is determined according to an identity identifier of a file descriptor of the first process corresponding to the first shared memory among all the processes.

10. The device according to any one of claims 6 to 7 and 9, characterized in that: The processing module is used for: Determine whether the function for obtaining the call stack information is enabled; The acquisition module is used to: when the function of acquiring the call stack information is enabled, acquire and display the call stack information of the second process corresponding to the file descriptor of the first shared memory.

11. A shared memory leak location device, characterized in that: include: A processor, wherein the processor is coupled to a memory, wherein the memory is used to store a computer program, and when the processor calls the computer program, the device is caused to execute the method according to any one of claims 1 to 5.

12. A computer-readable storage medium, characterized in that Used to store a computer program, the computer program comprising instructions for implementing the method according to any one of claims 1 to 5.

13. A computer program product, characterized in that The computer program product includes computer program code, and when the computer program code is run on a computer, the computer is enabled to implement the method according to any one of claims 1 to 5.

Images