W tej sekcji podsumowano przydatne narzędzia i powiązane polecenia do debugowania, śledzenia i profilowania natywnego kodu platformy Android podczas opracowywania funkcji na poziomie platformy.
Uwaga: strony w tej sekcji i w innych miejscach tej witryny zalecają użycie adb w połączeniu z argumentem setprop w celu debugowania niektórych aspektów systemu Android. W systemie Android 7.x i starszym nazwy właściwości miały limit długości 32 znaków. Oznaczało to, że aby utworzyć właściwość wrap z nazwą aplikacji, konieczne było skrócenie nazwy, aby pasowała. W systemie Android 8.0 i nowszych limit ten jest znacznie większy i nie powinien wymagać obcinania.
Ta strona zawiera podstawowe informacje dotyczące zrzutów awaryjnych znajdujących się w danych wyjściowych logcat. Inne strony zawierają znacznie więcej szczegółów na temat diagnozowania awarii natywnych , eksplorowania usług systemowych za pomocą dumpsys , przeglądania użycia pamięci natywnej , sieci i pamięci RAM , używania AddressSanitizer do wykrywania błędów pamięci w kodzie natywnym, oceniania problemów z wydajnością (w tym systrace ) i używania debugerów .
Zrzuty i nagrobki
Podczas uruchamiania dynamicznie połączonego pliku wykonywalnego rejestrowanych jest kilka programów obsługi sygnałów, które w przypadku awarii powodują zapisanie podstawowego zrzutu awarii w logcat i zapisanie bardziej szczegółowego pliku tombstone w /data/tombstones/ . Nagrobek to plik z dodatkowymi danymi na temat awarii procesu. W szczególności zawiera ślady stosu dla wszystkich wątków w procesie awarii (nie tylko wątku, który przechwycił sygnał), pełną mapę pamięci i listę wszystkich otwartych deskryptorów plików.
Przed systemem Android 8.0 awarie były obsługiwane przez demony debuggerd i debuggerd64 . W systemie Android 8.0 i nowszych crash_dump32 i crash_dump64 są odradzane w razie potrzeby.
Zrzut awaryjny może dołączyć tylko wtedy, gdy nic innego nie jest już podłączone, co oznacza, że użycie narzędzi takich jak strace lub lldb zapobiega występowaniu zrzutów awaryjnych.
Przykładowe dane wyjściowe (z usuniętymi znacznikami czasu i nieistotnymi informacjami):
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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
Ostatnia linia danych wyjściowych podaje lokalizację pełnego nagrobka na dysku.
Jeśli masz dostępne nieokrojone pliki binarne, możesz uzyskać bardziej szczegółowe informacje o numerze wiersza, wklejając stos do development/scripts/stack :
development/scripts/stack
Wskazówka: dla wygody, jeśli uruchomiłeś lunch , stack jest już na Twojej $PATH , więc nie musisz podawać pełnej ścieżki.
Przykładowe dane wyjściowe (na podstawie danych wyjściowych logcat powyżej):
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)
Możesz użyć stack na całym nagrobku. Przykład:
stack < FS/data/tombstones/tombstone_05
Jest to przydatne, jeśli właśnie rozpakowałeś raport o błędzie w bieżącym katalogu. Aby uzyskać więcej informacji na temat diagnozowania awarii natywnych i reliktów, zobacz Diagnozowanie awarii natywnych .
Uzyskiwanie śladu stosu/nagrobka z uruchomionego procesu
Możesz użyć narzędzia debuggerd , aby uzyskać zrzut stosu z uruchomionego procesu. Z wiersza poleceń wywołaj debuggerd przy użyciu identyfikatora procesu (PID), aby zrzucić pełny tombstone na stdout . Aby pobrać tylko stos dla każdego wątku w procesie, dołącz flagę -b lub --backtrace .
Zrozumienie złożonego relaksu
Gdy aplikacja ulega awarii, stos jest dość złożony. Poniższy szczegółowy przykład podkreśla wiele złożoności:
#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)
Klatki od 00 do 03 pochodzą z natywnego kodu JNI, który był przechowywany w postaci nieskompresowanej w pakiecie APK, aby zaoszczędzić miejsce na dysku, a nie wyodrębniać go do osobnego pliku .so . Odwijacz stosu w systemie Android 9 i nowszych nie wymaga wyodrębnionego pliku .so , aby poradzić sobie z tym powszechnym przypadkiem specyficznym dla Androida.
Ramki #00–#02 nie mają nazw symboli, ponieważ zostały usunięte przez programistę.
Ramka #03 pokazuje, że tam, gdzie dostępne są symbole, odwijak ich używa.
#04 pc 0000000000117550 /data/dalvik-cache/arm64/system@priv-app@Velvet@Velvet.apk@classes.dex (offset 0x108000) (com.google.speech.recognizer.AbstractRecognizer.nativeRun+160)
Ramka nr 04 to skompilowany kod Java z wyprzedzeniem. Stary odwijak zatrzymałby się tutaj, nie mogąc odwinąć się przez Javę.
#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)
Ramki #05–#10 pochodzą z implementacji interpretera ART. Odwijacz stosu w wersjach niższych niż Android 9 pokazywałby te ramki bez kontekstu ramki nr 11 wyjaśniającego, jaki kod interpretował interpreter. Te ramki są przydatne, jeśli debugujesz sam ART. Jeśli debugujesz aplikację, możesz je zignorować. Niektóre narzędzia, takie jak simpleperf , automatycznie pomijają te ramki.
#11 pc 00000000001992d6 /system/priv-app/Velvet/Velvet.apk (offset 0x26cf000) (com.google.speech.recognizer.AbstractRecognizer.run+18)
Ramka nr 11 to interpretowany kod Java.
#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)
Ramki #12–#16 to sama implementacja interpretera.
#17 pc 00000000002454a0 /system/priv-app/Velvet/Velvet.apk (offset 0x1322000) (com.google.android.apps.gsa.speech.e.c.c.call+28)
Ramka 17 to interpretowany kod Java. Ta metoda Javy odpowiada ramkom interpretera nr 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)
Ramki #18–#20 to sama maszyna wirtualna, kod do przejścia od skompilowanego kodu Java do zinterpretowanego kodu Java.
#21 pc 00000000002ce44c /system/framework/arm64/boot.oat (offset 0xdc000) (java.util.concurrent.FutureTask.run+204)
Ramka #21 to skompilowana metoda Java, która wywołuje metodę Java w #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)
Ramki #22–#27 to implementacja interpretera, która powoduje wywołanie metody z interpretowanego kodu do skompilowanej metody.
#28 pc 00000000003ed69e /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.e.run+22)
Ramka #28 to interpretowany kod Java.
#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)
Ramki #29–#31 to kolejne przejście między kodem skompilowanym a kodem interpretowanym.
#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)
Ramki #32–#34 to skompilowane ramki Java wywołujące się bezpośrednio. W tym przypadku natywny stos wywołań jest taki sam jak stos wywołań 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)
Ramki #35–#40 to sam interpreter.
#41 pc 00000000003ed8e0 /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.i.run+20)
Ramka #41 to interpretowany kod Java.
#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)
Ramki #42–#49 to sama maszyna wirtualna. Tym razem jest to kod, który uruchamia Javę w nowym wątku.
#50 pc 0000000000082e24 /system/lib64/libc.so (__pthread_start(void*)+36)
#51 pc 00000000000233bc /system/lib64/libc.so (__start_thread+68)
Ramki #50–#51 to początek wszystkich wątków. To jest kod rozpoczęcia nowego wątku libc .