Android Fatal signal 11 (SIGSEGV) на 0x636f7d89 (код = 1). Как его можно отследить?
Я читал другие сообщения по отслеживанию причин получения SIGSEGV
в приложении для Android. Я планирую вычеркнуть свое приложение для возможных NullPointers, связанных с использованием Canvas, но мой SIGSEGV
каждый раз заполняет другой адрес памяти. Плюс я видел code=1
и code=2
. Если адрес памяти был 0x00000000
, я бы понял, что это NullPointer.
Последний, который я получил, был code=2
:
A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)
Любые предложения о том, как отслеживать это?
У меня есть подозреваемый, но я пока не экспериментирую с ним. Мое приложение использует API OSMDroid для автономного сопоставления. Класс OverlayItem представляет маркеры/узлы на карте. У меня есть Служба, которая собирает данные через сеть, чтобы заполнить OverlayItem, которые затем отображаются на карте. Чтобы упростить мой дизайн, я расширил OverlayItem в свой собственный класс NodeOverlayItem, который включает некоторые дополнительные атрибуты, которые я использую в деятельности пользовательского интерфейса и в Сервисе. Это дало мне один пункт информации о деталях для пользовательского интерфейса и сервиса. Я использовал Intents для трансляции в Activity, чтобы обновить карту пользовательского интерфейса, когда что-то изменилось. Действие привязывается к Сервису, и есть метод службы, чтобы получить список NodeOverlayItem. Я думаю, что это может быть использование API OSMDroid OverlayItem и моей службы обновления node информации одновременно. (a concurrency)
Как я пишу это, я думаю, что действительно проблема. Головная боль не расщепляет node и OverlayItem из NodeOverlayItem, это значит, что для операции потребуется некоторые данные из Node, которые выполняется Сервисом. Плюс, когда создается действие (onResume и т.д.), Объекты OverlayItem необходимо будет восстановить из данных node, которые Служба поддерживала, пока активность не была удалена. например Вы запускаете приложение, Служба собирает данные, пользовательский интерфейс отображает его, вы переходите в "Домой", а затем обратно в приложение. Управлению необходимо будет вытащить и заново создать OverlayItem из последних данных службы node.
Я знаю, что это не большие или четкие вопросы. Это, как и все мои SO-вопросы, нишевые или неясные. Если у кого-то есть предложение о том, как интерпретировать эти ошибки SIGSEGV
, было бы очень полезно!
UPDATE
Здесь последний сбой, зафиксированный во время сеанса отладки. У меня есть 3 из этих устройств, которые используются для тестирования, и они не все работают с уверенностью, когда я разрабатываю и тестирую. Я включил немного больше, чтобы можно было отметить регистрацию GC. Вы можете видеть, что проблема, вероятно, не связана с исчерпанием памяти.
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 a re-broadcast from another node, or from myself. It 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 [email protected]+...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
Ответы
Ответ 1
OK! Мне очень жаль тех, кто действительно отправил комментарии и ответы, но я нашел проблему. Я не думаю, что это поможет многим другим, кто пытается отследить их личный SIGSEGV, но мой (и это было очень сложно) полностью связано с этим:
https://code.google.com/p/android/issues/detail?id=8709
libcrypto.so в моем режиме дампа. Я делаю хеш MD5 пакетных данных, пытаясь определить, видел ли я этот пакет, и пропустил его, если бы у меня было. Я подумал, что в какой-то момент это была уродливая проблема с потоками, связанная с отслеживанием этих хэшей, но оказалось, что это класс java.security.MessageDigest! Это не потокобезопасно!
Я поменял его с помощью UID, который я набивал в каждом пакете на основе UUID устройства и отметки времени. С тех пор проблем нет.
Я думаю, что урок, который я могу передать тем, которые были в моей ситуации, даже если вы - 100% -ное Java-приложение, обратите внимание на собственную библиотеку и символ, отмеченные в дампе сбоя для подсказок. Googling для SIGSEGV + имя lib.so будет намного дальше, чем бесполезный код = 1 и т.д. Затем подумайте о том, где ваше приложение Java может касаться собственного кода, даже если он ничего не делает. Я допустил ошибку, предположив, что это проблема с потоком Service + UI, где Canvas рисует что-то нулевое (наиболее распространенный случай, когда я Googled на SIGSEGV) и игнорировал возможность, что он мог быть полностью связан с кодом, который я написал, который был связанные с lib.so в дампе сбоя. Естественно, java.security будет использовать собственный компонент в libcrypto.so для скорости, поэтому, как только я узнал, я Googled для Android + SIGSEGV + libcrypto.so и нашел документированную проблему. Удачи!
Ответ 2
Во-первых, получите трассировку стека надгробий, он будет печататься каждый раз, когда ваше приложение выйдет из строя. Что-то вроде этого:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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
Затем используйте утилиту addr2line
(найдите ее в цепочке инструментов NDK), чтобы найти неисправную функцию. В этом примере вы
addr2line -e -f libc.so 0001173c
И вы увидите, где у вас проблема. Конечно, это не поможет вам, так как это в libc.
Итак, вы можете объединить утилиты arm-eabi-objdump
, чтобы найти конечную цель.
Поверьте, это непростая задача.
Просто для обновления. Я думаю, что довольно долго я делал сборку Android на основе дерева исходных текстов, и до сегодняшнего дня я сам тщательно читал документы NDK. С момента выпуска NDK-r6 он предоставил утилиту под названием ndk-stack
.
Ниже приведено содержимое официальных документов NDK с шаром NDK-r9.
Обзор:
ndk-stack
- простой инструмент, который позволяет фильтровать трассировки стека, как они появляются на выходе "adb logcat", и заменять любой адрес внутри общей библиотеки соответствующими значениями.
Вкратце, он переведет что-то вроде:
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):
В более читаемый вывод:
********** 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
Применение:
Для этого вам сначала понадобится каталог, содержащий символические версии разделяемых вами приложений. Если вы используете систему сборки NDK (т.е. ndk-build
), то они всегда находятся под $PROJECT_PATH/obj/local/, где для вашего устройства ABI (т.е. armeabi
) по умолчанию).
Вы можете передать текст logcat
либо как прямой ввод в программу, например:
adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi
Или вы можете использовать параметр -dump для указания logcat в качестве входного файла, например:
adb logcat > /tmp/foo.txt
$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt
ВАЖНО:
Инструмент ищет начальную строку, содержащую начало в выводе logcat
, то есть что-то похожее:
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
При копировании/вставке следов не забудьте эту строку из трасс, или ndk-stack
не будет работать правильно.
TODO:
Будущая версия ndk-stack
попытается запустить adb logcat
и автоматически выбрать путь к библиотеке. На данный момент вам нужно будет сделать эти шаги вручную.
На данный момент ndk-stack
не обрабатывает библиотеки, в которых нет отладочной информации. Может быть полезно попытаться обнаружить ближайшую точку входа функции на заданный адрес ПК (например, как в примере libc.so выше).
Ответ 3
Я получал эту ошибку, сохраняя объект в общих предпочтениях как преобразованная строка gson. Строка gson не была хорошей, поэтому извлечение и десериализация объекта на самом деле не работали правильно. Это означало, что любые последующие обращения к объекту привели к этой ошибке. Страшно:)
Ответ 4
Я также получил эту ошибку много раз, и я решил ее.
Эта ошибка будет рассмотрена в случае управления памятью на родной стороне.
Ваше приложение обращается к памяти за пределами своего адресного пространства. Скорее всего, это недопустимый доступ указателя. SIGSEGV = ошибка сегментации в собственном коде. Так как это не происходит в коде Java, вы не увидите трассировку стека с подробностями. Тем не менее, вы все равно можете увидеть информацию о трассировке стека в логарифме, если вы немного оглядитесь после сбоя процесса приложения. Он не укажет номер строки в файле, но расскажет вам, какие объектные файлы и адреса использовались в цепочке вызовов. Оттуда вы часто можете выяснить, какая область кода проблематична. Вы также можете настроить собственное подключение gdb к целевому процессу и уловить его в отладчике.
Ответ 5
Сегодня я столкнулся с Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161
выпуске Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161
и я пол дня Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161
решить эту проблему.
Я пробовал много вещей, очищающих кеш и удаляющих файл .gradle и все.
Наконец я disable Instant Run
и теперь я больше не получаю эту проблему. Теперь мое приложение работает после включения мгновенного запуска. Это может быть проблема мгновенного запуска, попробуйте отключить и включить мгновенный запуск
Из этого ответа:
Перейдите в Настройки или настройки Android Studio (для MAC) → Сборка, выполнение, развертывание → Мгновенный запуск.
Затем снимите флажок "Включить мгновенный запуск" в верхней части.
Ответ 6
Попробуйте отключить аппаратное ускорение Android в манифесте.
android:hardwareAccelerated="false"
Ответ 7
Я столкнулся с этой ошибкой, когда пытался получить доступ к "холсту" вне 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
Очень плохая практика:/
Ответ 8
Я получал эту ошибку при использовании растрового изображения следующим образом:
bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);
Для меня проблема заключалась в уменьшении размера растрового изображения ( > 1000px до 700px).
Ответ 9
Я столкнулся с SIGSEGV на Android 4.4.4 (Nexuses, Samsung)
И оказалось, что фатальная ошибка заключалась в анализе null
String
с использованием DecimalFormat
static DecimalFormat decimalFormat = new DecimalFormat("###,###.###");
void someMethod(String value) {
...
Number number = decimalFormat.parse(value);//value is null, SIGSEGV will happen`
...
}
В Android > 21 он был успешно обработан с помощью try/catch
Ответ 10
Если вы используете библиотеку vitamio и эта фатальная ошибка возникает.
Затем убедитесь, что в графе вашего проекта targetSdkVersion должно быть меньше 23.
Благодарю.
Ответ 11
Я столкнулся с этой проблемой несколько androidx
назад после миграции с android.support
на androidx
.
Проблема была renderscript
.
Решение: я удалил из своего build.gradle
эти две строки:
renderscriptTargetApi 21
renderscriptSupportModeEnabled true
после того, как проект не удался, из-за неразрешенных ссылок:
import androidx.renderscript.Allocation;
import androidx.renderscript.Element;
import androidx.renderscript.RenderScript;
import androidx.renderscript.ScriptIntrinsicBlur;
поэтому я изменил их на:
import android.renderscript.Allocation;
import android.renderscript.Element;
import android.renderscript.RenderScript;
import android.renderscript.ScriptIntrinsicBlur;
После этого все проблемы исчезли.
Ответ 12
В моем случае проблема вызвана Android Profiler. В Android Studio нажмите "Android Profiler" и "end session".
По иронии судьбы, это также вызывало экстремальные проблемы с производительностью в приложении.
Ответ 13
Я получил эту ошибку, когда я использовал ViewTreeObserver внутри функции 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
}
});
}
Ответ 14
Проверьте свой JNI/собственный код. Одна из моих ссылок была нулевой, но она была прерывистой, поэтому это было не очень очевидно.
Ответ 15
проверьте свои родные функции, независимо от того, возвращается ли он должным образом или нет. Если он не возвращается, добавьте операторы возврата.
Ответ 16
Для меня эта проблема возникла из-за плохого отношения между двумя видами деятельности. Недавно я переместил этот метод из Activity1 в другой 2. После этого рефакторинг оставил это явное приведение прежним. Так что вместо того, чтобы делать
((Activity1) mainActivity).hideDialog();
Я должен был сделать
((Activity2) mainActivity).hideDialog();
Примечание: но эта ошибка не произошла на Android 8.0 Я еще не уверен, почему.
*** Надеюсь, поможет.
Ответ 17
У меня была ошибка ошибки сегментации из-за проблем с памятью. Моя структура, имеющая много переменных и массивов, имела этот массив размером 1024.
Уменьшая размер до 512, ошибка исчезла.
PS: это обходной путь, а не решение. Необходимо найти размер структуры и динамическое распределение памяти - лучший вариант.
Ответ 18
В моем случае (я использую формы Xamarin) эта ошибка возникла из-за ошибки привязки - например:
<Label Grid.Column="4" Grid.Row="1" VerticalTextAlignment="Start" HorizontalTextAlignment="Center" VerticalOptions="Start" HorizontalOptions="Start" FontSize="10" TextColor="Pink" Text="{Binding }"></Label>
По сути, я удалил свойство view модели по ошибке. Для разработчиков Xamarin, если у вас есть та же проблема, проверьте свои привязки...
Ответ 19
У меня была эта проблема с пакетом, который был добавлен в мое приложение (FancyShowCaseView) и вызвал эту проблему на pre-lolipop. этот пакет был написан на kotlin, а мои основные коды написаны на java. так что теперь я проверяю версию в pre-lolipop и не позволяю ее классу быть выполненным. временно решил проблему.
проверьте это, если у вас есть подобные проблемы, как я
Ответ 20
Build fingerprint:
'motorola/harpia/harpia:6.0.1/MPIS24.241-2.50-16/16:user/release-keys'
Revision: 'p1b0' ABI: 'arm' pid: 18139, tid: 25935, name: GLThread
2137 >>> com.portable3d.okt.a3dmap1 <<< signal 11 (SIGSEGV), code 2
(SEGV_ACCERR), fault addr 0x7452f000
2 из 12 телефонов вернули ошибку, обнаружили, что проблема была в onDrawFrame(), некоторые объекты были нулевыми, я не знаю почему, я просто установил
if(gears==null) return;
.