Natywna awaria systemu Android 7: libc.so tgkill


98

Widzę tę natywną awarię z następującym śladem stosu.

Dzieje się tak tylko w Androidzie 7.0 i 7.1. Nie dodano nic nowego do aplikacji, która była produkowana od kilku lat, ale wraz z aktualizacją większej liczby urządzeń do Nougat ta awaria zdarza się teraz często i staje się uciążliwa.

Każda rada będzie mile widziana.

native: pc 000000000007a6c4  /system/lib64/libc.so (tgkill+8)
  native: pc 0000000000077920  /system/lib64/libc.so (pthread_kill+64)
  native: pc 000000000002538c  /system/lib64/libc.so (raise+24)
  native: pc 000000000001d24c  /system/lib64/libc.so (abort+52)
  native: pc 000000000001225c  /system/lib64/libcutils.so (__android_log_assert+224)
  native: pc 00000000000610e0  /system/lib64/libhwui.so
  native: pc 000000000003908c  /system/lib64/libhwui.so
  native: pc 000000000003609c  /system/lib64/libhwui.so
  native: pc 000000000003b4fc  /system/lib64/libhwui.so
  native: pc 000000000003c520  /system/lib64/libhwui.so
  native: pc 000000000003e694  /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+152)
  native: pc 00000000000127f0  /system/lib64/libutils.so (_ZN7android6Thread11_threadLoopEPv+336)
  native: pc 00000000000a50b0  /system/lib64/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+116)
  native: pc 00000000000770f4  /system/lib64/libc.so (_ZL15__pthread_startPv+204)
  native: pc 000000000001e7d0  /system/lib64/libc.so (__start_thread+16)

Oto lista urządzeń, których dotyczy problem: wprowadź opis obrazu tutaj

AKTUALIZACJA 18.07:

Wciąż nie udało mi się dotrzeć do sedna tego problemu, dlatego zdecydowałem się na zakup urządzenia, które miało najwięcej wystąpień i było w rozsądnej cenie, którym okazał się Samsung Galaxy J3 2017 w wersji z systemem Android 7.0. Niestety nadal nie jestem w stanie odtworzyć awarii.

Wprowadziłem również pewne ulepszenia dotyczące zużycia pamięci w aplikacji w produkcji, ale awaria nadal ma miejsce.

Ze wszystkich komentarzy i moich własnych badań wynika, że ​​jest to związane z dynamicznie połączonymi NDK, ale nie używam żadnego i trudno jest dowiedzieć się, czy działa jakakolwiek z zależności.

Chciałbym podzielić się moimi zależnościami, byłoby wspaniale, gdyby inni ludzie borykający się z tym samym problemem mogli sprawdzić, czy używają jednej z tych samych zależności - być może w ten sposób możemy wykryć winowajcę.

// App Compat
    compile 'com.android.support:support-v4:23.0.1'
    compile 'com.android.support:appcompat-v7:23.0.1'
    compile 'com.android.support:cardview-v7:23.0.1'
    compile 'com.android.support:recyclerview-v7:23.0.1'

    // Play Services
    compile 'com.google.android.gms:play-services-location:8.3.0'
    compile 'com.google.android.gms:play-services-maps:8.3.0'
    compile 'com.google.android.gms:play-services-analytics:8.3.0'
    compile 'com.google.android.gms:play-services-appindexing:8.3.0'
    compile 'com.google.android.gms:play-services-ads:8.3.0'

    // Misc Libraries
    compile 'fr.avianey.com.viewpagerindicator:library:2.4.1@aar'
    compile files('app/libs/htmlcleaner-2.7.jar')
    compile files('app/libs/protobuf-java-2.6.0.jar')
    compile files('app/libs/nineoldandroids-2.4.0.jar')

    // Fabric
    compile('com.twitter.sdk.android:twitter:1.13.0@aar') { transitive = true; }
    compile('com.crashlytics.sdk.android:crashlytics:2.5.5@aar') { transitive = true; }

