Cette section résume les outils utiles et les commandes associées pour le débogage, le traçage et le profilage du code natif de la plate-forme Android lors du développement de fonctionnalités au niveau de la plate-forme.
Remarque : les pages de cette section et ailleurs sur ce site recommandent l'utilisation de adb
en conjonction avec l'argument setprop
pour déboguer certains aspects d'Android. Dans Android 7.x et versions antérieures, les noms de propriétés étaient limités à 32 caractères. Cela signifiait que pour créer une propriété wrap avec le nom de l'application, il était nécessaire de tronquer le nom pour l'adapter. Sous Android 8.0 et versions ultérieures, cette limite est beaucoup plus grande et ne devrait pas nécessiter de troncature.
Cette page couvre les bases concernant les vidages sur incident trouvés dans la sortie logcat. D'autres pages contiennent beaucoup plus de détails sur le diagnostic des crashs natifs , l'exploration des services système avec dumpsys
, l'affichage de la mémoire native , du réseau et de l'utilisation de la RAM , l'utilisation d'AddressSanitizer pour détecter les bogues de mémoire dans le code natif, l'évaluation des problèmes de performances (y compris systrace ) et l'utilisation de débogueurs .
Décharges accidentelles et pierres tombales
Lorsqu'un exécutable lié dynamiquement démarre, plusieurs gestionnaires de signaux sont enregistrés qui, en cas de crash, provoquent l'écriture d'un vidage sur incident de base dans logcat et l'écriture d'un fichier tombstone plus détaillé dans /data/tombstones/
. La pierre tombale est un fichier contenant des données supplémentaires sur le processus en panne. En particulier, il contient des traces de pile pour tous les threads du processus de plantage (pas seulement le thread qui a capté le signal), une carte mémoire complète et une liste de tous les descripteurs de fichiers ouverts.
Avant Android 8.0, les plantages étaient gérés par les démons debuggerd
et debuggerd64
. Sous Android 8.0 et versions ultérieures, crash_dump32
et crash_dump64
sont générés selon les besoins.
Il est possible que le dumper sur incident ne soit attaché que si rien d'autre n'est déjà attaché, ce qui signifie que l'utilisation d'outils tels que strace
ou lldb
empêche les vidages sur incident de se produire.
Exemple de résultat (avec horodatages et informations superflues supprimés) :
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 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
La dernière ligne de sortie donne l'emplacement de la pierre tombale complète sur le disque.
Si vous disposez des binaires non supprimés, vous pouvez obtenir un déroulement plus détaillé avec les informations sur le numéro de ligne en collant la pile dans development/scripts/stack
:
development/scripts/stack
Astuce : Pour plus de commodité, si vous avez exécuté lunch
, alors stack
est déjà sur votre $PATH
vous n'avez donc pas besoin de fournir le chemin complet.
Exemple de sortie (basé sur la sortie logcat ci-dessus) :
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)
Vous pouvez utiliser stack
sur une pierre tombale entière. Exemple:
stack < FS/data/tombstones/tombstone_05
Ceci est utile si vous venez de décompresser un rapport de bug dans le répertoire courant. Pour plus d'informations sur le diagnostic des pannes et des blocages natifs, consultez Diagnostic des pannes natives .
Obtenir une trace/tombstone de pile à partir d'un processus en cours d'exécution
Vous pouvez utiliser l'outil debuggerd
pour obtenir un vidage de pile à partir d'un processus en cours d'exécution. À partir de la ligne de commande, appelez debuggerd
à l'aide d'un ID de processus (PID) pour vider une pierre tombale complète sur stdout
. Pour obtenir uniquement la pile pour chaque thread du processus, incluez l'indicateur -b
ou --backtrace
.
Comprendre un déroulement complexe
Lorsqu'une application plante, la pile a tendance à être assez complexe. L’exemple détaillé suivant met en évidence bon nombre des complexités :
#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)
Les images 00 à 03 proviennent du code JNI natif qui a été stocké non compressé dans l'APK pour économiser de l'espace disque plutôt que d'être extrait dans un fichier .so
distinct. Le dérouleur de pile sous Android 9 et versions ultérieures n'a pas besoin du fichier .so
extrait pour faire face à ce cas courant spécifique à Android.
Les images #00 à #02 n'ont pas de noms de symboles car elles ont été supprimées par le développeur.
L'image n°03 montre que là où les symboles sont disponibles, le dérouleur les utilise.
#04 pc 0000000000117550 /data/dalvik-cache/arm64/system@priv-app@Velvet@Velvet.apk@classes.dex (offset 0x108000) (com.google.speech.recognizer.AbstractRecognizer.nativeRun+160)
L’image n°04 est du code Java compilé à l’avance. L'ancien dérouleur se serait arrêté ici, incapable de se dérouler via 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)
Les images 05 à 10 proviennent de l'implémentation de l'interpréteur ART. Le dérouleur de pile dans les versions inférieures à Android 9 aurait affiché ces images sans le contexte de l'image n°11 expliquant quel code l'interpréteur interprétait. Ces cadres sont utiles si vous déboguez ART lui-même. Si vous déboguez une application, vous pouvez les ignorer. Certains outils, comme simpleperf
, omettent automatiquement ces frames.
#11 pc 00000000001992d6 /system/priv-app/Velvet/Velvet.apk (offset 0x26cf000) (com.google.speech.recognizer.AbstractRecognizer.run+18)
L'image n°11 est le code Java en cours d'interprétation.
#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)
Les images 12 à 16 sont l'implémentation de l'interpréteur elle-même.
#17 pc 00000000002454a0 /system/priv-app/Velvet/Velvet.apk (offset 0x1322000) (com.google.android.apps.gsa.speech.e.c.c.call+28)
L'image n°17 est le code Java en cours d'interprétation. Cette méthode Java correspond aux trames d'interpréteur 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)
Les images 18 à 20 sont la machine virtuelle elle-même, le code pour passer du code Java compilé au code Java interprété.
#21 pc 00000000002ce44c /system/framework/arm64/boot.oat (offset 0xdc000) (java.util.concurrent.FutureTask.run+204)
Le cadre n°21 est la méthode Java compilée qui appelle la méthode Java du 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)
Les images 22 à 27 sont l'implémentation de l'interpréteur, effectuant une invocation de méthode à partir du code interprété vers une méthode compilée.
#28 pc 00000000003ed69e /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.e.run+22)
L'image n°28 est le code Java en cours d'interprétation.
#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)
Les images 29 à 31 sont une autre transition entre le code compilé et le code interprété.
#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)
Les frames #32 à #34 sont des frames Java compilées qui s'appellent directement. Dans ce cas, la pile d'appels native est la même que la pile d'appels 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)
Les images 35 à 40 sont l'interprète lui-même.
#41 pc 00000000003ed8e0 /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.i.run+20)
L'image n°41 est le code Java en cours d'interprétation.
#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)
Les images 42 à 49 sont la VM elle-même. Cette fois, c'est le code qui démarre l'exécution de Java sur un nouveau thread.
#50 pc 0000000000082e24 /system/lib64/libc.so (__pthread_start(void*)+36) #51 pc 00000000000233bc /system/lib64/libc.so (__start_thread+68)
Les images 50 à 51 correspondent à la manière dont tous les threads doivent démarrer. Il s'agit du code de démarrage du nouveau thread libc
.