Android memory leak issue "go"

This article was reproduced from: http://www.voidcn.com/article/p-hbnuyfwz-ee.html

Memory leak issues are easily exposed in some stress-test scenarios, such as repetitive operations (eg: repeatedly switching the camera back and forth, repeatedly exiting the camera application, and pressure taking pictures, etc.).

Memory leaks typically behave as:

① memory allocation is released, causing the virtual address of the process space to be allocated or the physical address to be allocated.

The ② file is compromised, causing the maximum number of process space file handles to be reached.

③ threads are compromised, causing the virtual address of the process space to be allocated, leaving many line stacks (stacks) in the process.

Most of the leaks in the Android native layer are in the HAL layer, and the main cause is some asymmetric operations.

1. Tools

This layer primarily uses tools for Linux and some file node states.

List of commands:

PS [-t] [pid] [| BusyBox wc-l] Top [-t] LL/PROC/PID/FD [|busybox Wc-l] Cat/proc/pid/maps [|busybox Wc-l] Cat/proc/meminfo [| grep "Memfree"] Dumpsys Meminfo [PID] [package name] Procrank Valgrind Valgrind

2. Ps/top command

Ps/top can monitor and control processes in Linux systems. Ps is the status of the instantaneous process, and top is the monitoring of the process run time.

Ps/top command to find the target process number PID, and then according to the PID to observe the repeated operation of the two ps/top printing items:

Vsize (VSS): The size of virtual memory consumed.

RSS: Takes up the size of memory.

Confirm that the existence of the memory leak problem can be preliminarily confirmed by whether the two items have been increased indefinitely.

PS-T PID This command lists the threads of the current process, including the native thread and the Java thread.

Native threads can view their thread names, such as:

USER PID PPID vsize RSS Wchan PC NAME Media 1574 1465 50312 9992 c0089920 b6ea491c scameracaptureth

Java threads can only see the map names of Java threads at the native layer

USER PID PPID vsize RSS Wchan PC NAME U0_a22 6884 2562 984204 54004 c0089920 4010491c SThread-194

Check thread leak tip: You can use the following command repeatedly in the same state, such as after each application open closed, this command can count the number of threads in the target process, this number has been increasing, indicating that the process within the process is not properly released.

PS-T PID | BusyBox wc-c

3. Proc Process Status Node

The Linux proc virtual file system will record some status information of all the processes in the system, there will be a process directory under/prco, and the directory name is PID. The amount of information in the PID folder is very large, now only two are related to the internal leak: FD directory and maps node.

[Email protected]:/# PS MediaServer USER PID PPID vsize RSS Wchan PC NAME Media 8403 1 240688 16940 ffffffff b6f225a0 s/system/bin/mediaserver [Email protected]:/# ll/proc/8403 Dr-xr-xr-x Media Audio 2012-02-14 12:55 attr ....................................... dr-x------Media Audio 2012-02-14 12:55 FD -r--r--r--Media Audio 0 2012-02-14 12:55 maps ....................................... -r--r--r--Media Audio 0 2012-02-14 12:55 Wchan

① Process FD Directory

You can see that the FD is a link to the file handle, for example, 17 is the file handle number and/system/etc/camera.cfg is the open file directory.

[Email protected]:/# LL/PROC/8403/FD LRWX------Media Audio 2012-02-14 13:02 0,/dev/null LRWX------Media Audio 2012-02-14 13:02 1,/dev/null L-WX------Media Audio 2012-02-14 13:02/dev/log/system lr-x------Media Audio 2012-02-14 13:02/dev/__properties__ lr-x------Media Audio 2012-02-14 13:02/system/etc/camera.cfg lr-x------Media Audio 2012-02-14 13:0217-/system/etc/camera.cfg L-WX------Media Audio 2012-02-14 13:02/dev/cpuctl/apps/tasks LRWX------Media Audio 2012-02-14 13:02 3,/dev/binder LRWX------Media Audio 2012-02-14 13:02 8,/dev/cpuctl/tasks L-WX------Media Audio 2012-02-14 13:02 9,/dev/log/events .......................................

To see the maximum number of file handles per thread of the system, the general system defaults to a process with a maximum of 1024 file handles, and when a process opens a file handle that reaches 1024, the file handle will fail, and Strerror (errno) will report "Too many Open Files ".

Cat/proc/pid/limits | grep "Max Open Files"

Check if the file handle is leaking technique: You can use the following command repeatedly in the same state, such as after each application open closed, this command can count all the file handles in the target process, this number has been increasing, indicating that there is a process within the processing file handle is not properly closed.

cat/proc/fd | BusyBox wc-c

② Process Maps Node

The maps node can query the usage of the virtual memory space of the process.

The file has 6 columns, respectively:

Address: library in process address range

Permissions: Virtual memory permissions, r= read, w= write, x=,s= sharing, p= private;

Offset: library in process address range

Device: The main device number and the secondary device number of the image file;

Node: the node number of the image file;

Path: path to the image file