W przypadku osób, które stoją w obliczu tej samej awarii, prosimy o odpowiedź w komentarzach, jeśli używasz którejkolwiek z tych zależności / wersji. Może uda nam się wyodrębnić zależność od problemu.


6
Być może myślę, że twoja rodzima awaria to ten sam następujący problem. issuetracker.google.com/issues/37123764 Moja aplikacja ma podobny błąd, ale nie znajduję żadnego rozwiązania ... Myślę, że błąd Androida 7, 7.1.
Koji Matsubara

3
Widzę również to, dokładnie ten sam ślad stosu i dokładnie tę samą listę urządzeń, których dotyczy problem! Najnowsza wersja została opublikowana 15 maja, ale na stronie awarii są dwa wiersze o tej samej nazwie „tgkill”.
Orgmir

3
Doświadczam również tego samego problemu, dokładnie tego samego śladu stosu, dokładnie tych samych urządzeń, których dotyczy problem, używam zerowych bibliotek natywnych oraz korzystam z usług lokalizacji i map. Może to jest z tym związane? Czy ktoś ma rozwiązanie?
Cord Rehn,

3
W ciągu ostatnich 2 miesięcy mieliśmy ponad 30 000 tych awarii tgkill, które miały wpływ na ponad 14 000 użytkowników. Spędziłem ostatnie kilka tygodni na powolnym usuwaniu wszystkich bibliotek innych firm, z których korzystamy, i zwalnianiu wdrożeń etapowych, aby sprawdzić, czy mogę znaleźć przyczynę tych awarii. Wszystko zostało usunięte z wyjątkiem Retrofit, Okhttp, Jackson, Picasso, Firebase, Google Play Services, MultiDex i Apache Legacy. Na podstawie tego wątku rozmawiamy o udostępnieniu 1% naszych użytkowników po usunięciu naszych map. Obecnie działa: „com.google.android.gms: play-services-maps: 11.0.1”
FinHead

3
Udostępniliśmy wdrażanie etapowe, w którym usunęliśmy tylko „com.google.android.gms: play-services-maps: 11.0.1”. Po obejrzeniu go przez cały weekend nie było żadnych przypadków awarii tgkill. Tak, ten problem jest spowodowany przez mapy wspomniane przez @Deo i połączone z narzędziem do śledzenia problemów poniżej.
FinHead

Odpowiedzi:


33

Spojrzenie na dostarczony zrzut daje kilka wskazówek:

_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv

Oznacza to, że błąd wystąpił w wątku interfejsu użytkownika.

libhwui.so x 6

Oznacza to, że dzieje się to w środku kodu związanego z grafiką / interfejsem użytkownika.

libcutils.so - __android_log_assert

To jest program obsługi assertów, więc najprawdopodobniej został naruszony jakiś rodzaj asercji libwhui.

anulować:

Jest to aplikacja nakazująca systemowi operacyjnemu zamknięcie „nieprawidłowo”.

raise + pthread_kill + tgkill: To jest system operacyjny (Android) zamykający aplikację.

Możesz zobaczyć dokumentację dotyczącą debugowania tego rodzaju awarii tutaj .

W każdym razie obawiam się, że poza tą zgrubną i nieprecyzyjną interpretacją przedstawionych danych naprawdę trudno jest spekulować.

Może gdybyś złapał błąd, gdy był dołączony do przeglądarki dzienników Androida, miałbyś więcej danych specyficznych dla aplikacji (lub nawet komunikat o błędzie, który zwykle wyświetla funkcja assert).

Moja rada jest taka, aby użyć czegoś takiego jak ACRA, aby wyśledzić wszystkie szczegóły dotyczące błędu lub zdobyć urządzenie, którego dotyczy problem, i odtworzyć je po podłączeniu do debuggera.

Powodzenia!

EDYCJA 16.06.2017 : Chcę tylko dodać dodatkowe informacje dzięki uprzejmości Fco P. Najwyraźniej Google zdecydował się wprowadzić pewne zmiany w tym, jakie biblioteki natywne mogą działać w najnowszych wersjach Androida (7.x). Więcej szczegółów w tym linku .


