Android 7 Crash natif: libc.so tgkill

Je vois ce crash natif avec la trace de stack suivante.

Cela se produit sous Android 7.0 et 7.1 uniquement. Rien de nouveau n’a été ajouté à l’application, qui est en production depuis quelques années, mais avec la mise à jour de plus de périphériques vers Nougat, cet incident se produit fréquemment maintenant et devient une nuisance.

Tout avis sera le bienvenu.

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) 

Voici une liste des périphériques qui sont effectués: entrer la description de l'image ici

MISE À JOUR 7/18:

Toujours incapable d’arriver à la racine, j’ai donc décidé d’acheter un appareil ayant le plus d’occurrences et à un prix raisonnable, qui s’est avéré être la version Samsung Galaxy J3 2017 avec Android 7.0. Mais malheureusement toujours incapable de reproduire le crash.

J’ai également apporté quelques améliorations à l’utilisation de la mémoire dans l’application en production, mais la panne persiste.

De tous les commentaires et de mes propres recherches, il semble que cela soit lié aux NDK liés dynamicment, mais je n’utilise aucun de ces éléments pour savoir si des dépendances existent.

J’aimerais partager mes dépendances, ce serait formidable si d’autres personnes confrontées au même problème pouvaient appeler si elles utilisaient l’une des mêmes dépendances – peut-être pourrions-nous identifier le coupable de cette façon.

 // App Compat comstack 'com.android.support:support-v4:23.0.1' comstack 'com.android.support:appcompat-v7:23.0.1' comstack 'com.android.support:cardview-v7:23.0.1' comstack 'com.android.support:recyclerview-v7:23.0.1' // Play Services comstack 'com.google.android.gms:play-services-location:8.3.0' comstack 'com.google.android.gms:play-services-maps:8.3.0' comstack 'com.google.android.gms:play-services-analytics:8.3.0' comstack 'com.google.android.gms:play-services-appindexing:8.3.0' comstack 'com.google.android.gms:play-services-ads:8.3.0' // Misc Libraries comstack 'fr.avianey.com.viewpagerindicator:library:2.4.1@aar' comstack files('app/libs/htmlcleaner-2.7.jar') comstack files('app/libs/protobuf-java-2.6.0.jar') comstack files('app/libs/nineoldandroids-2.4.0.jar') // Fabric comstack('com.twitter.sdk.android:twitter:1.13.0@aar') { transitive = true; } comstack('com.crashlytics.sdk.android:crashlytics:2.5.5@aar') { transitive = true; } 

Pour les personnes confrontées au même plantage, veuillez répondre dans les commentaires si vous utilisez l’une de ces dépendances / versions. Peut-être pouvons-nous distinguer la dépendance au problème.

En regardant la décharge que vous avez fournie, vous obtenez des indices:

_ZN7android10uirenderer12renderthread12RenderThread10threadLoopEv

Cela indique que l’erreur s’est produite dans le thread d’interface utilisateur.

libhwui.so x 6

Cela indique que cela se produit au milieu de certains codes graphiques / ui.

libcutils.so – __android_log_assert

Il s’agit d’un gestionnaire d’assertion, de sorte qu’il est fort probable qu’une sorte d’ libwhui été violée dans libwhui .

avorter:

C’est l’application qui demande à l’O / S de s’arrêter “de manière anormale”.

raise + pthread_kill + tgkill: C’est le O / S (Android) qui ferme l’application.

Vous pouvez voir de la documentation pour déboguer ces types de plantages ici .

Quoi qu’il en soit, je crains qu’il soit vraiment difficile de spéculer au-delà de cette interprétation grossière et imprécise des données que vous avez présentées.

Peut-être que si vous renconsortingez le bogue alors qu’il était attaché à la visionneuse de journaux Android, vous auriez plus de données spécifiques à l’application (ou même un message d’erreur que la fonction assert émet généralement).

Mon conseil est d’utiliser quelque chose comme AGRA pour retrouver tous les détails relatifs à l’erreur, ou obtenir un périphérique affecté et le reproduire en réalité lorsqu’il est attaché à un débogueur.

Bonne chance!

EDIT 2017-06-16 : Je veux juste append quelques commentaires de courtoisie supplémentaires de Fco P. Apparemment, Google a décidé d’apporter des modifications aux bibliothèques natives autorisées à utiliser les dernières versions d’Android (7.x). Plus de détails sont dans ce lien .

Ceci est rapporté ici: https://issuetracker.google.com/issues/37123764

Pour reproduire: Obtenez un mode affecté, activez le mode développeur et définissez les activités en arrière-plan sur 0. Activez également “Afficher les incidents en arrière-plan”.

Ensuite, ouvrez l’application et fermez-la à nouveau: vous verrez le crash.

Pas dans les commentaires (rep insuffisant).

Parmi les dépendances que vous avez répertoriées, nous utilisons:

 comstack 'com.android.support:cardview-v7:25.3.1' comstack 'com.android.support:appcompat-v7:25.3.1' comstack 'com.android.support:support-v4:25.3.1' comstack 'com.google.android.gms:play-services-maps:10.2.1' comstack 'com.google.android.gms:play-services-location:10.2.1' 

différentes versions que la vôtre. Je soupçonne fortement que play-services-maps contient le bogue.

Vous utilisez peut-être des fragments de carte dans viewpager et de nombreuses personnes en cause ont déjà été mentionnées par Koji Matsubara ( https://issuetracker.google.com/issues/37123764 )

Je ne sais pas, peut-être que ce problème comme le nôtre, peut-être différent, car je vois dans les dépendances avoir notamment carview . Partagez ici l’espoir utile pour quelqu’un à l’avenir

J’ai également rencontré le problème sur Android 7.0 et 7.1 ci-dessous

 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) 

Après des recherches et des recherches sur gooogle, j’ai remplacé cardview par Framelayout puis ce problème a été résolu

J’ai eu le même problème dans Google Play Console pour les mêmes appareils que vous.

Dans mon cas, le problème était dans TextureView avec une animation dans un thread séparé avec verrouiller et déverrouiller la canvas.

J’ai changé l’animation TextureView pour l’animation invalider-onDraw pour Android 7 et 7.1 et cela a aidé.