Questa sezione riepiloga gli strumenti utili e i comandi correlati per il debug, la traccia e la profilazione del codice della piattaforma Android nativa durante lo sviluppo di funzionalità a livello di piattaforma.
Nota: le pagine in questa sezione e altrove all'interno di questo sito consigliano l'uso di adb insieme all'argomento setprop per eseguire il debug di alcuni aspetti di Android. In Android 7.x e versioni precedenti, i nomi delle proprietà avevano un limite di lunghezza di 32 caratteri. Ciò significava che per creare una proprietà di wrap con il nome dell'app era necessario troncare il nome per adattarlo. In Android 8.0 e versioni successive questo limite è molto maggiore e non dovrebbe richiedere il troncamento.
Questa pagina copre le nozioni di base relative ai dump di arresto anomalo del sistema trovati nell'output di logcat. Altre pagine contengono molti più dettagli sulla diagnosi dei crash nativi , sull'esplorazione dei servizi di sistema con dumpsys , sulla visualizzazione della memoria nativa , della rete e dell'utilizzo della RAM , sull'utilizzo di AddressSanitizer per rilevare bug di memoria nel codice nativo, sulla valutazione dei problemi di prestazioni (include systrace ) e sull'utilizzo dei debugger .
Discarica e lapidi
Quando si avvia un eseguibile collegato dinamicamente, vengono registrati diversi gestori di segnale che, in caso di arresto anomalo, causano la scrittura di un crash dump di base su logcat e la scrittura di un file tombstone più dettagliato su /data/tombstones/ . La rimozione definitiva è un file con dati aggiuntivi sul processo bloccato. In particolare, contiene analisi dello stack per tutti i thread nel processo che ha subito un crash (non solo il thread che ha rilevato il segnale), una mappa di memoria completa e un elenco di tutti i descrittori di file aperti.
Prima di Android 8.0, gli arresti anomali venivano gestiti dai demoni debuggerd e debuggerd64 . In Android 8.0 e versioni successive, crash_dump32 e crash_dump64 vengono generati secondo necessità.
È possibile che il dumper di arresto anomalo del sistema venga collegato solo se non è già collegato nient'altro, il che significa che l'utilizzo di strumenti come strace o lldb impedisce il verificarsi di dump di arresto anomalo del sistema.
Output di esempio (con timestamp e informazioni estranee rimosse):
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys'
Revision: '0'
ABI: 'arm'
pid: 17946, tid: 17949, name: crasher >>> crasher <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
r0 0000000c r1 00000000 r2 00000000 r3 00000000
r4 00000000 r5 0000000c r6 eccdd920 r7 00000078
r8 0000461a r9 ffc78c19 sl ab209441 fp fffff924
ip ed01b834 sp eccdd800 lr ecfa9a1f pc ecfd693e cpsr 600e0030
backtrace:
#00 pc 0004793e /system/lib/libc.so (pthread_mutex_lock+1)
#01 pc 0001aa1b /system/lib/libc.so (readdir+10)
#02 pc 00001b91 /system/xbin/crasher (readdir_null+20)
#03 pc 0000184b /system/xbin/crasher (do_action+978)
#04 pc 00001459 /system/xbin/crasher (thread_callback+24)
#05 pc 00047317 /system/lib/libc.so (_ZL15__pthread_startPv+22)
#06 pc 0001a7e5 /system/lib/libc.so (__start_thread+34)
Tombstone written to: /data/tombstones/tombstone_06
L'ultima riga di output fornisce la posizione dell'intera rimozione definitiva sul disco.
Se sono disponibili i file binari non rimossi, è possibile ottenere uno svolgimento più dettagliato con le informazioni sul numero di riga incollando lo stack in development/scripts/stack :
development/scripts/stack
Suggerimento: per comodità, se hai eseguito lunch , lo stack è già sul tuo $PATH quindi non è necessario fornire il percorso completo.
Output di esempio (basato sull'output logcat sopra):
Reading native crash info from stdin
03-02 23:53:49.477 17951 17951 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-02 23:53:49.477 17951 17951 F DEBUG : Build fingerprint: 'Android/aosp_angler/angler:7.1.1/NYC/enh12211018:eng/test-keys'
03-02 23:53:49.477 17951 17951 F DEBUG : Revision: '0'
03-02 23:53:49.477 17951 17951 F DEBUG : ABI: 'arm'
03-02 23:53:49.478 17951 17951 F DEBUG : pid: 17946, tid: 17949, name: crasher >>> crasher <<<
03-02 23:53:49.478 17951 17951 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
03-02 23:53:49.478 17951 17951 F DEBUG : r0 0000000c r1 00000000 r2 00000000 r3 00000000
03-02 23:53:49.478 17951 17951 F DEBUG : r4 00000000 r5 0000000c r6 eccdd920 r7 00000078
03-02 23:53:49.478 17951 17951 F DEBUG : r8 0000461a r9 ffc78c19 sl ab209441 fp fffff924
03-02 23:53:49.478 17951 17951 F DEBUG : ip ed01b834 sp eccdd800 lr ecfa9a1f pc ecfd693e cpsr 600e0030
03-02 23:53:49.491 17951 17951 F DEBUG :
03-02 23:53:49.491 17951 17951 F DEBUG : backtrace:
03-02 23:53:49.492 17951 17951 F DEBUG : #00 pc 0004793e /system/lib/libc.so (pthread_mutex_lock+1)
03-02 23:53:49.492 17951 17951 F DEBUG : #01 pc 0001aa1b /system/lib/libc.so (readdir+10)
03-02 23:53:49.492 17951 17951 F DEBUG : #02 pc 00001b91 /system/xbin/crasher (readdir_null+20)
03-02 23:53:49.492 17951 17951 F DEBUG : #03 pc 0000184b /system/xbin/crasher (do_action+978)
03-02 23:53:49.492 17951 17951 F DEBUG : #04 pc 00001459 /system/xbin/crasher (thread_callback+24)
03-02 23:53:49.492 17951 17951 F DEBUG : #05 pc 00047317 /system/lib/libc.so (_ZL15__pthread_startPv+22)
03-02 23:53:49.492 17951 17951 F DEBUG : #06 pc 0001a7e5 /system/lib/libc.so (__start_thread+34)
03-02 23:53:49.492 17951 17951 F DEBUG : Tombstone written to: /data/tombstones/tombstone_06
Reading symbols from /huge-ssd/aosp-arm64/out/target/product/angler/symbols
Revision: '0'
pid: 17946, tid: 17949, name: crasher >>> crasher <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
r0 0000000c r1 00000000 r2 00000000 r3 00000000
r4 00000000 r5 0000000c r6 eccdd920 r7 00000078
r8 0000461a r9 ffc78c19 sl ab209441 fp fffff924
ip ed01b834 sp eccdd800 lr ecfa9a1f pc ecfd693e cpsr 600e0030
Using arm toolchain from: /huge-ssd/aosp-arm64/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9/bin/
Stack Trace:
RELADDR FUNCTION FILE:LINE
0004793e pthread_mutex_lock+2 bionic/libc/bionic/pthread_mutex.cpp:515
v------> ScopedPthreadMutexLocker bionic/libc/private/ScopedPthreadMutexLocker.h:27
0001aa1b readdir+10 bionic/libc/bionic/dirent.cpp:120
00001b91 readdir_null+20 system/core/debuggerd/crasher.cpp:131
0000184b do_action+978 system/core/debuggerd/crasher.cpp:228
00001459 thread_callback+24 system/core/debuggerd/crasher.cpp:90
00047317 __pthread_start(void*)+22 bionic/libc/bionic/pthread_create.cpp:202 (discriminator 1)
0001a7e5 __start_thread+34 bionic/libc/bionic/clone.cpp:46 (discriminator 1)
Puoi usare stack su un'intera lapide. Esempio:
stack < FS/data/tombstones/tombstone_05
Questo è utile se hai appena decompresso una segnalazione di bug nella directory corrente. Per ulteriori informazioni sulla diagnosi di arresti anomali nativi e rimozione definitiva, vedere Diagnosi degli arresti anomali nativi .
Ottenere un'analisi dello stack/rimozione definitiva da un processo in esecuzione
È possibile utilizzare lo strumento debuggerd per ottenere un dump dello stack da un processo in esecuzione. Dalla riga di comando, richiama debuggerd utilizzando un ID di processo (PID) per eseguire il dump di una rimozione completa su stdout . Per ottenere solo lo stack per ogni thread nel processo, includi il flag -b o --backtrace .
Comprendere uno svolgimento complesso
Quando un'app si arresta in modo anomalo, lo stack tende a essere piuttosto complesso. Il seguente esempio dettagliato evidenzia molte delle complessità:
#00 pc 00000000007e6918 /system/priv-app/Velvet/Velvet.apk (offset 0x346b000)
#01 pc 00000000001845cc /system/priv-app/Velvet/Velvet.apk (offset 0x346b000)
#02 pc 00000000001847e4 /system/priv-app/Velvet/Velvet.apk (offset 0x346b000)
#03 pc 00000000001805c0 /system/priv-app/Velvet/Velvet.apk (offset 0x346b000) (Java_com_google_speech_recognizer_AbstractRecognizer_nativeRun+176)
I frame n. 00–#03 provengono dal codice JNI nativo archiviato non compresso nell'APK per risparmiare spazio su disco anziché essere estratti in un file .so separato. Lo svolgitore dello stack in Android 9 e versioni successive non necessita del file .so estratto per far fronte a questo caso comune specifico di Android.
I frame #00–#02 non hanno nomi di simboli perché sono stati rimossi dallo sviluppatore.
Il frame #03 mostra che laddove i simboli sono disponibili, lo svolgitore li utilizza.
#04 pc 0000000000117550 /data/dalvik-cache/arm64/system@priv-app@Velvet@Velvet.apk@classes.dex (offset 0x108000) (com.google.speech.recognizer.AbstractRecognizer.nativeRun+160)
Il frame n. 04 è un codice Java compilato in anticipo. Il vecchio svolgitore si sarebbe fermato qui, incapace di svolgersi attraverso Java.
#05 pc 0000000000559f88 /system/lib64/libart.so (art_quick_invoke_stub+584)
#06 pc 00000000000ced40 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
#07 pc 0000000000280cf0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
#08 pc 000000000027acac /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+948)
#09 pc 000000000052abc0 /system/lib64/libart.so (MterpInvokeDirect+296)
#10 pc 000000000054c614 /system/lib64/libart.so (ExecuteMterpImpl+14484)
I frame n. 05–n. 10 provengono dall'implementazione dell'interprete ART. Lo svolgitore dello stack nelle versioni precedenti ad Android 9 avrebbe mostrato questi frame senza il contesto del frame n. 11 che spiegava quale codice stava interpretando l'interprete. Questi frame sono utili se stai eseguendo il debug di ART stesso. Se stai eseguendo il debug di un'app, puoi ignorarli. Alcuni strumenti, come simpleperf , omettono automaticamente questi frame.
#11 pc 00000000001992d6 /system/priv-app/Velvet/Velvet.apk (offset 0x26cf000) (com.google.speech.recognizer.AbstractRecognizer.run+18)
Il frame n. 11 è il codice Java interpretato.
#12 pc 00000000002547a8 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.780698333+496)
#13 pc 000000000025a328 /system/lib64/libart.so (art::interpreter::ArtInterpreterToInterpreterBridge(art::Thread*, art::CodeItemDataAccessor const&, art::ShadowFrame*, art::JValue*)+216)
#14 pc 000000000027ac90 /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+920)
#15 pc 0000000000529880 /system/lib64/libart.so (MterpInvokeVirtual+584)
#16 pc 000000000054c514 /system/lib64/libart.so (ExecuteMterpImpl+14228)
I frame dal n. 12 al n. 16 sono l'implementazione stessa dell'interprete.
#17 pc 00000000002454a0 /system/priv-app/Velvet/Velvet.apk (offset 0x1322000) (com.google.android.apps.gsa.speech.e.c.c.call+28)
Il frame n. 17 è il codice Java interpretato. Questo metodo Java corrisponde ai frame dell'interprete n. 12–n. 16.
#18 pc 00000000002547a8 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.780698333+496)
#19 pc 0000000000519fd8 /system/lib64/libart.so (artQuickToInterpreterBridge+1032)
#20 pc 00000000005630fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
I frame dal n. 18 al n. 20 sono la VM stessa, il codice per la transizione dal codice Java compilato al codice Java interpretato.
#21 pc 00000000002ce44c /system/framework/arm64/boot.oat (offset 0xdc000) (java.util.concurrent.FutureTask.run+204)
Il frame n. 21 è il metodo Java compilato che richiama il metodo Java nel n. 17.
#22 pc 0000000000559f88 /system/lib64/libart.so (art_quick_invoke_stub+584)
#23 pc 00000000000ced40 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
#24 pc 0000000000280cf0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
#25 pc 000000000027acac /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+948)
#26 pc 0000000000529880 /system/lib64/libart.so (MterpInvokeVirtual+584)
#27 pc 000000000054c514 /system/lib64/libart.so (ExecuteMterpImpl+14228)
I frame dal n. 22 al n. 27 sono l'implementazione dell'interprete, che effettua una chiamata al metodo dal codice interpretato a un metodo compilato.
#28 pc 00000000003ed69e /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.e.run+22)
Il frame n. 28 è il codice Java interpretato.
#29 pc 00000000002547a8 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.780698333+496)
#30 pc 0000000000519fd8 /system/lib64/libart.so (artQuickToInterpreterBridge+1032)
#31 pc 00000000005630fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
I frame dal n. 29 al n. 31 sono un'altra transizione tra codice compilato e codice interpretato.
#32 pc 0000000000329284 /system/framework/arm64/boot.oat (offset 0xdc000) (java.util.concurrent.ThreadPoolExecutor.runWorker+996)
#33 pc 00000000003262a0 /system/framework/arm64/boot.oat (offset 0xdc000) (java.util.concurrent.ThreadPoolExecutor$Worker.run+64)
#34 pc 00000000002037e8 /system/framework/arm64/boot.oat (offset 0xdc000) (java.lang.Thread.run+72)
I frame #32–#34 sono frame Java compilati che si chiamano direttamente tra loro. In questo caso lo stack di chiamate nativo è uguale allo stack di chiamate Java.
#35 pc 0000000000559f88 /system/lib64/libart.so (art_quick_invoke_stub+584)
#36 pc 00000000000ced40 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
#37 pc 0000000000280cf0 /system/lib64/libart.so (art::interpreter::ArtInterpreterToCompiledCodeBridge(art::Thread*, art::ArtMethod*, art::ShadowFrame*, unsigned short, art::JValue*)+344)
#38 pc 000000000027acac /system/lib64/libart.so (bool art::interpreter::DoCall<false, false>(art::ArtMethod*, art::Thread*, art::ShadowFrame&, art::Instruction const*, unsigned short, art::JValue*)+948)
#39 pc 0000000000529f10 /system/lib64/libart.so (MterpInvokeSuper+1408)
#40 pc 000000000054c594 /system/lib64/libart.so (ExecuteMterpImpl+14356)
I frame #35–#40 sono l'interprete stesso.
#41 pc 00000000003ed8e0 /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.i.run+20)
Il frame n. 41 è il codice Java interpretato.
#42 pc 00000000002547a8 /system/lib64/libart.so (_ZN3art11interpreterL7ExecuteEPNS_6ThreadERKNS_20CodeItemDataAccessorERNS_11ShadowFrameENS_6JValueEb.llvm.780698333+496)
#43 pc 0000000000519fd8 /system/lib64/libart.so (artQuickToInterpreterBridge+1032)
#44 pc 00000000005630fc /system/lib64/libart.so (art_quick_to_interpreter_bridge+92)
#45 pc 0000000000559f88 /system/lib64/libart.so (art_quick_invoke_stub+584)
#46 pc 00000000000ced40 /system/lib64/libart.so (art::ArtMethod::Invoke(art::Thread*, unsigned int*, unsigned int, art::JValue*, char const*)+200)
#47 pc 0000000000460d18 /system/lib64/libart.so (art::(anonymous namespace)::InvokeWithArgArray(art::ScopedObjectAccessAlreadyRunnable const&, art::ArtMethod*, art::(anonymous namespace)::ArgArray*, art::JValue*, char const*)+104)
#48 pc 0000000000461de0 /system/lib64/libart.so (art::InvokeVirtualOrInterfaceWithJValues(art::ScopedObjectAccessAlreadyRunnable const&, _jobject*, _jmethodID*, jvalue*)+424)
#49 pc 000000000048ccb0 /system/lib64/libart.so (art::Thread::CreateCallback(void*)+1120)
I frame n. 42–# 49 sono la VM stessa. Questa volta è il codice che avvia l'esecuzione di Java su un nuovo thread.
#50 pc 0000000000082e24 /system/lib64/libc.so (__pthread_start(void*)+36)
#51 pc 00000000000233bc /system/lib64/libc.so (__start_thread+68)
I frame #50–#51 indicano come dovrebbero iniziare tutti i thread. Questo è il codice di inizio del nuovo thread libc .