Android Native code memory leak locating solution

The memory location of Java code is not a concern for now. This article, mainly around C ++ code memory leaks.

Welcome to leave a message and share your solution for locating memory leaks. C ++ code, due to its special nature, does not have the concept of virtual machine, the memory is directly managed by the user, such as application, release, need to be actively triggered by the user, if the user appears to use the application, but after using up, do not call release, will cause memory leakage. This is a true memory leak that can only be recovered by restarting the machine.

In contrast, memory leakage on the Java side refers to an application running for a long time, which causes cross-reference and cannot be released, and the GC cannot reclaim, causing the effective memory to become smaller and smaller. We call this phenomenon “memory leak”. By closing the application and opening it again, the memory can be restored. So there is a fundamental difference between a Java memory leak and a C c ++ leak.

Java virtual machine itself will pay attention to object application, release, these do not need users directly note, Java virtual machine through the management mechanism, will call c++ in the real malloc free method, encapsulation, Java object life cycle and malloc free association. This ensures that objects that are no longer referenced are freed when they are not in use and memory is tight, which is exactly what GC collection does. Back to the main content of this section, how to locate memory leaks in our C ++.

00

We looked at the code and found that the memory request code location, in /bionic/libc/, Libstdc++. So /bionic/libc/malloc_debug/ libstdc++. Must be a debug version because the lib_malloc_debug.so library is required)

The debugging principle for this MALloc is as follows: Malloc free is redirected to lib_malloc_debug.so, lib_malloc_debug.so, lib_malloc_debug.so. For comparison, there is more record information, the address, stack, so and other information of each application will be recorded, and then when we need, we will use the tool DDMS dump to analyze the memory of each application, whether the normal release, whether there is a memory leak.

Official: adb shell stop adb shell setprop libc. Debug. Malloc. Options backtrace adb shell start and then open the need to detect apk, then run, debug can come out. Actually not feasible… I don’t want to go to the trouble of finding why? Why don’t we be violent and modify it directly? Here I give my modification method:

/ bionic/libc/bionic/malloc_common CPP modify the static void malloc_init_impl (libc_globals * globals) method, will be in front of some judgment

Then compile this module separately in /bionic/libc directory MMM

Adb shell adds some parameters. Do you need this) echo “libc. Debug. Malloc. Program = app_process” > > / system/build. The prop echo “libc. Debug. Malloc. Options = backtrace” > > /system/build.prop echo “libc.debug.malloc.env_enabled=1” >> /system/build.prop echo “libc.debug.malloc=1” >> /system/build.prop put our compiled libc.so libstdc++

adb remount adb push ‘xxxxxx/system/lib/libc.so’ /system/lib adb push xxxxxx/system/lib/libstdc++.so’ /system/lib adb Reboot then we reboot the phone and run our test demo, in this case JNidemo. How do we verify that debug Malloc is successful? mt:/ # ps | grep jnidemo u0_a155 13112 343 821920 45124 SyS_epoll_ a695c8a8 S com.example.jnidemo mt:/ # cat /proc/13112/maps | grep malloc_debug a718a000-a71ae000 r-xp 00000000 103:08 1400 /system/lib/libc_malloc_debug.so a71af000-a71b0000 r–p 00024000 103:08 1400 /system/lib/libc_malloc_debug.so a71b0000-a71b1000 rw-p 00025000 103:08 1400 /system/lib/libc_malloc_debug.so mt:/ # If /system/lib/libc_malloc_debug.so Home /user/. Android: native=true in DDMS. CFG Our Eclipse standalone DDMS will have a Native Heap display. Go to the eclipse SDK directory and open the DDMS in/SDK /tools. (Remember to close other adb port processes)

Select our process, then select the Native Heap on the right, click Snapshot Current Native Heap Usage, and the C memory information applied by the current process will be displayed.

We can use this to see how much space has been allocated to a particular location in a particular library, and then we can do multiple operations to compare the amount of space allocated to find our memory leaks.

01

Libtest_jni. so (8cf84c54); libtest_jni.so (8cf84c54); Use the cat/proc/pid/maps | grep libtest_jni. So

You see that 8CF84C54 falls in between 8CF84000 and 8CF87000, and then you look at r-XP and there’s the execution bit. P private bits so we calculate 8CF84c54-8CF84000 = 0xC54 (the address of the corresponding method in the so library) we use addr2line to find the code for this address, Here you can see line 13 of xxxxxxxtest_jni. c.

Find the code:

Here we see that the size of malloc request is 100 bytes and the code location is 13 lines. We have been applying for it but have not released it. As shown above, the C ++ memory problem can be verified through this solution to debug and locate the memory leak problem.

02

To sum up, it demonstrates a search to locate the location code of the space applied by C code. If we find that the native heap generated by meminfo information in a certain process keeps increasing, we can use this debugging method to locate it, and generally try to locate it in the method that is associated with our app. There is a slight problem here. By the nature of the DDMS tool, when you configure adDR2line, you configure the symbol lookup location, and it should be resolved to symbols, not addresses. But here always prompt addr2line tool can not find, very is broken, speechless, so just have the above manual resolution address to method means. On the other hand, this is not only a good way to learn more, but also something to be happy about.

Some reference documents:

Java Memory Leak

http://www.open-open.com/lib/view/open1432102426271.html

http://www.open-open.com/lib/view/open1425993728107.html

LeakCanary

http://www.open-open.com/lib/view/open1453976808761.html

Native memory leaks

http://blog.csdn.net/u011280717/article/details/51820268