Cette section récapitule 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 au niveau de la plate-forme.
Remarque:Les pages de cette section et des autres pages
sur ce site, nous vous recommandons d'utiliser adb conjointement 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
caractères. Cela signifiait que pour créer une propriété
wrapper avec le nom de l'application,
il était nécessaire de tronquer
le nom pour tenir. Sur Android 8.0 et versions ultérieures, cette
est bien supérieure et ne devrait pas nécessiter la troncation.
Cette page présente les principes de base des fichiers de crash dump contenus dans la sortie logcat.
D'autres pages contiennent
beaucoup plus de détails sur
diagnostiquer les plantages natifs
explorant les services système avec
<ph type="x-smartling-placeholder"></ph>
dumpsys, affichage
mémoire native,
réseau,
et RAM
en utilisant AddressSanitizer pour détecter la mémoire
les bugs dans le code natif, l'évaluation
problèmes de performances (y compris
systrace), et l'utilisation
débogueurs.
Vidages de plantage et pierres tombales
Lorsqu'un exécutable associé de manière dynamique démarre, plusieurs gestionnaires de signaux sont
enregistré qu'en cas de plantage, un fichier de crash dump de base est écrit dans Logcat
et un fichier tombstone plus détaillé à écrire dans /data/tombstones/.
Le tombstone est un fichier contenant des données supplémentaires sur le processus qui a planté. En particulier, il contient
les traces de la pile de tous les threads au cours du processus de plantage (pas uniquement celui qui a détecté le
signal), un mappage de mémoire complet et une liste de tous les descripteurs de fichiers ouverts.
Avant Android 8.0, les plantages étaient gérés par
Daemons debuggerd et debuggerd64. Sur Android 8.0 et versions ultérieures,
crash_dump32 et crash_dump64 sont générés si nécessaire.
Il est possible que le fichier de crash dumper ne s'attache que si rien d'autre n'est
déjà associé, ce qui signifie que l'utilisation d'outils comme strace ou
lldb empêchent les fichiers de crash dump.
Exemple de résultat (sans les codes temporels et les informations superflues):
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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 du résultat indique l'emplacement du tombstone complet sur le disque.
Si vous disposez de binaires complets, vous pouvez obtenir un rapport
détendez-vous avec les informations
sur le numéro de ligne en collant la pile dans
development/scripts/stack:
development/scripts/stack
Conseil:Pour plus de commodité, si vous exécutez lunch,
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 un tombstone entier. Exemple :
stack < FS/data/tombstones/tombstone_05
Cette opération est utile si vous venez de décompresser un rapport de bug dans le répertoire actuel. Pour en savoir plus sur le diagnostic des plantages et des tombstones natifs, consultez Diagnostiquer les plantages natifs.
Obtenir une trace de pile ou un 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
tombstone complet sur stdout. Pour obtenir uniquement la pile
de chaque thread dans
le processus, incluez l'option -b ou --backtrace.
Comprendre un moment de détente complexe
Lorsqu'une application plante, la pile a tendance à être assez complexe. L'exemple détaillé suivant met en évidence de nombreuses 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 frames 00 à 03 proviennent du code JNI natif stocké non compressé dans l'APK pour économiser le disque
au lieu d'être extrait dans un fichier .so distinct. Le dérouleur de pile
Android 9 ou version ultérieure n'a pas besoin du fichier .so extrait pour gérer ce problème
cas spécifique à Android.
Les images n° 00 à n° 02 n'ont pas de nom de symbole, car elles ont été supprimées par le développeur.
L'image n° 03 montre que lorsque des 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)
Le frame n°04 correspond au code Java compilé à l'avance. L'ancien dérouleur s'est arrêté ici, pour vous détendre avec 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 antérieures à Android 9 aurait affiché ces frames sans contexte
du cadre n° 11 expliquant le code
interprété par l'interpréteur. Ces cadres sont utiles si
vous déboguez ART lui-même. Si vous déboguez une application, vous pouvez les ignorer. Certains outils, tels que
simpleperf, omettez automatiquement ces cadres.
#11 pc 00000000001992d6 /system/priv-app/Velvet/Velvet.apk (offset 0x26cf000) (com.google.speech.recognizer.AbstractRecognizer.run+18)
Le frame n°11 correspond au code Java interprété.
#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 n° 12 à n° 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)
Le frame n°17 correspond au code Java interprété. Cette méthode Java correspond aux frames d'interpréteur n° 12 à 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 frames 18 à 20 sont la VM elle-même, le code permettant de 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 frame n°21 est la méthode Java compilée qui appelle la méthode Java à l'étape 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 frames 22 à 27 sont l'implémentation de l'interpréteur, ce qui permet d'appeler une méthode à partir de à 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)
Le frame n°28 correspond au code Java interprété.
#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 frames 29 à 31 constituent 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és qui s'appellent directement les uns les autres. Dans ce cas, l'appel natif est identique à la pile d'appel 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éteur lui-même.
#41 pc 00000000003ed8e0 /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.i.run+20)
Le frame n°41 correspond au code Java interprété.
#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 frames 42 à 49 sont la VM elle-même. Cette fois, c'est le code qui commence à exécuter 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 frames 50 à 51 constituent le point de départ de tous les threads. Voici le libc
un nouveau code de démarrage de thread.