Method for native memory monitoring in android platform

Abstract

The application provides a Native memory monitoring method in an Android platform, characterized by the following steps: obtaining an ELF base address; obtaining relocation information of the ELF; and using a hook function to take over the ELF calling a memory allocation function. The application also provides a second Native memory monitoring method in an Android platform, characterized by the following steps: creating a function array, wherein each element in the function array is a hook function; obtaining a plurality of ELF base addresses; obtaining relocation information of each ELF; and using elements in the function array to take over each ELF calling a memory allocation function, respectively.

Description

Technical Field

[0001] This invention provides a memory monitoring method, and more particularly relates to a native memory monitoring method in the Android platform. Background Technology

[0002] Android app memory consists of two parts: Java heap memory and native memory. The allocation and deallocation of Java objects occur in the Java heap memory, which is managed by the JVM garbage collector, and memory leaks are not a significant issue here. However, native memory is allocated by programmers using C / C++ functions like malloc. This memory is not in the heap and therefore is not released by the Java garbage collector, making memory leaks in this part more problematic.

[0003] To resolve native memory leaks, it's necessary to monitor native memory allocation to track memory usage and pinpoint the cause of the leak. Currently, there's a lack of efficient and convenient tools for native memory monitoring. The only available tool, malloc debug, falls short in terms of performance and stability, and also suffers from poor version compatibility. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide a Native memory monitoring method in the Android platform, characterized by including: the step of obtaining the ELF base address; the step of obtaining the relocation information of the ELF; and the step of using a hook function to take over the ELF's call to the memory allocation function.

[0005] Preferably, in the Native memory monitoring method of the above Android platform, the ELF base address is obtained by calling dl_iterate_phdr.

[0006] Preferably, in the Native memory monitoring method of the above Android platform, the address corresponding to the record with offset of 0 is used as the base address of the ELF by parsing the / proc / self / maps file.

[0007] Preferably, in the Native memory monitoring method of the Android platform described above, the relocation information includes information in .got, .plt, .rel.plt, and .rel.dyn.

[0008] Preferably, in the Native memory monitoring method of the above Android platform, the step of taking over the call with a hook function includes: modifying the memory attribute where the relocation information is located to writable; and assigning the memory where the relocation information is located to the address of the hook function.

[0009] Preferably, in the Native memory monitoring method of the Android platform described above, the step of taking over the call with a hook function further includes: resetting the memory attributes where the relocation information is located.

[0010] The present invention also provides a second method for monitoring native memory in an Android platform, comprising: a step of creating a function array, wherein each element in the function array is a hook function; a step of obtaining multiple ELF base addresses; a step of obtaining relocation information for each ELF; and a step of using the elements in the function array to take over the memory allocation function calls of each ELF respectively.

[0011] Preferably, in the Native memory monitoring method of the Android platform described above, each hook function in the function array outputs the ELF memory call status to a CSV file every preset time T.

[0012] Preferably, in the Native memory monitoring method of the above Android platform, the address corresponding to the record with offset of 0 is used as the base address of the ELF by parsing the / proc / self / maps file. Attached Figure Description

[0013] Figure 1 This is a flowchart of the Native memory monitoring method of the present invention;

[0014] Figure 2 This is a diagram showing the contents of the / proc / self / maps file. Detailed Implementation

[0015] The following specific examples illustrate the implementation of the present invention. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention.

[0016] The core idea of ​​this invention is to use hooks to intercept applications' calls to native memory allocation functions. This allows for the recording and monitoring of memory usage during these calls, identifying how much memory each dynamic library allocates and which memory segments are continuously occupied and not released. Traditional hooks require root privileges to intercept other applications' calls to functions like malloc, calloc, realloc, and free. Granting root privileges to ordinary applications simply to monitor for content leaks is not only uneconomical but also often impractical.

[0017] In the Android platform, after C / C++ source code is compiled and linked, the resulting dynamic link libraries or executable files are in ELF (Executable and Linkable Format) format. ELF is an industry-standard binary data encapsulation format. ELF is loaded into memory by the dynamic linker provided by the operating system. Loading occurs on a segment-by-segment basis. A segment contains one or more sections, among which the ".dynamic section" is a very important and special section. It contains information such as the memory locations of the other sections in the ELF. When the dynamic linker loads a dynamic link library or executable file, it needs to first locate the memory location of the .dynamic section before further reading the information of the other sections.

[0018] The general steps for loading are:

[0019] (1). Read the PHT (program header table) of the ELF and use mmap to map all segments of type PT_LOAD into memory in sequence;

[0020] (2). Read the information items from the .dynamic segment, mainly the relative virtual memory addresses of each section, and then calculate and save the absolute virtual memory addresses of each section;

[0021] (3) Perform a relocation operation. The relocation information may exist in one or more of the following sections: .rel.plt, .rela.plt, .rel.dyn, .rela.dyn, .rel.android, .rela.android. The dynamic linker needs to process the relocation requests in these .relxxx sections one by one.

[0022] Based on the characteristics and operating mechanism of ELF files, this invention proposes a method that, without root privileges, uses hook functions to intercept application calls to malloc / realloc / calloc / free, thereby monitoring the application's use of native memory. See the detailed process below. Figure 1 ,include:

[0023] S1: Steps to obtain the ELF base address. In a process's memory space, the memory address to which various ELFs are loaded is random. The actual load address, or base address, is only obtained at runtime. After the aforementioned loading and relocation are completed, the ELF's base address is determined. When a target function (in this example, malloc / realloc / calloc / free) is called, it's not the original function address that's invoked. Instead, it first goes through the Procedure Link Table (PLT) and jumps to the Global Offset Table (GOT) to obtain the target function's global offset. At this point, the actual target function address can be located using the base address + offset. One way to obtain the base address is to call the system-provided dl_iterate_phdr function, which can query information about loaded dynamic libraries, including their base addresses.

[0024] However, some Android versions do not support dl_iterate_phdr. The base address can be obtained by parsing the / proc / self / maps file. The maps file returns the mmap mapping information in the memory space of the specified process, including various dynamic libraries, executable files (such as the linker), stack space, and heap space. The contents of the maps file are as follows: Figure 2 As shown, each process typically has 3 records in the maps file, and the address of the record with an offset of 0 can be used as the base address of the process. Figure 2 In the example, the base address of the process libc is b6e42000-b6eb5000.

[0025] S2: Steps to obtain relocation information. The relocation information in the ELF can be found based on the base address. As mentioned earlier, when the dynamic linker performs relocation operations, it handles the relocation requests in the .relxxx sections. If the content in these .relxxx sections is replaced with a specified function, then when the ELF is called, the specified function will actually be called. If a hook function is specified, then the hook function will take over the ELF's invocation.

[0026] In this example, the relocation information needed includes information from the following sections: .got, .plt, .rel.plt, and .rel.dyn. The hook functions can be designed custom-made. One example is to output a memory snapshot to a log file every time interval T, allowing developers to monitor the native memory usage of the target ELF from the log file and determine if any leaks exist.

[0027] S3: Steps to take over the call using a hook function. The intuitive way to take over ELF calls using a hook function is to directly modify the relocation information into a hook function. However, the memory segment corresponding to this relocation information may be write-protected, and directly assigning a value to this memory segment will cause an error. One solution is to first use the system-provided `mprotect()` function to modify the memory segment's attributes to writable, and then assign a value to that memory segment (i.e., perform the hook operation).

[0028] Considering that the section type of .got and .data is PROGBITS, which is executable code, the processor may cache this part of the data. In order to eliminate the impact of caching, after the aforementioned memory modification is completed, a processor instruction cache clearing operation is performed to allow the processor to read the instructions from memory again.

[0029] More preferably, after the memory modification is completed, the memory attributes are reset, that is, the memory attributes are changed back to the read / write attributes before step S3, so as to avoid affecting the system or other applications.

[0030] The above describes a method for monitoring native memory allocation behavior within an application. However, in practice, the native memory area is shared by multiple applications, each of which may call native memory allocation functions, or the application may be multi-process concurrent. Therefore, the above method alone cannot effectively prevent memory leaks.

[0031] An improved approach is to create an array of hook functions called `hookstub`, where each element stores the address of a hook function. The starting address of the array is relatively easy to obtain, and the addresses of each element are contiguous. Therefore, by obtaining the starting address, the address of each hook function in the array can be easily calculated. In this way, each element in the array can be used to manage a memory allocation function, and the entire array can manage multiple memory allocation behaviors across multiple applications or within a single application, achieving more comprehensive monitoring.

[0032] More preferably, each element in the hookstub array (i.e., each hook function) is set to output the process ID of the process it is taking over, along with the memory usage of that process, to a CSV file. This utilizes the structured data in the CSV file, making it easier to automate the processing of log information and quickly locate problems.

[0033] Unless otherwise specified, the "device" and "module" mentioned in the cache cleanup device of this invention refer to logical functional components, which can be implemented in hardware or software in practice. The subordinate relationships and connecting lines of the modules in the attached drawings only represent the logical connections between the modules and do not constitute a limitation on research and development, especially not a limitation on development methods such as class inheritance and module division in software development. Using the native memory monitoring method of this invention, implementation is simple, and the content and format of the monitoring output logs can be flexibly customized according to needs, thereby effectively discovering the causes of memory leaks, and therefore has high application value.

Claims

1. A method for monitoring native memory on the Android platform, characterized in that, include: The steps to obtain the ELF base address include: parsing the / proc / self / maps file and taking the address corresponding to the record with an offset of 0 as the base address of the ELF; The step of obtaining the relocation information of the ELF, wherein the relocation information includes information in .got, .plt, .rel.plt and .rel.dyn; The steps of using a hook function to take over the ELF call to the memory allocation function include: modifying the memory attribute of the relocation information to writable; and assigning the memory of the relocation information to the address of the hook function.

2. The Native memory monitoring method in the Android platform according to claim 1, characterized in that, The ELF base address is obtained by calling dl_iterate_phdr.

3. The Native memory monitoring method in the Android platform according to claim 2, characterized in that, The step of taking over the call using a hook function also includes: resetting the memory attributes where the relocation information is located.

4. A method for monitoring native memory on the Android platform, characterized in that... include: The steps to create an array of functions, where each element in the array is a hook function; The steps to obtain multiple ELF base addresses include: parsing the / proc / self / maps file and taking the address corresponding to the record with offset 0 as the base address of the ELF; The step of obtaining relocation information for each of the ELFs, wherein the relocation information includes information in .got, .plt, .rel.plt, and .rel.dyn; The steps of using the elements in the function array to take over the memory allocation function call of each ELF include: modifying the memory attribute of the relocation information to writable; and assigning the memory of the relocation information to the address of an element in the function array.

5. The Native memory monitoring method in the Android platform according to claim 4, characterized in that, Each hook function in the function array outputs the ELF memory call information to a CSV file every preset time interval T.

Images