W następnych sekcjach znajdziesz informacje o popularnych typach błędów natywnych, analizę przykładowego zrzutu z błędem oraz omówienie nagrobków. Każdy typ awarii zawiera przykład debuggerd z wyróżnionymi kluczowymi dowodami, aby ułatwić odróżnianie poszczególnych rodzajów awarii.
Przerwij
Przerwy są interesujące, ponieważ są celowe. Istnieje wiele różnych sposobów na przerwanie (w tym wywołanie abort(3), nieudane wywołanie assert(3) lub użycie jednego z typów rejestrowania błędów specyficznych dla Androida), ale wszystkie one wymagają wywołania abort. Wywołanie funkcji abort sygnalizuje wywołanie wątku za pomocą SIGABRT, więc aby rozpoznać ten przypadek, należy zwrócić uwagę na ramkę z wartością „abort” w funkcji libc.so oraz SIGABRT w wyjściu debuggerd.
Może pojawić się wyraźny wiersz „abort message”. Sprawdź też dane wyjściowe logcat, aby zobaczyć, co zostało zapisane w tym wątku przed celowym zakończeniem działania, ponieważ w odróżnieniu od assert(3) lub funkcji rejestrowania błędów krytycznych na wysokim poziomie abort(3) nie akceptuje komunikatu.
Obecne wersje Androida umieszczają wywołanie tgkill(2)
systemowe w swojej treści, więc ich stosy są najłatwiejsze do odczytania, a wywołanie abort(3) znajduje się na samym szczycie:
pid: 4637, tid: 4637, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 0000121d r2 00000006 r3 00000008
r4 0000121d r5 0000121d r6 ffb44a1c r7 0000010c
r8 00000000 r9 00000000 r10 00000000 r11 00000000
ip ffb44c20 sp ffb44a08 lr eace2b0b pc eace2b16
backtrace:
#00 pc 0001cb16 /system/lib/libc.so (abort+57)
#01 pc 0001cd8f /system/lib/libc.so (__assert2+22)
#02 pc 00001531 /system/bin/crasher (do_action+764)
#03 pc 00002301 /system/bin/crasher (main+68)
#04 pc 0008a809 /system/lib/libc.so (__libc_init+48)
#05 pc 00001097 /system/bin/crasher (_start_main+38)
Starsze wersje Androida wykorzystywały skomplikowaną ścieżkę między pierwotnym wywołaniem abort (ramka 4 tutaj) a rzeczywistym wysłaniem sygnału (ramka 0 tutaj).
Dotyczyło to zwłaszcza procesorów ARM 32-bitowych, które dodały __libc_android_abort (klatka 3 tutaj) do sekwencji raise/pthread_kill/tgkill na innych platformach:
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
Możesz odtworzyć ten typ awarii za pomocą narzędzia crasher
abort.
Bezwzględne odwoływanie się do wskaźnika o wartości null
To klasyczny błąd natywny i chociaż jest to tylko szczególny przypadek błędu z następującego typu, warto go wymienić osobno, ponieważ zwykle wymaga najmniejszego namysłu.
W przykładzie poniżej, mimo że funkcja powodująca błąd znajduje się w funkcji libc.so, funkcje napisowe działają tylko na wskaźnikach, które są im przekazywane. Możesz więc wywnioskować, że funkcja strlen(3) została wywołana ze wskaźnikiem null. Ten błąd powinien zostać zgłoszony bezpośrednio do autora wywołującego kodu. W tym przypadku ramka 01 to nieprawidłowy rozmówca.
pid: 25326, tid: 25326, name: crasher >>> crasher <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
r0 00000000 r1 00000000 r2 00004c00 r3 00000000
r4 ab088071 r5 fff92b34 r6 00000002 r7 fff92b40
r8 00000000 r9 00000000 sl 00000000 fp fff92b2c
ip ab08cfc4 sp fff92a08 lr ab087a93 pc efb78988 cpsr 600d0030
backtrace:
#00 pc 00019988 /system/lib/libc.so (strlen+71)
#01 pc 00001a8f /system/xbin/crasher (strlen_null+22)
#02 pc 000017cd /system/xbin/crasher (do_action+948)
#03 pc 000020d5 /system/xbin/crasher (main+100)
#04 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#05 pc 000010e4 /system/xbin/crasher (_start+96)
Możesz odtworzyć ten typ awarii za pomocą narzędzia crasher
strlen-NULL.
Odwołania do wskaźników null o niskim adresie
W wielu przypadkach adres błędu nie będzie równy 0, ale będzie to inna mała liczba. Adresy dwu- i trzycyfrowe są bardzo powszechne, natomiast adresy sześciocyfrowe prawie na pewno nie są odwołaniami do pustych wskaźników, ponieważ wymagałyby przesunięcia o 1 MiB. Dzieje się to zwykle wtedy, gdy masz kod, który odwołuje się do wskaźnika null tak, jakby był to prawidłowy typ struktury. Typowe funkcje to fprintf(3) (lub dowolna inna funkcja przyjmująca argument FILE*) i readdir(3), ponieważ kod często nie sprawdza, czy wywołanie funkcji fopen(3) lub opendir(3) zakończyło się sukcesem.
Oto przykład właściwości readdir:
pid: 25405, tid: 25405, name: crasher >>> crasher <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xc
r0 0000000c r1 00000000 r2 00000000 r3 3d5f0000
r4 00000000 r5 0000000c r6 00000002 r7 ff8618f0
r8 00000000 r9 00000000 sl 00000000 fp ff8618dc
ip edaa6834 sp ff8617a8 lr eda34a1f pc eda618f6 cpsr 600d0030
backtrace:
#00 pc 000478f6 /system/lib/libc.so (pthread_mutex_lock+1)
#01 pc 0001aa1b /system/lib/libc.so (readdir+10)
#02 pc 00001b35 /system/xbin/crasher (readdir_null+20)
#03 pc 00001815 /system/xbin/crasher (do_action+976)
#04 pc 000021e5 /system/xbin/crasher (main+100)
#05 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#06 pc 00001110 /system/xbin/crasher (_start+96)
Bezpośrednią przyczyną awarii jest to, że pthread_mutex_lock(3) próbował uzyskać dostęp do adresu 0xc (ramka 0). Ale pierwszą rzeczą, którą wykonuje pthread_mutex_lock, jest odwoływanie się do elementu state w pthread_mutex_t*, który został mu przekazany. Jeśli spojrzysz na źródło, zobaczysz, że element znajduje się w strukturze w odstępie 0, co oznacza, że pthread_mutex_lock otrzymał nieprawidłowy wskaźnik 0xc. Z ramki 1 widać, że ten wskaźnik został przekazany przez readdir, który wyodrębnia pole mutex_ z elementu DIR*. Przyglądając się tej strukturze, można zauważyć, że mutex_ znajduje się w odstępie sizeof(int) + sizeof(size_t) + sizeof(dirent*) w strukturze struct DIR, co na urządzeniu 32-bitowym oznacza 4 + 4 + 4 = 12 = 0xc, więc znaleziono błąd: wywołujący przekazał parametrowi readdir wskaźnik null. Teraz możesz wkleić zrzut do narzędzia do analizy zrzutów, aby dowiedzieć się, gdzie w logcat wystąpił problem.
struct DIR {
int fd_;
size_t available_bytes_;
dirent* next_;
pthread_mutex_t mutex_;
dirent buff_[15];
long current_pos_;
};
W większości przypadków możesz pominąć tę analizę. Wystarczająco niski adres błędu oznacza zazwyczaj, że możesz pominąć dowolne ramki libc.so w stosie i bezpośrednio oskarżyć kod wywołujący. Nie zawsze jednak tak jest.
Aby odtworzyć takie przypadki awarii, użyj narzędzia crasher
fprintf-NULL lub crasher readdir-NULL.
Błąd FORTIFY
Niepowodzenie FORTIFY to szczególny przypadek przerwania, które występuje, gdy biblioteka C wykryje problem, który może prowadzić do luki w zabezpieczeniach. Wiele funkcji biblioteki C jest wzmocnionych; przyjmują one dodatkowy argument, który informuje je o tym, jak duży jest bufor, i sprawdzają w czasie wykonywania, czy operacja, którą próbujesz wykonać, się mieści. Oto przykład, w którym kod próbuje read(fd, buf, 32) do bufora, który ma tylko 10 bajtów...
pid: 25579, tid: 25579, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'FORTIFY: read: prevented 32-byte write into 10-byte buffer'
r0 00000000 r1 000063eb r2 00000006 r3 00000008
r4 ff96f350 r5 000063eb r6 000063eb r7 0000010c
r8 00000000 r9 00000000 sl 00000000 fp ff96f49c
ip 00000000 sp ff96f340 lr ee83ece3 pc ee86ef0c cpsr 000d0010
backtrace:
#00 pc 00049f0c /system/lib/libc.so (tgkill+12)
#01 pc 00019cdf /system/lib/libc.so (abort+50)
#02 pc 0001e197 /system/lib/libc.so (__fortify_fatal+30)
#03 pc 0001baf9 /system/lib/libc.so (__read_chk+48)
#04 pc 0000165b /system/xbin/crasher (do_action+534)
#05 pc 000021e5 /system/xbin/crasher (main+100)
#06 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#07 pc 00001110 /system/xbin/crasher (_start+96)
Możesz odtworzyć ten typ awarii za pomocą narzędzia crasher
fortify.
Uszkodzenie stosu wykryte przez opcję -fstack-protector
Opcja kompilatora -fstack-protector wstawia sprawdzanie do funkcji z buforami na stosie, aby chronić przed przepełnieniem bufora. Ta opcja jest domyślnie włączona w przypadku kodu platformy, ale nie aplikacji. Gdy ta opcja jest włączona, kompilator dodaje instrukcje do prologu funkcji, aby zapisać losową wartość tuż za ostatnią zmienną lokalną na stosie, oraz do epilogu funkcji, aby odczytać tę wartość i sprawdzić, czy się nie zmieniła. Jeśli ta wartość uległa zmianie, została zastąpiona przez przepełnienie bufora, więc w epilogu funkcja __stack_chk_fail rejestruje wiadomość i przerywa działanie.
pid: 26717, tid: 26717, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'stack corruption detected'
r0 00000000 r1 0000685d r2 00000006 r3 00000008
r4 ffd516d8 r5 0000685d r6 0000685d r7 0000010c
r8 00000000 r9 00000000 sl 00000000 fp ffd518bc
ip 00000000 sp ffd516c8 lr ee63ece3 pc ee66ef0c cpsr 000e0010
backtrace:
#00 pc 00049f0c /system/lib/libc.so (tgkill+12)
#01 pc 00019cdf /system/lib/libc.so (abort+50)
#02 pc 0001e07d /system/lib/libc.so (__libc_fatal+24)
#03 pc 0004863f /system/lib/libc.so (__stack_chk_fail+6)
#04 pc 000013ed /system/xbin/crasher (smash_stack+76)
#05 pc 00001591 /system/xbin/crasher (do_action+280)
#06 pc 00002219 /system/xbin/crasher (main+100)
#07 pc 000177a1 /system/lib/libc.so (__libc_init+48)
#08 pc 00001144 /system/xbin/crasher (_start+96)
Możesz odróżnić to od innych rodzajów przerwania, ponieważ w backtrace pojawia się element__stack_chk_fail, a także konkretny komunikat o przerwaniu.
Możesz odtworzyć ten typ awarii za pomocą narzędzia crasher
smash-stack.
Seccomp SIGSYS z niedozwolonego wywołania systemowego
System seccomp (w szczególności seccomp-bpf) ogranicza dostęp do wywołań systemowych. Więcej informacji o seccomp dla deweloperów platformy znajdziesz w poście na blogu Filtr Seccomp w Androidzie O. Wątek, który wywołuje ograniczone wywołanie systemowe, otrzyma sygnał SIGSYS z kodem SYS_SECCOMP. Numer wywołania systemu będzie widoczny w wierszu przyczyny wraz z architekturą. Pamiętaj, że liczba wywołań systemowych różni się w zależności od architektury. Na przykład wywołanie systemu readlinkat(2) ma numer 305 na procesorach x86, ale 267 na procesorach x86-64.
Numer wywołania jest znowu inny w przypadku obu tych opcji. Ponieważ numery wywołań systemowych różnią się w zależności od architektury, łatwiej jest zwykle użyć ścieżki wywołań, aby dowiedzieć się, które wywołanie systemowe zostało zabronione, niż szukać numeru wywołania systemowego w nagłówkach.
pid: 11046, tid: 11046, name: crasher >>> crasher <<<
signal 31 (SIGSYS), code 1 (SYS_SECCOMP), fault addr --------
Cause: seccomp prevented call to disallowed arm system call 99999
r0 cfda0444 r1 00000014 r2 40000000 r3 00000000
r4 00000000 r5 00000000 r6 00000000 r7 0001869f
r8 00000000 r9 00000000 sl 00000000 fp fffefa58
ip fffef898 sp fffef888 lr 00401997 pc f74f3658 cpsr 600f0010
backtrace:
#00 pc 00019658 /system/lib/libc.so (syscall+32)
#01 pc 00001993 /system/bin/crasher (do_action+1474)
#02 pc 00002699 /system/bin/crasher (main+68)
#03 pc 0007c60d /system/lib/libc.so (__libc_init+48)
#04 pc 000011b0 /system/bin/crasher (_start_main+72)
Niedozwolone wywołania systemu można odróżnić od innych awarii po obecności elementu SYS_SECCOMP na linii sygnału i opisu na linii przyczyny.
Możesz odtworzyć ten typ awarii za pomocą narzędzia crasher
seccomp.
Naruszenie zasad dotyczących pamięci tylko do wykonania (tylko Android 10)
W przypadku architektury ARM64 tylko w Androidzie 10 segmenty wykonywalne binarów i bibliotek zostały zamapowane w pamięci jako przeznaczone tylko do wykonania (nieczytelne) jako technika wzmocnienia ochrony przed atakami polegającymi na ponownym wykorzystaniu kodu. Ta metoda zapobiegania miała negatywny wpływ na inne metody i została później usunięta.
Uniemożliwienie odczytania kodu powoduje celowe i nieumyślne odczytywanie segmentów pamięci oznaczonych jako „tylko do wykonania”, co powoduje wygenerowanie błędu SIGSEGV o kodze SEGV_ACCERR. Może to nastąpić w wyniku błędu, luki w zabezpieczeniach, danych zmieszanych z kodem (takich jak literal pool) lub celowego zbadania pamięci.
Kompilator zakłada, że kod i dane nie są ze sobą pomieszane, ale problemy mogą wystąpić w przypadku ręcznie napisanego kodu. W wielu przypadkach można je naprawić, przenosząc stałe do sekcji .data.
Jeśli analiza kodu jest absolutnie konieczna w przypadku sekcji kodu wykonywalnego, należy najpierw wywołać funkcję mprotect(2), aby oznaczyć kod jako czytelny, a potem ponownie, aby oznaczyć go jako nieczytelny po zakończeniu operacji.
pid: 2938, tid: 2940, name: crasher64 >>> crasher64 <<<
signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x5f2ced24a8
Cause: execute-only (no-read) memory access error; likely due to data in .text.
x0 0000000000000000 x1 0000005f2cecf21f x2 0000000000000078 x3 0000000000000053
x4 0000000000000074 x5 8000000000000000 x6 ff71646772607162 x7 00000020dcf0d16c
x8 0000005f2ced24a8 x9 000000781251c55e x10 0000000000000000 x11 0000000000000000
x12 0000000000000014 x13 ffffffffffffffff x14 0000000000000002 x15 ffffffffffffffff
x16 0000005f2ced52f0 x17 00000078125c0ed8 x18 0000007810e8e000 x19 00000078119fbd50
x20 00000078125d6020 x21 00000078119fbd50 x22 00000b7a00000b7a x23 00000078119fbdd8
x24 00000078119fbd50 x25 00000078119fbd50 x26 00000078119fc018 x27 00000078128ea020
x28 00000078119fc020 x29 00000078119fbcb0
sp 00000078119fba40 lr 0000005f2ced1b94 pc 0000005f2ced1ba4
backtrace:
#00 pc 0000000000003ba4 /system/bin/crasher64 (do_action+2348)
#01 pc 0000000000003234 /system/bin/crasher64 (thread_callback+44)
#02 pc 00000000000e2044 /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
#03 pc 0000000000083de0 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)
Możesz odróżnić naruszenia pamięci tylko do wykonania od innych awarii na podstawie wiersza przyczyny.
Możesz odtworzyć ten typ awarii za pomocą narzędzia crasher xom.
Błąd wykryty przez fdsan
Filtr fdsan w Androidzie pomaga wykrywać typowe błędy związane z opisami plików, takie jak użycie po zamknięciu i podwójne zamknięcie. Aby dowiedzieć się więcej o debugowaniu (i unikaniu) tej klasy błędów, zapoznaj się z dokumentacją fdsan.
pid: 32315, tid: 32315, name: crasher64 >>> crasher64 <<< signal 35 (), code -1 (SI_QUEUE), fault addr -------- Abort message: 'attempted to close file descriptor 3, expected to be unowned, actually owned by FILE* 0x7d8e413018' x0 0000000000000000 x1 0000000000007e3b x2 0000000000000023 x3 0000007fe7300bb0 x4 3033313465386437 x5 3033313465386437 x6 3033313465386437 x7 3831303331346538 x8 00000000000000f0 x9 0000000000000000 x10 0000000000000059 x11 0000000000000034 x12 0000007d8ebc3a49 x13 0000007fe730077a x14 0000007fe730077a x15 0000000000000000 x16 0000007d8ec9a7b8 x17 0000007d8ec779f0 x18 0000007d8f29c000 x19 0000000000007e3b x20 0000000000007e3b x21 0000007d8f023020 x22 0000007d8f3b58dc x23 0000000000000001 x24 0000007fe73009a0 x25 0000007fe73008e0 x26 0000007fe7300ca0 x27 0000000000000000 x28 0000000000000000 x29 0000007fe7300c90 sp 0000007fe7300860 lr 0000007d8ec2f22c pc 0000007d8ec2f250 backtrace: #00 pc 0000000000088250 /bionic/lib64/libc.so (fdsan_error(char const*, ...)+384) #01 pc 0000000000088060 /bionic/lib64/libc.so (android_fdsan_close_with_tag+632) #02 pc 00000000000887e8 /bionic/lib64/libc.so (close+16) #03 pc 000000000000379c /system/bin/crasher64 (do_action+1316) #04 pc 00000000000049c8 /system/bin/crasher64 (main+96) #05 pc 000000000008021c /bionic/lib64/libc.so (_start_main)
Możesz odróżnić to od innych rodzajów przerwania, ponieważ w backtrace pojawia się elementfdsan_error, a także konkretny komunikat o przerwaniu.
Możesz odtworzyć ten typ błędu za pomocą crasher fdsan_file lub crasher fdsan_dir.
Badanie zrzutów awaryjnych
Jeśli nie masz konkretnego błędu, który obecnie analizujesz, źródło platformy zawiera narzędzie do testowania debuggerd o nazwie crasher. Jeśli mm w system/core/debuggerd/, na ścieżce będzie zarówno crasher, jak i crasher64 (ta druga pozwala na testowanie awarii 64-bitowych). Crasher może się zawiesić na wiele interesujących sposobów w zależności od podanych przez Ciebie argumentów wiersza poleceń.
Aby zobaczyć aktualnie obsługiwane opcje, kliknij crasher --help.
Aby zapoznać się z różnymi elementami pliku z informacjami o zawieszeniu, przeanalizujmy ten przykładowy plik:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
Revision: '0'
ABI: 'arm'
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8
r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c
r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c
ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
Tombstone written to: /data/tombstones/tombstone_06
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Wiersz gwiazdek z przecinkami jest przydatny, jeśli w dzienniku szukasz informacji o zawaleniach natywnych. Ciąg znaków „*** ***” rzadko pojawia się w logach poza początkiem uruchamiania natywnej aplikacji.
Build fingerprint: 'Android/aosp_flounder/flounder:5.1.51/AOSP/enh08201009:eng/test-keys'
Odcisk palca pozwala określić, w której wersji wystąpiła awaria.
Jest to dokładnie to samo co usługa ro.build.fingerprint w systemie.
Revision: '0'
Wersja odnosi się do sprzętu, a nie oprogramowania. Zwykle nie jest używany, ale może być przydatny do automatycznego ignorowania błędów, które są spowodowane wadliwym sprzętem. Jest to dokładnie to samo co właściwość systemowa ro.revision.
ABI: 'arm'
Interfejs ABI może być arm, arm64, x86 lub x86-64. Jest to przydatne głównie w przypadku wspomnianego wyżej skryptu stack, aby wiedział, jakiej łańcucha narzędzi użyć.
pid: 1656, tid: 1656, name: crasher >>> crasher <<<
Ten wiersz wskazuje konkretny wątek w procesie, który uległ awarii. W tym przypadku był to główny wątek procesu, więc identyfikatory procesu i wątku są takie same. Pierwsza nazwa to nazwa wątku, a nazwa otoczona znakami >>> i <<< to nazwa procesu. W przypadku aplikacji nazwa procesu to zwykle pełna nazwa pakietu (np. com.facebook.katana), która jest przydatna podczas zgłaszania błędów lub próby znalezienia aplikacji w Google Play. Wartości pid i tid mogą też ułatwić znalezienie odpowiednich linii dziennika poprzedzających awarię.
signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
Ten wiersz informuje, który sygnał (SIGABRT) został odebrany, oraz więcej informacji o sposobie jego odbioru (SI_TKILL). Sygnały zgłaszane przez debuggerd to: SIGABRT, SIGBUS, SIGFPE, SIGILL, SIGSEGV i SIGTRAP. Kody poszczególnych sygnałów różnią się w zależności od konkretnego sygnału.
Abort message: 'some_file.c:123: some_function: assertion "false" failed'
Nie wszystkie awarie będą zawierać wiersz wiadomości o aborcji, ale awarie będą. Jest on automatycznie zbierany z ostatniego wiersza wyjścia fatalnego logcat dla tego PID/TID, a w przypadku celowego przerwania prawdopodobnie zawiera wyjaśnienie, dlaczego program się zamknął.
r0 00000000 r1 00000678 r2 00000006 r3 f70b6dc8 r4 f70b6dd0 r5 f70b6d80 r6 00000002 r7 0000010c r8 ffffffed r9 00000000 sl 00000000 fp ff96ae1c ip 00000006 sp ff96ad18 lr f700ced5 pc f700dc98 cpsr 400b0010
Zrzut rejestru pokazuje zawartość rejestrów procesora w momencie otrzymania sygnału. (Ta sekcja różni się znacznie w zależności od ABI) Ich przydatność zależy od konkretnej awarii.
backtrace:
#00 pc 00042c98 /system/lib/libc.so (tgkill+12)
#01 pc 00041ed1 /system/lib/libc.so (pthread_kill+32)
#02 pc 0001bb87 /system/lib/libc.so (raise+10)
#03 pc 00018cad /system/lib/libc.so (__libc_android_abort+34)
#04 pc 000168e8 /system/lib/libc.so (abort+4)
#05 pc 0001a78f /system/lib/libc.so (__libc_fatal+16)
#06 pc 00018d35 /system/lib/libc.so (__assert2+20)
#07 pc 00000f21 /system/xbin/crasher
#08 pc 00016795 /system/lib/libc.so (__libc_init+44)
#09 pc 00000abc /system/xbin/crasher
Zrzut stosu pokazuje, w którym miejscu kodu znajdowaliśmy się w momencie awarii. Pierwsza kolumna to numer kadru (zgodnie ze stylem gdb, w którym najgłębszy klatka ma numer 0). Wartości PC są względne w stosunku do lokalizacji zasobów wspólnych, a nie adresów bezwzględnych. Kolejna kolumna to nazwa zmapowanego regionu (zwykle jest to biblioteka współdzielona lub plik wykonywalny, ale nie dotyczy to na przykład kodu skompilowanego za pomocą JIT). Na koniec, jeśli symbole są dostępne, wyświetlany jest symbol, do którego odnosi się wartość PC
wraz ze przesunięciem w bajtach. Możesz użyć tego polecenia w połączeniu z poleceniem objdump(1), aby znaleźć odpowiednią instrukcję asemblera.
Czytanie elementów tombstone
Tombstone written to: /data/tombstones/tombstone_06
To pokazuje, gdzie debuggerd napisał dodatkowe informacje.
debuggerd będzie przechowywać do 10 tablic nagrobnych, przechodząc przez liczby od 00 do 09 i w razie potrzeby zastępując istniejące tablice.
Zawiera on te same informacje co zrzut awarii, a dodatkowo kilka dodatkowych. Obejmuje on na przykład ścieżki odzyskiwania dla wszystkich wątków (a nie tylko wątku, który uległ awarii), rejestrów zmiennoprzecinkowych, surowych zrzutów stosu oraz zrzutów pamięci w okolicach adresów w rejestrach. Najważniejsze jest to, że zawiera ona też pełną mapę pamięci (podobną do /proc/pid/maps). Oto adnotowany przykład z 32-bitowego procesu ARM, który uległ awarii:
memory map: (fault address prefixed with --->) --->ab15f000-ab162fff r-x 0 4000 /system/xbin/crasher (BuildId: b9527db01b5cf8f5402f899f64b9b121)
Należy zwrócić uwagę na 2 kwestie. Po pierwsze, przed tym wierszem znajduje się znak „--->”. Mapy są najbardziej przydatne, gdy awaria nie jest spowodowana tylko odwołaniem do wskaźnika null. Jeśli adres błędu jest mały, prawdopodobnie jest to jakaś odmiana odwoływania się do wskaźnika null. W przeciwnym razie możesz sprawdzić mapy w pobliżu adresu błędu, aby dowiedzieć się, co się stało. Oto niektóre możliwe problemy, które można zauważyć na mapach:
- Odczytuje/zapisuje dane poza końcem bloku pamięci.
- Czytanie/zapisywanie przed początkiem bloku pamięci.
- próby wykonania kodu niebędącego kodem,
- Wypełnianie do końca grupy.
- próbuje zapisać kod (jak w przykładzie powyżej).
Drugą rzeczą, o której warto pamiętać, jest to, że pliki wykonywalne i pliki bibliotek współdzielonych będą wyświetlać identyfikator kompilacji (jeśli jest dostępny) w Androidzie 6.0 lub nowszym, dzięki czemu możesz sprawdzić, która wersja kodu uległa awarii. Od Androida 6.0 binarne pliki platformy zawierają domyślnie identyfikator BuildId. NDK w wersji 12 i nowszej automatycznie przekazuje do linkera także parametr -Wl,--build-id.
ab163000-ab163fff r-- 3000 1000 /system/xbin/crasher ab164000-ab164fff rw- 0 1000 f6c80000-f6d7ffff rw- 0 100000 [anon:libc_malloc]
Na Androidzie stos nie musi być pojedynczym regionem. Regiony stosu będą oznaczone etykietą [anon:libc_malloc].
f6d82000-f6da1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 f6da2000-f6dc1fff r-- 0 20000 /dev/__properties__/u:object_r:default_prop:s0 f6dc2000-f6de1fff r-- 0 20000 /dev/__properties__/u:object_r:logd_prop:s0 f6de2000-f6de5fff r-x 0 4000 /system/lib/libnetd_client.so (BuildId: 08020aa06ed48cf9f6971861abf06c9d) f6de6000-f6de6fff r-- 3000 1000 /system/lib/libnetd_client.so f6de7000-f6de7fff rw- 4000 1000 /system/lib/libnetd_client.so f6dec000-f6e74fff r-x 0 89000 /system/lib/libc++.so (BuildId: 8f1f2be4b37d7067d366543fafececa2) (load base 0x2000) f6e75000-f6e75fff --- 0 1000 f6e76000-f6e79fff r-- 89000 4000 /system/lib/libc++.so f6e7a000-f6e7afff rw- 8d000 1000 /system/lib/libc++.so f6e7b000-f6e7bfff rw- 0 1000 [anon:.bss] f6e7c000-f6efdfff r-x 0 82000 /system/lib/libc.so (BuildId: d189b369d1aafe11feb7014d411bb9c3) f6efe000-f6f01fff r-- 81000 4000 /system/lib/libc.so f6f02000-f6f03fff rw- 85000 2000 /system/lib/libc.so f6f04000-f6f04fff rw- 0 1000 [anon:.bss] f6f05000-f6f05fff r-- 0 1000 [anon:.bss] f6f06000-f6f0bfff rw- 0 6000 [anon:.bss] f6f0c000-f6f21fff r-x 0 16000 /system/lib/libcutils.so (BuildId: d6d68a419dadd645ca852cd339f89741) f6f22000-f6f22fff r-- 15000 1000 /system/lib/libcutils.so f6f23000-f6f23fff rw- 16000 1000 /system/lib/libcutils.so f6f24000-f6f31fff r-x 0 e000 /system/lib/liblog.so (BuildId: e4d30918d1b1028a1ba23d2ab72536fc) f6f32000-f6f32fff r-- d000 1000 /system/lib/liblog.so f6f33000-f6f33fff rw- e000 1000 /system/lib/liblog.so
Biblioteka udostępniona ma zwykle 3 sąsiednie wpisy. Jeden jest czytelny i wykonalny (kod), drugi jest tylko do odczytu (dane tylko do odczytu), a trzeci jest do odczytu i zapisu (dane podlegające zmianom). Pierwsza kolumna zawiera zakresy adresów mapowania, druga – uprawnienia (w zwykłym formacie Unix ls(1)), trzecia – przesunięcie w pliku (w systemie szesnastkowym), czwarta – rozmiar regionu (w systemie szesnastkowym), a piąta – nazwę pliku (lub inną nazwę regionu).
f6f34000-f6f53fff r-x 0 20000 /system/lib/libm.so (BuildId: 76ba45dcd9247e60227200976a02c69b) f6f54000-f6f54fff --- 0 1000 f6f55000-f6f55fff r-- 20000 1000 /system/lib/libm.so f6f56000-f6f56fff rw- 21000 1000 /system/lib/libm.so f6f58000-f6f58fff rw- 0 1000 f6f59000-f6f78fff r-- 0 20000 /dev/__properties__/u:object_r:default_prop:s0 f6f79000-f6f98fff r-- 0 20000 /dev/__properties__/properties_serial f6f99000-f6f99fff rw- 0 1000 [anon:linker_alloc_vector] f6f9a000-f6f9afff r-- 0 1000 [anon:atexit handlers] f6f9b000-f6fbafff r-- 0 20000 /dev/__properties__/properties_serial f6fbb000-f6fbbfff rw- 0 1000 [anon:linker_alloc_vector] f6fbc000-f6fbcfff rw- 0 1000 [anon:linker_alloc_small_objects] f6fbd000-f6fbdfff rw- 0 1000 [anon:linker_alloc_vector] f6fbe000-f6fbffff rw- 0 2000 [anon:linker_alloc] f6fc0000-f6fc0fff r-- 0 1000 [anon:linker_alloc] f6fc1000-f6fc1fff rw- 0 1000 [anon:linker_alloc_lob] f6fc2000-f6fc2fff r-- 0 1000 [anon:linker_alloc] f6fc3000-f6fc3fff rw- 0 1000 [anon:linker_alloc_vector] f6fc4000-f6fc4fff rw- 0 1000 [anon:linker_alloc_small_objects] f6fc5000-f6fc5fff rw- 0 1000 [anon:linker_alloc_vector] f6fc6000-f6fc6fff rw- 0 1000 [anon:linker_alloc_small_objects] f6fc7000-f6fc7fff rw- 0 1000 [anon:arc4random _rsx structure] f6fc8000-f6fc8fff rw- 0 1000 [anon:arc4random _rs structure] f6fc9000-f6fc9fff r-- 0 1000 [anon:atexit handlers] f6fca000-f6fcafff --- 0 1000 [anon:thread signal stack guard page]
Od Androida 5.0 biblioteka C nazywa większość anonimowych zmapowanych regionów, więc jest mniej regionów tajemniczych.
f6fcb000-f6fccfff rw- 0 2000 [stack:5081]
Regiony o nazwie [stack:tid] to stosy dla podanych wątków.
f6fcd000-f702afff r-x 0 5e000 /system/bin/linker (BuildId: 84f1316198deee0591c8ac7f158f28b7) f702b000-f702cfff r-- 5d000 2000 /system/bin/linker f702d000-f702dfff rw- 5f000 1000 /system/bin/linker f702e000-f702ffff rw- 0 2000 f7030000-f7030fff r-- 0 1000 f7031000-f7032fff rw- 0 2000 ffcd7000-ffcf7fff rw- 0 21000 ffff0000-ffff0fff r-x 0 1000 [vectors]
To, czy widzisz [vector] czy [vdso], zależy od architektury. ARM używa [vector], a wszystkie inne architektury – [vdso].