Signal fatal Android 11 (SIGSEGV) à 0x636f7d89 (code = 1). Comment peut-il être retrouvé?
J'ai lu les autres articles sur la recherche des raisons pour obtenir une SIGSEGV dans une application Android. Je prévois de parcourir mon application à la recherche de NullPointers possibles liés à l'utilisation de Canvas, mais ma SIGSEGV affiche une adresse mémoire différente à chaque fois. De plus, j'ai vu code=1 et code=2. Si l'adresse mémoire était 0x00000000, j'aurais une idée qu'il s'agit d'un NullPointer.
Le dernier que j'ai eu était un code=2:
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
Des suggestions sur la façon de dépister cela?
J'ai un suspect, mais je ne veux pas encore en faire l'expérience. Mon application utilise l'API OSMDroid pour le mappage hors ligne. La classe OverlayItem représente les marqueurs/nœuds sur la carte. J'ai un service qui collecte des données via le réseau pour renseigner le OverlayItem qui sont ensuite affichés sur la carte. Afin de simplifier ma conception, j'ai étendu OverlayItem dans ma propre classe NodeOverlayItem, qui comprend certains attributs supplémentaires que j'utilise dans l'activité d'interface utilisateur et dans le service. Cela m'a donné un seul point d'informations sur les éléments pour l'interface utilisateur et le service. J'ai utilisé Intents pour diffuser vers l'activité afin d'actualiser la carte d'interface utilisateur lorsque quelque chose a changé. L'activité se lie au service et une méthode de service permet d'obtenir la liste des objets NodeOverlayItem. Je pense que cela pourrait être l'utilisation de OverlayItem par l'API OSMDroid et que mon service met à jour les informations de nœud en même temps. (un problème de concurrence)
Au moment où j'écris ceci, je pense que c'est vraiment le problème. Le mal de tête ne consiste pas à séparer le nœud et les couches superposées de NodeOverlayItem, c'est que l'activité nécessitera des données du nœud, que le service détient. De plus, lors de la création de l'activité (onResume, etc.), les objets OverlayItem devront être recréés à partir des données de nœud gérées par le service pendant la durée de l'activité. par exemple. Vous démarrez l'application, le service collecte des données, l'interface utilisateur l'affiche, vous accédez à Accueil, puis vous revenez à l'application. L'activité devra extraire et recréer les données OverlayItem à partir des dernières données du nœud de service.
Je sais que ce n'est pas une grande ou des questions claires. C'est comme si toutes mes SO questions sont niches ou obscures. Si quelqu'un a une suggestion sur la façon d'interpréter ces erreurs SIGSEGV, ce serait grandement apprécié!
UPDATE Voici le dernier crash capturé lors d'une session de débogage. Trois de ces périphériques sont utilisés pour les tests et ils ne tombent pas tous en panne de manière fiable lorsque je développe et teste. J'ai inclus un peu plus pour que l'enregistrement du GC puisse être noté. Vous pouvez voir que le problème n'est probablement pas lié à l'épuisement de la mémoire.
03-03 02:02:38.328: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.328: I/CommService(7477): Already processed this packet. It's a re-broadcast from another node, or from myself. It's not a repeat broadcast though.
03-03 02:02:38.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:38.460: D/CommService(7477): Monitoring nodes...
03-03 02:02:38.515: D/dalvikvm(7477): GC_CONCURRENT freed 2050K, 16% free 17151K/20359K, paused 3ms+6ms
03-03 02:02:38.515: I/CommService(7477): Received packet from: 192.168.1.102
03-03 02:02:38.515: D/CommService(7477): Forwarding packet (4f68802cf10684a83ac4936ebb3c934d) along to other nodes.
03-03 02:02:38.609: I/CommService(7477): Received packet from: 192.168.1.100
03-03 02:02:38.609: D/CommService(7477): Forwarding packet (e4bc81e91ec92d06f83e03068f52ab4) along to other nodes.
03-03 02:02:38.609: D/CommService(7477): Already processed this packet: 4204a5b27745ffe5e4f8458e227044bf
03-03 02:02:38.609: A/libc(7477): Fatal signal 11 (SIGSEGV) at 0x68f52abc (code=1)
03-03 02:02:38.914: I/DEBUG(4008): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
03-03 02:02:38.914: I/DEBUG(4008): Build fingerprint: 'Lenovo/IdeaTab_A1107/A1107:4.0.4/MR1/eng.user.20120719.150703:user/release-keys'
03-03 02:02:38.914: I/DEBUG(4008): pid: 7477, tid: 7712 >>> com.test.testm <<<
03-03 02:02:38.914: I/DEBUG(4008): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 68f52abc
03-03 02:02:38.914: I/DEBUG(4008): r0 68f52ab4 r1 412ef268 r2 4d9c3bf4 r3 412ef268
03-03 02:02:38.914: I/DEBUG(4008): r4 001ad8f8 r5 4d9c3bf4 r6 412ef268 r7 4c479df8
03-03 02:02:38.914: I/DEBUG(4008): r8 4d9c3c0c r9 4c479dec 10 46cf260a fp 4d9c3c24
03-03 02:02:38.914: I/DEBUG(4008): ip 40262a04 sp 4d9c3bc8 lr 402d01dd pc 402d0182 cpsr 00000030
03-03 02:02:38.914: I/DEBUG(4008): d0 00000001000c0102 d1 3a22364574614c7d
03-03 02:02:38.914: I/DEBUG(4008): d2 403fc0000000007d d3 363737343433350a
03-03 02:02:38.914: I/DEBUG(4008): d4 49544341223a2273 d5 6f6567222c224556
03-03 02:02:38.914: I/DEBUG(4008): d6 3a223645676e6f4c d7 000000013835372d
03-03 02:02:38.914: I/DEBUG(4008): d8 0000000000000000 d9 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008): d10 0000000000000000 d11 4040000000000000
03-03 02:02:38.914: I/DEBUG(4008): d12 4040000000000000 d13 0000000000000021
03-03 02:02:38.914: I/DEBUG(4008): d14 0000000000000000 d15 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008): d16 3fe62e42fefa39ef d17 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d18 3fe62e42fee00000 d19 0000000000000000
03-03 02:02:38.914: I/DEBUG(4008): d20 0000000000000000 d21 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d22 4028000000000000 d23 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d24 0000000000000000 d25 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d26 0000000000000000 d27 c028000000000000
03-03 02:02:38.914: I/DEBUG(4008): d28 0000000000000000 d29 3ff0000000000000
03-03 02:02:38.914: I/DEBUG(4008): d30 3ff0000000000000 d31 3fecccccb5c28f6e
03-03 02:02:38.914: I/DEBUG(4008): scr 60000013
03-03 02:02:39.046: I/DEBUG(4008): #00 pc 0006b182 /system/lib/libcrypto.so (EVP_DigestFinal_ex)
03-03 02:02:39.046: I/DEBUG(4008): #01 pc 0006b1d8 /system/lib/libcrypto.so (EVP_DigestFinal)
03-03 02:02:39.054: I/DEBUG(4008): #02 pc 0001f814 /system/lib/libnativehelper.so
03-03 02:02:39.054: I/DEBUG(4008): #03 pc 0001ec30 /system/lib/libdvm.so (dvmPlatformInvoke)
03-03 02:02:39.054: I/DEBUG(4008): #04 pc 00058c70 /system/lib/libdvm.so (_Z16dvmCallJNIMethodPKjP6JValuePK6MethodP6Thread)
03-03 02:02:39.054: I/DEBUG(4008): code around pc:
03-03 02:02:39.054: I/DEBUG(4008): 402d0160 0003151e 4604b570 f7ff460d 4620ff81 ....p..F.F.... F
03-03 02:02:39.054: I/DEBUG(4008): 402d0170 f7ff4629 bd70ff93 4604b570 460e6800 )F....p.p..F.h.F
03-03 02:02:39.054: I/DEBUG(4008): 402d0180 68834615 dd062b40 21fa4810 44784a10 .F.h@+...H.!.JxD
03-03 02:02:39.054: I/DEBUG(4008): 402d0190 f7c8447a 6821f80f 698a4620 47904631 zD....!h F.i1F.G
03-03 02:02:39.054: I/DEBUG(4008): 402d01a0 b1154606 68836820 6822602b b12b6a13 .F.. h.h+`"h.j+.
03-03 02:02:39.054: I/DEBUG(4008): code around lr:
03-03 02:02:39.054: I/DEBUG(4008): 402d01bc 68e06821 21006c4a ea0af7c4 bd704630 !h.hJl.!....0Fp.
03-03 02:02:39.054: I/DEBUG(4008): 402d01cc 00031492 000314b5 4604b570 ffcef7ff ........p..F....
03-03 02:02:39.054: I/DEBUG(4008): 402d01dc 46204605 ff12f7ff bd704628 4604b573 .F F....(Fp.s..F
03-03 02:02:39.054: I/DEBUG(4008): 402d01ec 2102460d fb36f002 42ab6823 b123d020 .F.!..6.#h.B .#.
03-03 02:02:39.054: I/DEBUG(4008): 402d01fc b1136c5b f7c868e0 68a0fccf 05c26025 [l...h.....h%`..
03-03 02:02:39.054: I/DEBUG(4008): memory map around addr 68f52abc:
03-03 02:02:39.054: I/DEBUG(4008): 4d8c5000-4d9c4000
03-03 02:02:39.054: I/DEBUG(4008): (no map for address)
03-03 02:02:39.054: I/DEBUG(4008): b0001000-b0009000 /system/bin/linker
03-03 02:02:39.054: I/DEBUG(4008): stack:
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b88 408d1f90 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b8c 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b90 00000001
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b94 408d6c58 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b98 408d6fa8 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3b9c 4c479dec
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba0 46cf260a /system/framework/core.odex
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba4 408735e7 /system/lib/libdvm.so
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3ba8 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bac 002bf070 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb0 412ef258 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb4 00000000
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bb8 412ef268 /dev/ashmem/dalvik-heap (deleted)
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bbc 00000000
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bc0 df0027ad
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bc4 00000000
03-03 02:02:39.054: I/DEBUG(4008): #00 4d9c3bc8 001ad8f8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bcc 002ae0b8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bd0 00000004
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bd4 402d01dd /system/lib/libcrypto.so
03-03 02:02:39.054: I/DEBUG(4008): #01 4d9c3bd8 001ad8f8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3bdc 002ae0b8 [heap]
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3be0 00000004
03-03 02:02:39.054: I/DEBUG(4008): 4d9c3be4 4024e817 /system/lib/libnativehelper.so
03-03 02:02:39.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:39.500: D/CommService(7477): Monitoring nodes...
03-03 02:02:39.500: D/dalvikvm(7477): GC_FOR_ALLOC freed 2073K, 16% free 17118K/20359K, paused 51ms
03-03 02:02:39.632: D/dalvikvm(7477): GC_CONCURRENT freed 1998K, 16% free 17162K/20359K, paused 2ms+4ms
03-03 02:02:40.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:40.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:40.562: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17158K/20359K, paused 3ms+4ms
03-03 02:02:41.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:41.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:41.531: D/dalvikvm(7477): GC_CONCURRENT freed 2045K, 16% free 17154K/20359K, paused 3ms+12ms
03-03 02:02:42.406: D/CommService(7477): Checking OLSRd info...
03-03 02:02:42.445: D/CommService(7477): Monitoring nodes...
03-03 02:02:42.507: D/dalvikvm(7477): GC_CONCURRENT freed 2068K, 16% free 17128K/20359K, paused 3ms+4ms
03-03 02:02:42.679: D/dalvikvm(7477): GC_CONCURRENT freed 2006K, 16% free 17161K/20359K, paused 2ms+12ms
03-03 02:02:43.140: I/BootReceiver(1236): Copying /data/tombstones/tombstone_05 to DropBox (SYSTEM_TOMBSTONE)
03-03 02:02:43.210: D/dalvikvm(1236): GC_FOR_ALLOC freed 912K, 17% free 10207K/12295K, paused 62ms
03-03 02:02:43.265: D/dalvikvm(1236): GC_FOR_ALLOC freed 243K, 16% free 10374K/12295K, paused 49ms
03-03 02:02:43.265: I/dalvikvm-heap(1236): Grow heap (frag case) to 10.507MB for 196628-byte allocation
D'ACCORD! Je suis vraiment désolé pour ceux qui ont réellement soumis des commentaires et des réponses, mais j'ai trouvé le problème. Je ne pense pas que cela aidera beaucoup d’autres à essayer de retrouver leur SIGSEGV personnel, mais le mien (et c’était très difficile) était entièrement lié à ceci:
https://code.google.com/p/Android/issues/detail?id=8709
Le type libcrypto.so de mon fichier mémoire m'a indiqué. Je fais un hachage MD5 de données par paquets lorsque je tente de déterminer si j'ai déjà vu le paquet et de le sauter, le cas échéant. Je pensais à un moment que c’était un vilain problème de thread lié au suivi de ces hachages, mais il s’est avéré qu’il s’agissait de la classe Java.security.MessageDigest! Ce n'est pas thread-safe!
Je l'ai échangé avec un UID que je mettais dans chaque paquet en fonction de l'UUID du périphérique et d'un horodatage. Aucun problème depuis.
Je pense que la leçon que je peux donner à ceux qui se trouvaient dans ma situation est que, même si vous êtes une application 100% Java, faites attention à la bibliothèque native et au symbole indiqué dans le vidage mémoire sur incident pour obtenir des indices. Googler pour SIGSEGV + le nom de la lib .so ira beaucoup plus loin que le code inutile = 1, etc. ... Pensez ensuite aux endroits où votre application Java pourrait toucher le code natif, même si vous ne faites rien. J'ai commis l'erreur de supposer qu'il s'agissait d'un problème de filetage Service + UI où le canevas dessinait quelque chose qui était nul (le cas le plus fréquent, j'ai cherché sur SIGSEGV) et ai ignoré la possibilité que cela ait été complètement lié au code que j'avais écrit liée à la lib .so dans le vidage sur incident. Naturellement, Java.security utiliserait un composant natif de libcrypto.so pour plus de rapidité, alors une fois que j’ai été informé, j’ai cherché Google pour Android + SIGSEGV + libcrypto.so et trouvé le problème documenté. Bonne chance!
Tout d’abord, obtenez votre trace de pile de pierres tombales, elle sera imprimée chaque fois que votre application se bloque. Quelque chose comme ça:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'XXXXXXXXX'
pid: 1658, tid: 13086 >>> system_server <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 64696f7e
r0 00000000 r1 00000001 r2 ad12d1e8 r3 7373654d
r4 64696f72 r5 00000406 r6 00974130 r7 40d14008
r8 4b857b88 r9 4685adb4 10 00974130 fp 4b857ed8
ip 00000000 sp 4b857b50 lr afd11108 pc ad115ebc cpsr 20000030
d0 4040000040000000 d1 0000004200000003
d2 4e72cd924285e370 d3 00e81fe04b1b64d8
d4 3fbc71c7009b64d8 d5 3fe999999999999a
d6 4010000000000000 d7 4000000000000000
d8 4000000000000000 d9 0000000000000000
d10 0000000000000000 d11 0000000000000000
d12 0000000000000000 d13 0000000000000000
d14 0000000000000000 d15 0000000000000000
scr 80000012
#00 pc 000108d8 /system/lib/libc.so
#01 pc 0003724c /system/lib/libxvi020.so
#02 pc 0000ce02 /system/lib/libxvi020.so
#03 pc 0000d672 /system/lib/libxvi020.so
#04 pc 00010cce /system/lib/libxvi020.so
#05 pc 00004432 /system/lib/libwimax_jni.so
#06 pc 00011e74 /system/lib/libdvm.so
#07 pc 0004354a /system/lib/libdvm.so
#08 pc 00017088 /system/lib/libdvm.so
#09 pc 0001c210 /system/lib/libdvm.so
#10 pc 0001b0f8 /system/lib/libdvm.so
#11 pc 00059c24 /system/lib/libdvm.so
#12 pc 00059e3c /system/lib/libdvm.so
#13 pc 0004e19e /system/lib/libdvm.so
#14 pc 00011b94 /system/lib/libc.so
#15 pc 0001173c /system/lib/libc.so
code around pc:
ad115e9c 4620eddc bf00bd70 0001736e 0001734e
ad115eac 4605b570 447c4c0a f7f44620 e006edc8
ad115ebc 42ab68e3 68a0d103 f7f42122 6864edd2
ad115ecc d1f52c00 44784803 edbef7f4 bf00bd70
ad115edc 00017332 00017312 2100b51f 46682210
code around lr:
afd110e8 e2166903 1a000018 e5945000 e1a02004
afd110f8 e2055a02 e1a00005 e3851001 ebffed92
afd11108 e3500000 13856002 1a000001 ea000009
afd11118 ebfffe50 e1a01004 e1a00006 ebffed92
afd11128 e1a01005 e1550000 e1a02006 e3a03000
stack:
4b857b10 40e43be8
4b857b14 00857280
4b857b18 00000000
4b857b1c 034e8968
4b857b20 ad118ce9 /system/lib/libnativehelper.so
4b857b24 00000002
4b857b28 00000406
Utilisez ensuite l'utilitaire addr2line (recherchez-le dans votre chaîne d'outils NDK) pour rechercher la fonction qui se bloque. Dans cet exemple, vous faites
addr2line -e -f libc.so 0001173c
Et vous verrez où vous avez eu le problème. Bien sûr, cela ne vous aidera pas car il est dans libc.
Vous pouvez donc combiner les utilitaires de arm-eabi-objdump pour trouver la cible finale.
Croyez-moi, c'est une tâche difficile.
Juste pour une mise à jour. Je pense que je construisais depuis un certain temps, depuis l’arborescence source entière, la compilation native sur Android, et jusqu’à aujourd’hui, j’ai moi-même lu attentivement les documents NDK. Depuis la publication de NDK-r6, il fournit un utilitaire appelé ndk-stack.
Vous trouverez ci-dessous le contenu des documents NDK officiels contenant la balle de goudron NDK-r9.
Aperçu:
ndk-stack est un outil simple qui vous permet de filtrer les traces de pile telles qu'elles apparaissent dans le résultat de 'adb logcat' et de remplacer toute adresse dans une bibliothèque partagée par les valeurs correspondantes:.
En un mot, cela traduira quelque chose comme:
I/DEBUG ( 31): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 31): Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
I/DEBUG ( 31): pid: 351, tid: 351 %gt;%gt;%gt; /data/local/ndk-tests/crasher <<<
I/DEBUG ( 31): signal 11 (SIGSEGV), fault addr 0d9f00d8
I/DEBUG ( 31): r0 0000af88 r1 0000a008 r2 baadf00d r3 0d9f00d8
I/DEBUG ( 31): r4 00000004 r5 0000a008 r6 0000af88 r7 00013c44
I/DEBUG ( 31): r8 00000000 r9 00000000 10 00000000 fp 00000000
I/DEBUG ( 31): ip 0000959c sp be956cc8 lr 00008403 pc 0000841e cpsr 60000030
I/DEBUG ( 31): #00 pc 0000841e /data/local/ndk-tests/crasher
I/DEBUG ( 31): #01 pc 000083fe /data/local/ndk-tests/crasher
I/DEBUG ( 31): #02 pc 000083f6 /data/local/ndk-tests/crasher
I/DEBUG ( 31): #03 pc 000191ac /system/lib/libc.so
I/DEBUG ( 31): #04 pc 000083ea /data/local/ndk-tests/crasher
I/DEBUG ( 31): #05 pc 00008458 /data/local/ndk-tests/crasher
I/DEBUG ( 31): #06 pc 0000d362 /system/lib/libc.so
I/DEBUG ( 31):
Dans la sortie plus lisible:
********** Crash dump: **********
Build fingerprint: 'generic/google_sdk/generic/:2.2/FRF91/43546:eng/test-keys'
pid: 351, tid: 351 >>> /data/local/ndk-tests/crasher <<<
signal 11 (SIGSEGV), fault addr 0d9f00d8
Stack frame #00 pc 0000841e /data/local/ndk-tests/crasher : Routine Zoo in /tmp/foo/crasher/jni/Zoo.c:13
Stack frame #01 pc 000083fe /data/local/ndk-tests/crasher : Routine bar in /tmp/foo/crasher/jni/bar.c:5
Stack frame #02 pc 000083f6 /data/local/ndk-tests/crasher : Routine my_comparison in /tmp/foo/crasher/jni/foo.c:9
Stack frame #03 pc 000191ac /system/lib/libc.so
Stack frame #04 pc 000083ea /data/local/ndk-tests/crasher : Routine foo in /tmp/foo/crasher/jni/foo.c:14
Stack frame #05 pc 00008458 /data/local/ndk-tests/crasher : Routine main in /tmp/foo/crasher/jni/main.c:19
Stack frame #06 pc 0000d362 /system/lib/libc.so
Utilisation:
Pour ce faire, vous aurez d’abord besoin d’un répertoire contenant les versions symboliques des bibliothèques partagées de votre application. Si vous utilisez le système de compilation NDK (c'est-à-dire ndk-build), ils se trouvent toujours sous $ PROJECT_PATH/obj/local /, où correspond à l'ABI de votre périphérique (par exemple, armeabi par défaut).
Vous pouvez insérer le texte logcat en entrée directe dans le programme, par exemple:
adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi
Ou vous pouvez utiliser l'option -dump pour spécifier le logcat en tant que fichier d'entrée, par exemple:
adb logcat > /tmp/foo.txt
$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt
IMPORTANT:
L’outil recherche la ligne initiale contenant les débuts dans la sortie logcat, c’est-à-dire quelque chose qui ressemble à:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Lorsque vous copiez/collez des traces, n'oubliez pas cette ligne, sinon ndk-stack ne fonctionnera pas correctement.
FAIRE:
Une version ultérieure de ndk-stack tentera de lancer adb logcat et de sélectionner automatiquement le chemin de la bibliothèque. Pour l'instant, vous devrez suivre ces étapes manuellement.
ndk-stack ne gère pas les bibliothèques ne contenant pas d'informations de débogage. Il peut être utile de tenter de détecter le point d’entrée de fonction le plus proche d’une adresse PC donnée (par exemple, comme dans l’exemple de libc.so ci-dessus).
J'obtenais cette erreur en enregistrant un objet dans les préférences partagées sous forme de chaîne convertie par gson. La chaîne gson n'était pas bonne, donc récupérer et désérialiser l'objet ne fonctionnait pas correctement. Cela signifiait que tous les accès ultérieurs à l'objet entraînaient cette erreur. Effrayant :)
J'ai aussi eu cette erreur plusieurs fois et je l'ai résolue ..___ Cette erreur sera rencontrée en cas de gestion de la mémoire en natif.
Votre application accède à la mémoire en dehors de son espace d'adressage. C'est très probablement un accès de pointeur invalide. SIGSEGV = erreur de segmentation en code natif. Comme cela ne se produit pas dans le code Java, vous ne verrez pas de trace de pile avec des détails. Cependant, vous pouvez toujours voir des informations de trace de pile dans le logcat si vous regardez un peu après le blocage du processus d'application. Il ne vous indiquera pas le numéro de ligne dans le fichier, mais vous indiquera quels fichiers et adresses d'objets étaient utilisés dans la chaîne d'appels. À partir de là, vous pouvez souvent déterminer quelle partie du code est problématique. Vous pouvez également configurer une connexion native gdb au processus cible et l'attraper dans le débogueur.
Aujourd'hui, j'ai été confronté au problème Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161 et je me suis battu une demi-journée pour le résoudre.
J'ai essayé beaucoup de choses en effaçant le cache et en supprimant le fichier .gradle et tout.
Enfin je disable Instant Run et maintenant je ne reçois plus ce problème. Maintenant, mon application fonctionne après avoir activé l'exécution instantanée également. Il peut s'agir du problème d'exécution instantanée. Essayez de désactiver et d'activer l'exécution instantanée.
Essayez de désactiver l'accélération matérielle Android dans votre manifeste.
Android:hardwareAccelerated="false"
J'ai rencontré cette erreur lorsque j'ai essayé d'accéder à la "zone de travail" en dehors de onDraw()
private Canvas canvas;
@Override
protected void onDraw(Canvas canvas) {
this.canvas = canvas;
....... }
private class ScaleListener extends ScaleGestureDetector.SimpleOnScaleGestureListener {
@Override
public boolean onScale(ScaleGestureDetector detector) {
canvas.save(); // here
Une très mauvaise pratique: /
J'obtenais cette erreur en utilisant un bitmap comme celui-ci:
bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);
Ce qui a résolu le problème pour moi, c’est de réduire la taille du bitmap (> 1000 pixels de haut à 700 pixels).
J'ai fait face à SIGSEGV sur Android 4.4.4 (Nexuses, Samsungs) Et il s'est avéré qu'une erreur fatale était dans l'analyse de nullString en utilisant DecimalFormat
static DecimalFormat decimalFormat = new DecimalFormat("###,###.###");
void someMethod(String value) {
...
Number number = decimalFormat.parse(value);//value is null, SIGSEGV will happen`
...
}
Sur Android> 21, cela a été géré avec succès avec try/catch
Si vous utilisez la bibliothèque vitamio et que cette erreur fatale se produit.
Assurez-vous ensuite que, dans votre projet, targetSdkVersion doit être inférieur à 23.
merci.
J'ai rencontré ce problème il y a un moment, après avoir migré de Android.support à androidx.
Le problème était renderscript.
Solution: J'ai supprimé de mon build.gradle ces deux lignes:
renderscriptTargetApi 21
renderscriptSupportModeEnabled true
après que la construction du projet ait échoué, à cause de références non résolues:
import androidx.renderscript.Allocation;
import androidx.renderscript.Element;
import androidx.renderscript.RenderScript;
import androidx.renderscript.ScriptIntrinsicBlur;
donc je les ai changés en:
import Android.renderscript.Allocation;
import Android.renderscript.Element;
import Android.renderscript.RenderScript;
import Android.renderscript.ScriptIntrinsicBlur;
Après cela, tous les problèmes ont disparu.
Pour moi, ce problème était dû à une mauvaise conversion entre deux activités ..__ J'ai récemment déplacé cette méthode de Activité1 à une autre 2. Ce faisant, le refactor a laissé cette distribution explicite telle qu'elle était auparavant. Donc au lieu de faire
((Activity1) mainActivity).hideDialog();
Je devais faire
((Activity2) mainActivity).hideDialog();
Remarque: Mais cette erreur ne s'est pas produite sur Android 8.0, je ne sais pas encore pourquoi.
*** J'espère que ça aide.
Vérifiez votre code JNI/natif. Une de mes références était nulle, mais c'était intermittent, donc ce n'était pas très évident.
Construisez l'empreinte digitale: 'Motorola/harpia/harpia: 6.0.1/MPIS24.241-2.50-16/16: clé utilisateur/relâchement' Révision: 'p1b0' ABI: 'arm' pid: 18139, tid: 25935, nom: GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<< signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), adresse de faute 0x7452f000
2 téléphones sur 12 ont renvoyé une erreur, le problème était lié à onDrawFrame (), certains objets étaient nuls, je ne sais pas pourquoi, je viens de définir
if(gears==null) return;.
J'ai eu cette erreur lorsque j'ai utilisé ViewTreeObserver dans la fonction onDraw().
@Override
protected void onDraw(Canvas canvas) {
// super.onDraw(canvas);
ViewTreeObserver vto = mTextView.getViewTreeObserver();
vto.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
@Override
public void onGlobalLayout() {
// some animation
}
});
}
Dans mon cas, le problème était causé par le profileur Android. Dans Android Studio, cliquez sur "Android Profiler" et "end session".
Ironiquement, cela causait également des problèmes de performances extrêmes dans l'application.
vérifiez vos fonctions natives, si elles retournent correctement ou non. Si elles ne sont pas renvoyées, ajoutez des instructions de retour.
J'ai eu cette erreur de faute de segmentation en raison de Problèmes de mémoire . Mon struct ayant de nombreuses variables et tableaux, avait ce tableau de taille 1024.
En réduisant la taille à 512, l'erreur avait disparu.
P.S: Ceci est une solution de contournement et non une solution. Il est nécessaire de trouver la taille de la structure et l’allocation dynamique de mémoire .__ est une meilleure option.
Dans mon cas (j'utilise Xamarin Forms), cette erreur a été générée en raison d'une erreur de liaison - par ex. :
<Label Grid.Column="4" Grid.Row="1" VerticalTextAlignment="Start" HorizontalTextAlignment="Center" VerticalOptions="Start" HorizontalOptions="Start" FontSize="10" TextColor="Pink" Text="{Binding }"></Label>
Fondamentalement, j'ai supprimé la propriété du modèle de vue par erreur. Pour les développeurs Xamarin, si vous rencontrez le même problème, vérifiez vos liaisons ...
J'ai eu ce problème avec un paquet qui a été ajouté à mon application (FancyShowCaseView) et a causé ce problème sur le pré-lolipop. ce paquet a été écrit en kotlin et mes codes principaux ont été écrits en Java. donc maintenant je vérifie la version en pré-lolipop et ne laisse pas sa classe s'exécuter. temporaire a résolu le problème. vérifier ceci si vous avez le même problème que moi