Android :Comment analyser le natif heap dump?

Question

J'ai créé un tas natif fichier de vidage à l'aide de la commande dumpheap -n <PID> <file>.Le fichier est en format lisible par l'homme, mais contient de l'information qui est trop difficile à comprendre.Comment puis-je analyser ce fichier et obtenir des informations utiles en dehors de ça?

La fonction de l'adresse sont fournis à la place des noms de fonction.La cartographie est fourni à la fin du fichier.Est-il un outil pour cartographier et de fournir une véritable sortie avec la fonction/lib noms à la place des adresses (charger les symboles pour les bibliothèques/fonctions).Si il n'y a pas alors comment ddms faire cela?Aussi comment charger les symboles pour afficher les noms de fonction?

Est-il possible que je puisse comparer deux ou plusieurs tas natif dumps?

Le vidage de la mémoire que j'ai ressemble à ceci

Natif Android Heap Dump v1.0

Mémoire totale:13863984 Répartition des dossiers: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

Ce sont ces chiffres indiquant?

Answer 1

Les données générées par le dumpNativeHeap() fonction dans android_os_Debug.cpp.Chaque entrée est une allocation d'enregistrement, qui contient:

• Le zygote enfant" drapeau: z 0 les moyens la répartition a été réalisée dans le zygote processus, z 1 signifie qu'il est arrivé dans un enfant de zygote (c'est à direune application après l' fork()).Ceci est utile pour déterminer si une allocation peut être partagé entre plusieurs processus en vertu de la copie sur écriture.
• La taille de l'allocation, en octets.
• Le nombre d'affectations, avec exactement la même taille et de la trace.
• Les traces d'adresses (jusqu'à 32).

Les adresses ne sont pas de sens sans une copie de /proc/<pid>/maps pour voir ce que les binaires ont été cartographiés où, par conséquent, une copie est jointe à la fin.

L'outil de base pour la conversion binaire + adresse du symbole est addr2line.Vous devez soustraire de l'adresse de base de la bibliothèque à partir de l'adresse dans la trace de la pile pour obtenir la bibliothèque de l'offset.

Il y a un moyen plus facile.Le même mécanisme qui est utilisé pour générer ces tas dumps peut également être utilisé pour nourrir les DDMS Tas Natif Tracker.Cela fournit une INTERFACE utilisateur complète pour la navigation sur le contenu de votre tas natif.Vous pouvez trouver plus d'informations à ce sujet ici et ici.

FWIW, voici un exemple de le faire "à la dure".J'ai déversé un tas de l'application Calendrier et vu cette ligne:

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

Les lignes sur les cartes d'entrée sont:

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

L'adresse de base de la bibliothèque doit être soustraite de l'adresse dans la trace.Vous comprendre ce que la bibliothèque c'est de trouver les cartes d'entrée avec une plage d'adresses qui contient la trace de l'adresse.En travaillant de gauche à droite (en haut de la pile des appels vers le bas):

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)

...et ainsi de suite.Cette trace correspond à une ligne dalvik/vm/compiler/Compiler.cpp:

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