Debugowanie natywnego kodu platformy Android

W tej sekcji podsumowano przydatne narzędzia i powiązane polecenia służące 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 Androida. W systemie Android 7.x i starszych nazwach właściwości obowiązywał limit długości wynoszący 32 znaki. Oznaczało to, że aby utworzyć właściwość wrap z nazwą aplikacji, konieczne było obcięcie nazwy w celu dopasowania. W Androidzie 8.0 i nowszych limit ten jest znacznie większy i nie powinien wymagać obcięcia.

Na tej stronie omówiono podstawy dotyczące zrzutów awaryjnych znalezionych w wynikach logcat. Inne strony zawierają znacznie więcej szczegółów na temat diagnozowania natywnych awarii , eksplorowania usług systemowych za pomocą dumpsys , przeglądania natywnej pamięci , sieci i użycia RAM , używania narzędzia AddressSanitizer do wykrywania błędów pamięci w natywnym kodzie, oceniania problemów z wydajnością (w tym systrace ) i używania debugerów .

Wysypiska śmieci i nagrobki

Kiedy uruchamia się dynamicznie połączony plik wykonywalny, rejestrowanych jest kilka procedur obsługi sygnałów, które w przypadku awarii powodują zapisanie podstawowego zrzutu awaryjnego do logcat i zapisanie bardziej szczegółowego pliku tombstone do /data/tombstones/ . Nagrobek to plik z dodatkowymi danymi na temat zawieszonego procesu. W szczególności zawiera ślady stosu dla wszystkich wątków w procesie powodującym awarię (nie tylko wątku, który przechwycił sygnał), pełną mapę pamięci i listę wszystkich otwartych deskryptorów plików.

Przed wersją Androida 8.0 awarie były obsługiwane przez demony debuggerd i debuggerd64 . W systemie Android 8.0 i nowszych wersjach crash_dump32 i crash_dump64 są generowane w razie potrzeby.

Możliwe jest dołączenie narzędzia zrzutu awaryjnego tylko wtedy, gdy nie jest już podłączone nic innego, 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 dodatkowymi 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 wyniku podaje lokalizację pełnego nagrobka na dysku.

Jeśli masz dostępne nieobrobione pliki binarne, możesz uzyskać bardziej szczegółowe informacje o numerze linii, wklejając stos do development/scripts/stack :

development/scripts/stack

Wskazówka: dla wygody, jeśli uruchomiłeś lunch , stack znajduje się już na $PATH , więc nie musisz podawać pełnej ścieżki.

Przykładowe wyjście (w oparciu o powyższe wyjście logcat):

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 natywnych awarii i reliktów, zobacz Diagnozowanie natywnych awarii .

Pobieranie śladu stosu/nagrobka z działającego procesu

Możesz użyć narzędzia debuggerd , aby uzyskać zrzut stosu z działającego procesu. Z wiersza poleceń wywołaj debuggerd , używając identyfikatora procesu (PID), aby zrzucić pełny nagrobek na stdout . Aby uzyskać stos dla każdego wątku w procesie, dołącz flagę -b lub --backtrace .

Zrozumienie złożonego odprężenia

Gdy aplikacja ulega awarii, stos jest zwykle dość złożony. Poniższy szczegółowy przykład ilustruje 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)

Ramki #00–#03 pochodzą z natywnego kodu JNI, który był przechowywany w postaci nieskompresowanej w pliku APK, aby zaoszczędzić miejsce na dysku, zamiast wyodrębniać je do osobnego pliku .so . Odwijak stosu w systemie Android 9 i nowszych wersjach nie potrzebuje wyodrębnionego pliku .so , aby poradzić sobie z tym typowym przypadkiem specyficznym dla Androida.

Ramki #00–#02 nie mają nazw symboli, ponieważ zostały usunięte przez programistę.

Ramka nr 03 pokazuje, że tam, gdzie dostępne są symbole, odwijak je wykorzystuje.

    #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 z wyprzedzeniem kod Java. Stary odwijak zatrzymałby się w tym miejscu, nie mogąc odwinąć w Javie.

    #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. Odwijak stosu w wersjach starszych 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 ją 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 przedstawia 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 nr 12–16 stanowią samą implementację interpretera.

    #17 pc 00000000002454a0  /system/priv-app/Velvet/Velvet.apk (offset 0x1322000) (com.google.android.apps.gsa.speech.e.c.c.call+28)

Ramka nr 17 przedstawia interpretowany kod Java. Ta metoda Java odpowiada ramkom interpretera #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 przedstawiają samą maszynę wirtualną, kod umożliwiający przejście ze 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 z #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 przedstawiają implementację interpretera, wykonującą wywołanie metody z zinterpretowanego 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 nr 28 przedstawia 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 nr 29–31 to kolejne przejście między kodem skompilowanym a kodem zinterpretowanym.

    #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 nr 32–34 to skompilowane ramki Java, które bezpośrednio się ze sobą łączą. 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 same w sobie są interpretatorem.

    #41 pc 00000000003ed8e0  /system/priv-app/Velvet/Velvet.apk (com.google.android.apps.gsa.shared.util.concurrent.b.i.run+20)

Ramka nr 41 przedstawia 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 uruchamiający 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 pokazują, jak powinny zaczynać się wszystkie wątki. To jest kod startowy nowego wątku libc .