Android: come analizzare la discarica del mucchio nativo?

Question

Ho creato un file dump heap nativo utilizzando il comando dumpheap -n <PID> <file>. Il file è in formato leggibile umano ma contiene informazioni troppo difficili da capire. Come posso analizzare questo file e ottenere informazioni utili da esso?

L'indirizzo della funzione è fornito nel luogo dei nomi delle funzioni. La mappatura è fornita nella parte inferiore del file. C'è qualche strumento per mapparlo e fornire un'uscita significativa con nomi funzione / lib anziché indirizzi (caricare i simboli per le librerie / funzioni). Se non ce n'è uno, come fa DDMS questo? Anche come caricare i simboli per visualizzare i nomi delle funzioni?

C'è un modo in cui posso confrontare due o più discariche di mucchio nativo?

Il file Heap Dump che ho ottenuto assomiglia a questo

Android Native Heap Dump V1.0

Memoria totale: 13863984 Record di assegnazione: 3108

Z 1 SZ 8388608 NUM 1 BT 40AFCD1A 40AFC0E 40119D30 40795210 407A9BAE 407941A0 4076C264 40770B6C 407A47F4 407A481E 40786D44 407A6DA6 407A800E 407A58C4 407A820A 40798AC8 40115BB4 4014530C

z 1 sz 1.516.906 num 1 bt 40afcd1a 40afbc0e 40119d30 400658fe 402563d8 5a400b10 5d6c3ed2 5d6c3efc 5d6c3f34 5d69d556 5d6a9de0 40.794.664 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 40.792.086 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 40.792.086 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 40.792.086 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 40.792.086 4076c264 40770b6c 407a4aba 407ac010 4076c264 40770b6c 407a47f4 4078e676 401dd98e 401de472 4005ddd2

Quali sono queste figure che indicano?

Answer 1

I dati vengono generati dalla funzione dumpNativeHeap() in Android_os_Debug.cpp . Ogni voce è un record di assegnazione, che contiene:

.
• La bandiera "Zygote Child": z 0 significa che l'assegnazione è stata eseguita nel processo Zygote, z 1 significa che è successo in un figlio di Zygote (cioè un processo di app dopo il fork()). Ciò è utile per determinare se una particolare allocazione potrebbe essere condivisa tra più processi in virtù della copia-on-write.
• la dimensione dell'assegnazione, in byte.
• il numero di allocazioni con esattamente le stesse dimensioni e backtrace.
• Gli indirizzi di backtrana (fino a 32).

Gli indirizzi non sono significativi senza una copia di /proc/<pid>/maps per vedere quali binari sono stati mappati dove, quindi una copia è inclusa alla fine.

Lo strumento di base per la conversione dell'indirizzo Binario + per il simbolo è aggiungere / a>. È necessario sottrarre l'indirizzo di base della libreria dall'indirizzo nella traccia dello stack per ottenere l'offset della libreria.

C'è un modo più semplice. Lo stesso meccanismo utilizzato per generare queste discariche heap può anche essere utilizzato per alimentare il localizzatore di heap nativo DDMS. Questo fornisce un'interfaccia utente completa per la navigazione il contenuto del tuo mucchio nativo. Puoi trovare maggiori informazioni a riguardo qui e qui . < / P >.

fwiw, ecco un esempio di farlo il "duro modo". Ho scaricato il mucchio dell'app del calendario e ho visto questa linea:

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

.

Le linee pertinenti dalla voce delle mappe sono:

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'indirizzo di base della libreria deve essere sottratto dall'indirizzo nel backtrace. Scopri quale biblioteca è in entrata trovando la voce delle mappe con un intervallo di indirizzi che contiene l'indirizzo di backtrace. Lavorare da sinistra a destra (parte superiore dello stack di chiamata in basso):

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)

.

... e così via. Questa traccia corrisponde a una linea in dalvik/vm/compiler/Compiler.cpp:

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

.