raise + pthread_kill + tgkill: To jest system operacyjny (Android) zamykający aplikację. Czy dzieje się tak, gdy użytkownik zabija aplikację lub automatycznie z systemu operacyjnego?
DevC,

1
To jest system operacyjny, który wyłącza nieprawidłowo działający proces, o ile wiem. Gdyby aplikacja zakończyła się „pokojowo”, nie byłaby to operacja „zabicia”.
Lennart Rolland

8

To jest zgłaszane tutaj: https://issuetracker.google.com/issues/37123764

Aby odtworzyć: Uzyskaj tryb, na który ma to wpływ, włącz tryb programisty i ustaw działania w tle na 0. Włącz także opcję „Pokaż awarie w tle”.

Następnie otwórz aplikację i zamknij ją ponownie: zobaczysz awarię.


3

Brak komentarzy (niewystarczająca liczba powtórzeń).

Spośród wymienionych zależności używamy:

compile 'com.android.support:cardview-v7:25.3.1'
compile 'com.android.support:appcompat-v7:25.3.1'
compile 'com.android.support:support-v4:25.3.1'

compile 'com.google.android.gms:play-services-maps:10.2.1'
compile 'com.google.android.gms:play-services-location:10.2.1'

inne wersje niż twoja. Podejrzewam, że play-services-maps zawiera błąd.