[Email protected]:/# cat/proc/8403/maps a9035000-a9525000 rw-s 98bb3000 00:09 2159 anon_inode:dmabuf ................................................................ a95bf000-a96bc000 Rw-p 00000000 00:00 0 [stack:11334] a99fc000-ab17b000 rw-s 96354000 00:0c 31508/dev/video0 ab17b000-ac8fa000 rw-s 94bd5000 00:0c 31508/dev/video0 af7f8000-b0f77000 rw-s 90558000 00:0c 31508/dev/video0 b0f77000-b26f6000 rw-s 8edd9000 00:0c 31508/dev/video0 ................................................................ b26f9000-b27f6000 Rw-p 00000000 00:00 0 [stack:11307] b27f6000-b27f8000 Rw-p 00000000 00:00 0 ................................................................ b4bb4000-b4bb5000 r--p 00001000 b3:07 1091/system/lib/libril_audio.so b4bb5000-b4bb6000 rw-p 00002000 b3:07 1091/system/lib/libril_audio.so .................................................................. b6f54000-b6f55000 r--p 0000f000 b3:07 149/system/bin/linker b6f55000-b6f56000 rw-p 00010000 b3:07 149/system/bin/linker b6f56000-b6f57000 Rw-p 00000000 00:00 0 b6f57000-b6f59000 R-xp 00000000 b3:07 162/system/bin/mediaserver b6f5a000-b6f5b000 r--p 00002000 b3:07 162/system/bin/mediaserver b6f5b000-b6f5c000 Rw-p 00000000 00:00 0 b852b000-b859d000 Rw-p 00000000 00:00 0 [Heap] bea7c000-bea9d000 Rw-p 00000000 00:00 0 [Stack] ffff0000-ffff1000 R-xp 00000000 00:00 0 [vectors]

32-bit LIUNX system each process has a 4G address space, and the process address space under the Android system is as follows:

High-level 1G space for the kernel address space, the status of 3G space for the user address space, you can see stack stack is a high-to-low growth, and heap is from the status of the high-rise, there is a section of dynamic library load, you can print out the comparison according to the above Catmaps.

How to locate a heap leak:

The following is a call to the mmap map to get the process virtual address, so that the printing continues to increase, indicating that there are mmap and munmap in the process is not symmetric operation, resulting in the disclosure of the process virtual address.

ab17b000-ac8fa000 rw-s 94bd5000 00:0c 31508/dev/video0

The following is a line stacks usage, [stack:11334],11334 for the thread number TID, so that the printing continues to increase, the process will continue to create threads, but did not release the old thread.

a95bf000-a96bc000 Rw-p 00000000 00:00 0 [stack:11334]

③meminfo node

Proc/meminfo node records some usage of system memory, mainly see memfree this.

[Email protected]:/# Cat/proc/meminfo Cat/proc/meminfo memtotal:1673008 KB all available RAM sizes (that is, physical memory minus some reserved bits and the kernel's binary code size) memfree:761320 KB Lowfree and Highfree total, unused memory is left in the system .......................................... mapped:87932 KB the size of the mappings such as devices and files. ..........................................

4. Android Tools

This is some of the commands implemented on Android, which can also be used on the native layer, but some of the statistics are the same as above.

①dumpsys Meminfo [PID] [package name]

You can view memory usage for a thread, including app and system threads, including the native heap and the Java heap. Generally used to check the Java application process, for the system native process, dump out less information.

②procrank

Androidprocrank (/system/xbin/procrank) tool that lists the memory usage that the process consumes. The order is from high to low. Each process consumes a memory size listed in the form of VSS, RSS, PSS, USS. To simplify the description, memory consumption is expressed in pages rather than bytes. Typically, each page is 4096 bytes. (Same as PS function, data is slightly different).

③valgrind

The Android SDK is integrated by default with Valgrind, an excellent memory problem detection tool that can detect memory leaks.

The current scenario does not compile the tool by default and can be temporarily compiled with the following command:

$ CD External/valgrind $ mm-j16

Then go back to the Android root directory to compile the production system.img. For the system to start running process needs, such as debug Surfaceflinger, need to init.rc comment surfaceflinger service, change to command line startup,

[Email protected]:/# valgrind--leak-check=full--log-file=/data/valgrind.log/system/bin/surfaceflinger &

After some simple operation of the interface to kill the Surfacelinger process, Valgrind will output the analysis report to/data/valgrind.log, which contains a lot of information, with the relevant example log:

Follow Leak Summary:

==1982== LEAK SUMMARY: = = 1982==    definitely lost:58,004 bytes in 477 blocks ==1982==    indirectly lost: 376 bytes in 8 blocks ==1982==      possibly lost:122,997 bytes in 484 blocks ==198 2==    still reachable:922,973 bytes in 20,141 blocks ==1982==          suppressed:0 bytes in 0 blocks ==1982== Reachable blocks (those to which a pointer was found) AR e not shown. ==1982== to see them, rerun with:--leak-check=full--show-reachable=yes ==1982== ==1982== for counts of detected and suppressed errors, rerun with:-V ==1982== use--track-origins=yes to see where uninitialised values come from ==1982== ERROR summary:673822 errors from 827 contexts (suppressed:0 from 0)

Android memory leak issue "go"