Фатальный сигнал Android 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)

Любые предложения о том, как отследить это?

У меня есть подозреваемый, но я пока не заинтересован в экспериментах с ним. Мое приложение использует OSMDroid API для отображения в автономном режиме. Класс OverlayItem представляет маркеры / узлы на карте. У меня есть служба, которая собирает данные через сеть для заполнения OverlayItem, которые затем отображаются на карте. Чтобы упростить мой дизайн, я расширил OverlayItem в свой собственный класс NodeOverlayItem, который включает некоторые дополнительные атрибуты, которые я использую в UI Activity и в Service. Это дало мне один пункт информации об элементе для пользовательского интерфейса и службы. Я использовал Intents для трансляции в Activity, чтобы обновить карту пользовательского интерфейса, когда что-то изменилось. Activity связывается со службой, и есть метод Service, чтобы получить список объектов NodeOverlayItem. Я думаю, что это может быть использование API-интерфейса OSMDroid OverlayItem, и мой Сервис обновляет информацию об узле одновременно. (проблема параллелизма)

Когда я пишу это, я думаю, что это действительно проблема. Головная боль не отделяет Node и OverlayItem от NodeOverlayItem, это то, что Activity потребуются некоторые данные из Node, которые содержит Сервис. Кроме того, при создании действия (onResume и т. Д.) Необходимо будет заново создать объекты OverlayItem из данных узла, которые служба поддерживала, пока действие отсутствовало. Например, вы запускаете приложение, Служба собирает данные, пользовательский интерфейс отображает их, вы переходите в «Домой», а затем обратно в приложение, «Деятельности» нужно будет извлечь и заново создать OverlayItem из последних данных узла Службы.

Я знаю, что это не великие или ясные вопросы. Как будто все мои ТАК вопросы нишевые или неясные. Если у кого-то есть предложение о том, как интерпретировать эти SIGSEGVошибки, это будет с благодарностью!

ОБНОВЛЕНИЕ Вот последний сбой, зафиксированный во время сеанса отладки. У меня есть 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'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

Во-первых, найдите трассировку стека захоронений, она будет распечатываться каждый раз при сбое приложения. Что-то вроде этого:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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она не будет работать правильно.

ДЕЛАТЬ:

Будущую версию ndk-stackпостараюсь запуститьadb logcat и выбрать путь к библиотеке автоматически. На данный момент вам придется делать эти шаги вручную.

На данный ndk-stackмомент не обрабатывает библиотеки, в которых нет отладочной информации. Может быть полезно попытаться определить ближайшую точку входа функции по заданному адресу ПК (например, как в примере libc.so выше).

ХОРОШО! Мне очень жаль тех, кто на самом деле представил комментарии и ответы, но я нашел проблему. Я не думаю, что это поможет многим другим, пытающимся отследить их личный SIGSEGV, но мой (и это было очень трудно) было полностью связано с этим:

https://code.google.com/p/android/issues/detail?id=8709

Libcrypto.so в моем дампе как бы подсказал мне. Я делаю MD5-хэш пакетных данных, пытаясь определить, видел ли я уже пакет, и пропускаю его, если у меня был. В какой-то момент я подумал, что это ужасная проблема с потоками, связанная с отслеживанием этих хешей, но оказалось, что это класс java.security.MessageDigest! Это не потокобезопасно!

Я поменял его с UID, который я вставлял в каждый пакет, основываясь на UUID устройства и отметке времени. С тех пор проблем нет.

Я думаю, что урок, который я могу преподнести тем, кто был в моей ситуации, - даже если вы на 100% Java-приложение, обратите внимание на собственную библиотеку и символ, отмеченные в аварийном дампе для подсказок. Поиск в Google для SIGSEGV + имя lib .so пойдет намного дальше, чем бесполезный код = 1 и т. Д. Затем подумайте, где ваше Java-приложение может касаться нативного кода, даже если вы ничего не делаете. Я допустил ошибку, предположив, что это была проблема с потоками Service + UI, когда Canvas рисовал что-то, что было нулевым (самый распространенный случай, когда я гуглил на SIGSEGV), и проигнорировал возможность, что это могло быть полностью связано с написанным мною кодом, который был связанные с lib .so в аварийном дампе. Естественно, java.security будет использовать нативный компонент в libcrypto.so для скорости, поэтому, как только я уясню, я погуглил для Android + SIGSEGV + libcrypto. так и нашел задокументированный вопрос. Удачи!

Я получал эту ошибку, сохраняя объект в общих настройках в виде строки, преобразованной в gson. Строка gson оказалась бесполезной, поэтому поиск и десериализация объекта на самом деле работали некорректно. Это означало, что любой последующий доступ к объекту приводил к этой ошибке. Страшно :)

Я также получил эту ошибку много раз, и я решил ее. Эта ошибка возникнет в случае управления памятью на нативной стороне.

Ваше приложение обращается к памяти за пределами своего адресного пространства. Скорее всего, это неверный указатель доступа. SIGSEGV = ошибка сегментации в собственном коде. Так как это не происходит в коде Java, вы не увидите трассировку стека с подробностями. Тем не менее, вы все равно можете увидеть некоторую информацию о трассировке стека в logcat, если немного осмотритесь после сбоя процесса приложения. Он не сообщит вам номер строки в файле, но сообщит, какие объектные файлы и адреса использовались в цепочке вызовов. Оттуда вы часто можете выяснить, какая часть кода является проблематичной. Вы также можете установить собственное соединение GDB с целевым процессом и перехватить его в отладчике.

