memory leaks - Android : How to analyse the native heap dump?

Question

I have created a native heap dump file by using the command dumpheap -n <PID> <file>. The file is in human readable format but contains information that is too hard to understand. How can I analyze this file and get useful information out of it?

The function address are provided in the place of function names. The mapping is provided at the bottom of the file. Is there any tool to map these and provide meaningful output with function/lib names instead of addresses (load the symbols for libraries/functions). If there isn't one then how does ddms do this? Also how to load the symbols to display the function names?

Is there any way that I can compare two or more native heap dumps?

The dump heap file that I got looks like this

Android Native Heap Dump v1.0

Total memory: 13863984 Allocation records: 3108

z 1 sz 8388608 num 1 bt 40afcd1a 40afbc0e 40119d30 40795210 407a9bae 407941a0 4076c264 40770b6c 407a47f4 407a481e 40786d44 407a6da6 407a800e 407a58c4 407a820a 40798ac8 40115bb4 4011530c

z 1 sz 1516906 num 1 bt 40afcd1a 40afbc0e 40119d30 400658fe 402563d8 5a400b10 5d6c3ed2 5d6c3efc 5d6c3f34 5d69d556 5d6a9de0 40794664 407aafa0 4076c264 40770b6c 407a47f4 407a481e 407af4a8 407aff8c 407678b0 40770b6c 407a4aba 407ac010 4076c264 40770b6c 407a47f4 4078e676 401dd98e 401de472 4005ddd2 40119ed4

z 1 sz 262144 num 1 bt 40afcd1a 40afbc0e 40119d30 400658fe 40a14416 40a144e0 40a154a4 40a1570e 40a1d8cc 40a20d42 40a1a9e4 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 401f0c90 40762e34 40792086 4076c264 40770b6c 407a4aba 407ac010 4076c264 40770b6c 407a47f4 4078e676 401dd98e 401de472 4005ddd2

z 1 sz 262144 num 1 bt 40afcd1a 40afbc0e 40119d30 400658fe 40a14416 40a144e0 40a154a4 40a1570e 40a1d8cc 40a20d42 40a1a9e4 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 401f0c90 40762e34 40792086 4076c264 40770b6c 407a4aba 407ac010 4076c264 40770b6c 407a47f4 4078e676 401dd98e

z 1 sz 65536 num 1 bt 40afcd1a 40afbc0e 40119d30 400658fe 40a14400 40a15714 40a1d8cc 40a20d42 40a1a9e4 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 401f0c90 40762e34 40792086 4076c264 40770b6c 407a4aba 407ac010 4076c264 40770b6c 407a47f4 4078e676 401dd98e 401de472 4005ddd2 40119ed4

z 1 sz 65536 num 1 bt 40afcd1a 40afbc0e 40119d30 400658fe 40a14400 40a15714 40a1d8cc 40a20d42 40a1a9e4 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 40a1aa26 401f0c90 40762e34 40792086 4076c264 40770b6c 407a4aba 407ac010 4076c264 40770b6c 407a47f4 4078e676 401dd98e 401de472 4005ddd2

What are these figures indicating?

Answer 1

The data is being generated by the dumpNativeHeap() function in android_os_Debug.cpp. Each entry is one allocation record, which contains:

• The "zygote child" flag: z 0 means the allocation was performed in the zygote process, z 1 means it happened in a child of zygote (i.e. an app process after the fork()). This is useful for determining whether a particular allocation might be shared between multiple processes by virtue of copy-on-write.
• The size of the allocation, in bytes.
• The number of allocations with the exact same size and backtrace.
• The backtrace addresses (up to 32).

The addresses aren't meaningful without a copy of /proc/<pid>/maps to see what binaries were mapped where, so a copy is included at the end.

The basic tool for converting binary + address to symbol is addr2line. You need to subtract the base address of the library from the address in the stack trace to get the library offset.

There's an easier way. The same mechanism that is used to generate these heap dumps can also be used to feed the DDMS Native Heap Tracker. This provides a full UI for browsing the contents of your native heap. You can find more information about it here and here.

FWIW, here's an example of doing it the "hard way". I dumped the heap of the Calendar app and saw this line:

z 1  sz    49152  num    1  bt b5aac102 b5aac2f6 b6f8599a b5a5e946 b5a3f268 b6f8d6a0 b6f8b83e

The relevant lines from the maps entry are:

b59ea000-b5a92000 r-xp 00000000 b3:19 817        /system/lib/libdvm.so
b5a9f000-b5ae0000 r-xp 00000000 b3:19 782        /system/lib/libc_malloc_debug_leak.so
b6f78000-b6fbf000 r-xp 00000000 b3:19 780        /system/lib/libc.so

The base address of the library must be subtracted from the address in the backtrace. You figure out what library it's in by finding the maps entry with an address range that contains the backtrace address. Working from left to right (top of the call stack to the bottom):

b5aac102 - b5a9f000 = d102
addr2line -C -f -e [...]/symbols/system/lib/libc_malloc_debug_leak.so d102
--> leak_malloc (malloc_debug_leak.cpp:283)

b5aac2f6...
--> leak_calloc (malloc_debug_leak.cpp:338)

b6f8599a - b6f78000 = d99a
addr2line -C -f -e [...]/symbols/system/lib/libc.so d99a
--> calloc (malloc_debug_common.cpp:231)

b5a5e946 - b59ea000 = 74946
addr2line -C -f -e [...]/symbols/system/lib/libdvm.so 74946
--> compilerThreadStartup (Compiler.cpp:434)

b5a3f268...
--> internalThreadStart(void*) (Thread.cpp:1752)

...and so on. This trace corresponds to a line in dalvik/vm/compiler/Compiler.cpp:

pJitTable = (JitEntry*)
            calloc(gDvmJit.jitTableSize, sizeof(*pJitTable));