Być może używasz fragmentu mapy w przeglądarce, tak jak my, a wiele osób, o których mowa, zostało już wspomniane przez Koji Matsubara ( https://issuetracker.google.com/issues/37123764 )


Czy znasz jakieś obejście, aby temu zapobiec na podstawie tego raportu o błędzie? Nie widzę żadnego rozwiązania, obejścia ani niczego.
hvaughan3

Mam ten sam problem, który dotyczy wszystkich moich aplikacji, jednak używam tylko bibliotek pomocniczych: adnotacji, wersji 4, zgodności z aplikacjami i projektowania.
3c71,

3

Nie wiem, może ten problem jak nasz, może inny, bo w zależnościach widzę w tym carview. Podziel się tutaj nadzieją przydatną dla kogoś w przyszłości

Napotkałem również problem na Androidzie 7.0 i 7.1 poniżej

03-04 23:44:51.489 2173-2173/? A/DEBUG: Abort message: 'Error: Ambient Vertex Buffer overflow!!! used 420, total 284'
03-04 23:44:51.489 2173-2173/? A/DEBUG:     eax 00000000  ebx 0000083b  ecx 00000857  edx 00000006
03-04 23:44:51.489 2173-2173/? A/DEBUG:     esi d19ff978  edi d19ff920
03-04 23:44:51.489 2173-2173/? A/DEBUG:     xcs 00000023  xds 0000002b  xes 0000002b  xfs 0000006b  xss 0000002b
03-04 23:44:51.489 2173-2173/? A/DEBUG:     eip f00a6bb9  ebp d19fee68  esp d19fee0c  flags 00000292
03-04 23:44:51.555 2173-2173/? A/DEBUG: backtrace:
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #00 pc 00000bb9  [vdso:f00a6000] (__kernel_vsyscall+9)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #01 pc 0007a2ec  /system/lib/libc.so (tgkill+28)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #02 pc 00075b35  /system/lib/libc.so (pthread_kill+85)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #03 pc 0002784a  /system/lib/libc.so (raise+42)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #04 pc 0001ee26  /system/lib/libc.so (abort+86)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #05 pc 0000fa65  /system/lib/libcutils.so (__android_log_assert+245)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #06 pc 00084356  /system/lib/libhwui.so
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #07 pc 0003a5ba  /system/lib/libhwui.so
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #08 pc 00083d04  /system/lib/libhwui.so
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #09 pc 0008c5df  /system/lib/libhwui.so
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #10 pc 0008e6d8  /system/lib/libhwui.so
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #11 pc 0008e5d2  /system/lib/libhwui.so
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #12 pc 000350fe  /system/lib/libhwui.so
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #13 pc 0001201f  /system/lib/libutils.so (_ZN7android6Thread11_threadLoopEPv+207)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #14 pc 0006e53b  /system/lib/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+111)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #15 pc 00011873  /system/lib/libutils.so (_ZN13thread_data_t10trampolineEPKS_+259)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #16 pc 00075292  /system/lib/libc.so (_ZL15__pthread_startPv+210)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #17 pc 0002028e  /system/lib/libc.so (__start_thread+30)
03-04 23:44:51.555 2173-2173/? A/DEBUG:     #18 pc 0001e066  /system/lib/libc.so (__bionic_clone+70)

Po badaniach i wyszukiwaniu w gooogle wymieniłem cardviewdo Framelayouttego czasu ten problem został rozwiązany


Cześć @ songoku1610, jak dowiedziałeś się, że problem jest spowodowany przez Cardview.
Ran94

1
Próbowałem zastąpić cardviewdo Framelayouttego czasu ten problem został rozwiązany, ten problem występuje tylko na Androidzie 7.x
songoku1610

Inna sprawa, powyższe pytanie zostało zredagowane, usunięto because I see in dependencies have including carview
zależność

3

Miałem ten sam problem w konsoli Google Play na tych samych urządzeniach co Ty.

W moim przypadku problem był w TextureView z animacją w osobnym wątku z blokowaniem i odblokowywaniem płótna.

Zmieniłem animację TextureView na animację invalidate-onDraw dla Androida 7 i 7.1 i to pomogło.


Moja aplikacja używa TextureView. Czy mógłbyś szerzej omówić animację invalidate-onDraw .
Shishir Shetty

@ShishirShetty Nie używam już TextureView Nadpisuję View, opisuję wszystkie animacje w metodzie onDraw i wywołuję metodę postInvalidateOnAnimation () co 16 milisekund (~ 60fps)
Sergei Belozerov

-1

Widzę ten problem z raportu o awarii na urządzeniu jednego użytkownika - „Huawei Honor 7X (HWBND-H)” - z systemem Android 8.0. Ponieważ nie występuje w terenie dla innych urządzeń / wersji systemu operacyjnego, myślę, że mogło to już zostać naprawione w aktualizacjach systemu operacyjnego (których ten użytkownik nie odebrał lub prawdopodobnie Huawei nie dostarczył).

backtrace:
  #00  pc 000000000006a808  /system/lib64/libc.so (tgkill+8)
  #01  pc 000000000001db50  /system/lib64/libc.so (abort+88)
  #02  pc 0000000000007f4c  /system/lib64/liblog.so (__android_log_assert+304)
  #03  pc 000000000004e314  /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread10EglManager13createSurfaceEP13ANativeWindow+192)
  #04  pc 000000000004c790  /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread14OpenGLPipeline10setSurfaceEPNS_7SurfaceENS1_12SwapBehaviorE+64)
  #05  pc 00000000000492b4  /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread13CanvasContext10setSurfaceEPNS_7SurfaceE+140)
  #06  pc 000000000005123c  /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthreadL17Bridge_initializeEPNS1_14initializeArgsE+16)
  #07  pc 0000000000052fc4  /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread22MethodInvokeRenderTask3runEv+24)
  #08  pc 0000000000053f1c  /system/lib64/libhwui.so (_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv+348)
  #09  pc 0000000000011670  /system/lib64/libutils.so (_ZN7android6Thread11_threadLoopEPv+280)
  #10  pc 00000000000be1e8  /system/lib64/libandroid_runtime.so (_ZN7android14AndroidRuntime15javaThreadShellEPv+136)
  #11  pc 00000000000671b8  /system/lib64/libc.so (_ZL15__pthread_startPv+36)
  #12  pc 000000000001eee4  /system/lib64/libc.so (__start_thread+68)
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.