Сегодня я столкнулся с Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161проблемой, и мне трудно полдня, чтобы решить эту проблему.

Я пробовал много вещей, очищающих кеш и удаляющих файл .gradle и все.

Наконец-то у меня disable Instant Runи сейчас у меня больше нет этой проблемы. Теперь мое приложение работает после включения мгновенного запуска. Это может быть проблема мгновенного запуска, попробуйте отключить и включить мгновенный запуск

Из этого ответа:

Перейдите в Настройки или Настройки Android Studio (для MAC) -> Построение, Выполнение, Развертывание -> Мгновенный запуск.

Затем снимите флажок «Включить мгновенный запуск» в верхней части.

Попробуйте отключить аппаратное ускорение Android в своем манифесте.

android:hardwareAccelerated="false"

Я столкнулся с этой ошибкой, когда пытался получить доступ к «холсту» вне 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

Очень плохая практика: /

Я получаю эту ошибку при использовании растрового изображения, как это:

bmp = BitmapFactory.decodeResource(this.getResources(), R.drawable.myBitMap);

Для меня исправлена ​​проблема с уменьшением размера растрового изображения (от 1000 пикселей до 700 пикселей).

Я сталкивался с SIGSEGV на Android 4.4.4 (Nexuses, Samsungs) И оказалось, что фатальная ошибка была в разборе 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

Я столкнулся с этим вопросом минуту назад, после перехода от 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;

После этого все проблемы исчезли.

Если вы используете библиотеку vitamio и эта фатальная ошибка произойдет.

Затем убедитесь, что в вашем проекте gradle targetSdkVersion должно быть меньше 23.

Спасибо.

В моем случае (я использую формы 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, если у вас возникла та же проблема, проверьте свои привязки ...

Если вы добавили некоторый нативный код C в свой проект, этот ответ может быть полезным.

Я добавил немного родного кода на C в проекте Android.

Теперь я пытался получить доступ к тому коду, который возвращал мне нативную строку, перед обработкой строки я установил ее значение по умолчанию как nullptr. Теперь при получении его значения в Java-коде столкнулся с этой проблемой.

Так как наш родной C-код отсутствует в каталоге java, мы не можем понять, какая именно строка кода создает проблему. Поэтому я бы посоветовал вам проверить ваш файл .cpp и попытаться найти какую-либо подсказку там.

Надеюсь, что вы скоро избавитесь от проблемы. :)

В моем случае проблема была вызвана Android Profiler. В Android Studio нажмите «Android Profiler» и «завершить сеанс».

По иронии судьбы, это также вызывало серьезные проблемы с производительностью в приложении.

Добавьте эти две строки в ваш build.gradle в разделе Android:

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}

Проверьте свой JNI / собственный код. Одна из моих ссылок была нулевой, но она была прерывистой, так что это было не очень очевидно.

проверьте ваши собственные функции, правильно ли он возвращается или нет. Если он не возвращается, добавьте оператор возврата.

Для меня эта проблема была из-за плохого отношения между двумя действиями. Недавно я переместил этот метод из Activity1 в другой 2. После этого рефакторинг оставил это явное приведение, как это было раньше. Так что вместо того, чтобы делать

((Activity1) mainActivity).hideDialog();

Я должен был сделать

((Activity2) mainActivity).hideDialog();

Примечание: но эта ошибка не произошла на Android 8.0 Я еще не уверен, почему.

*** Надеюсь, поможет.

У меня была ошибка ошибки сегментации из-за проблем с памятью . Моя структура, имеющая много переменных и массивов, имела этот массив размером 1024.

При уменьшении размера до 512 ошибка исчезла.

PS: это обходной путь, а не решение. Необходимо найти размер структуры и динамическое распределение памяти - лучший вариант.

Я получил эту ошибку, когда я использовал 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        
        }
    });
 }

У меня была эта проблема с пакетом, который был добавлен в мое приложение (FancyShowCaseView) и вызвал эту проблему на pre-lolipop. этот пакет был написан на kotlin, а мои основные коды написаны на java. так что теперь я проверяю версию в pre-lolipop и не позволяю ее классу быть выполненным. временно решил проблему. проверьте это, если у вас есть подобные проблемы, как я

Отпечаток пальца: 'моторола / гарпия / гарпия: 6.0.1 / MPIS24.241-2.50-16 / 16: ключи пользователя / релиза' Редакция: 'p1b0' ABI: 'рука' pid: 18139, тид: 25935, имя: GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<< сигнал 11 (SIGSEGV), код 2 (SEGV_ACCERR), адрес ошибки 0x7452f000

2 из 12 телефонов вернули ошибку, обнаружили, что проблема была в onDrawFrame (), некоторые объекты были нулевыми, я не знаю почему, я просто установил

if(gears==null) return;,

У меня возникла проблема, когда я создавал PDF-файл с использованием API-интерфейсов PDF для Android, и случайно закрыл страницы PDF-файла canvas.save () и canvas.restore ().