Sinal fatal Android 11 (SIGSEGV) em 0x636f7d89 (código = 1). Como pode ser rastreado?

Estive lendo as outras postagens sobre como rastrear os motivos para obter um SIGSEGVem um aplicativo Android. Pretendo vasculhar meu aplicativo em busca de possíveis NullPointers relacionados ao uso do Canvas, mas meu SIGSEGVendereço de memória é diferente a cada vez. Além disso, eu já vi code=1e code=2. Se o endereço da memória fosse 0x00000000, eu teria uma pista de que é um NullPointer.

O último que recebi foi code=2:

A/libc(4969): Fatal signal 11 (SIGSEGV) at 0x42a637d9 (code=2)

Alguma sugestão sobre como rastrear isso?

Eu tenho um suspeito, mas ainda não estou interessado em experimentar. Meu aplicativo usa a API OSMDroid para mapeamento offline. A classe OverlayItem representa marcadores / nós no mapa. Eu tenho um serviço que coleta dados através da rede para preencher o OverlayItem, que são exibidos no mapa. Em um esforço para simplificar meu design, estendi OverlayItem para minha própria classe NodeOverlayItem, que inclui alguns atributos adicionais que eu uso na Atividade da UI e no Serviço. Isso me deu um único ponto de informações do item para a interface do usuário e o serviço. Usei o Intents para transmitir para a Activity para atualizar o mapa da interface do usuário quando algo mudou. A Atividade se liga ao Serviço e existe um método de Serviço para obter a lista dos NodeOverlayItem. Eu acho que pode ser o uso de OverlayItem da API OSMDroid, e meu Serviço atualizando as informações do nó ao mesmo tempo. (um problema de simultaneidade)

Enquanto escrevo isso, acho que esse é realmente o problema. A dor de cabeça não está dividindo o Nó e o OverlayItem de NodeOverlayItem, é que a Atividade precisará de alguns dados do Nó, que o Serviço mantém. Além disso, quando a Atividade é criada (onResume, etc ...), os objetos OverlayItem precisarão ser recriados a partir dos dados do Nó que o Serviço mantém enquanto a Atividade estava ausente. Por exemplo, você inicia o aplicativo, o Serviço coleta dados, a interface do usuário os exibe, você acessa a Página inicial e, em seguida, volta para o aplicativo. A Atividade precisará puxar e recriar o OverlayItem a partir dos dados mais recentes do nó Serviço.

Eu sei que essa não é uma pergunta ótima ou clara. É como se todas as minhas perguntas de SO fossem nicho ou obscuras. Se alguém tiver uma sugestão sobre como interpretar esses SIGSEGVerros, seria muito apreciada!

ATUALIZAÇÃO Aqui está a última falha capturada durante uma sessão de depuração. Eu tenho três desses dispositivos sendo usados ​​para teste e nem todos travam de maneira confiável quando estou desenvolvendo e testando. Incluí um pouco mais só para que o registro do GC possa ser observado. Você pode ver que o problema provavelmente não está relacionado ao esgotamento da memória.

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

Primeiro, obtenha seu rastreamento de pilha de marca para exclusão, que será impresso toda vez que seu aplicativo falhar. Algo assim:

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
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

Em seguida, use o addr2lineutilitário (encontre-o na sua cadeia de ferramentas NDK) para encontrar a função que trava. Nesta amostra, você faz

addr2line -e -f libc.so 0001173c

E você verá onde conseguiu o problema. Claro que isso não irá ajudá-lo, pois está na libc.

Então você pode combinar os utilitários de arm-eabi-objdumppara encontrar o destino final.

Acredite, é uma tarefa difícil.

Apenas para uma atualização. Eu acho que estava fazendo a compilação nativa do Android a partir da árvore de origem inteira por um bom tempo, até hoje eu mesmo li cuidadosamente os documentos NDK. Desde o lançamento NDK-R6, tem fornecido um utilitário chamado ndk-stack.

A seguir, o conteúdo dos documentos oficiais da NDK com a bola de alcatrão NDK-r9.

Visão geral:

ndk-stack é uma ferramenta simples que permite filtrar os rastreamentos de pilha conforme eles aparecem na saída de 'adb logcat' e substituir qualquer endereço dentro de uma biblioteca compartilhada pelos valores correspondentes:

Em poucas palavras, ele traduzirá algo como:

  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):

Na saída mais legível:

  ********** 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

Uso:

Para fazer isso, primeiro você precisará de um diretório contendo versões simbólicas das bibliotecas compartilhadas do seu aplicativo. Se você usar o sistema de construção NDK (ou seja ndk-build), eles sempre estarão localizados em $ PROJECT_PATH / obj / local /, onde significa a ABI do seu dispositivo (ou seja, armeabipor padrão).

Você pode alimentar o logcattexto como entrada direta para o programa, por exemplo:

adb logcat | $NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

Ou você pode usar a opção -dump para especificar o logcat como um arquivo de entrada, por exemplo:

adb logcat > /tmp/foo.txt
$NDK/ndk-stack -sym $PROJECT_PATH/obj/local/armeabi -dump foo.txt

IMPORTANTE:

A ferramenta procura a linha inicial que contém as partidas na logcatsaída, ou seja, algo parecido com:

 *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

Ao copiar / colar traços, não esqueça essa linha dos traços ou ndk-stacknão funcionará corretamente.

FAÇAM:

Uma versão futura do ndk-stacktentará iniciar adb logcate selecionar o caminho da biblioteca automaticamente. Por enquanto, você precisará executar essas etapas manualmente.

No momento, ndk-stacknão lida com bibliotecas que não contêm informações de depuração. Pode ser útil tentar detectar o ponto de entrada da função mais próximo de um determinado endereço de PC (por exemplo, como no exemplo libc.so acima).

ESTÁ BEM! Lamento muito aqueles que realmente enviaram comentários e respostas, mas encontrei o problema. Eu não acho que isso ajude muitos outros a tentar localizar seu SIGSEGV pessoal, mas o meu (e foi muito difícil) estava inteiramente relacionado a isso:

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

O libcrypto.so no meu dump meio que me deu uma pista. Eu faço um hash MD5 de dados de pacote ao tentar determinar se eu já vi o pacote e ignorá-lo, se tiver. Eu pensei que em um ponto isso era um problema de encadeamento feio relacionado ao rastreamento desses hashes, mas acabou que era a classe java.security.MessageDigest! Não é thread thread safe!

Troquei-o com um UID que eu estava preenchendo em todos os pacotes com base no UUID do dispositivo e em um carimbo de data / hora. Sem problemas desde então.

Acho que a lição que posso transmitir àqueles que estavam na minha situação é que, mesmo se você for um aplicativo Java 100%, preste atenção na biblioteca nativa e no símbolo anotado no despejo de memória para obter dicas. Pesquisando no SIGSEGV +, o nome lib .so vai muito além do código inútil = 1, etc ... Em seguida, pense em onde seu aplicativo Java poderia tocar no código nativo, mesmo que não esteja fazendo nada. Cometi o erro de supor que era um problema de encadeamento do Service + UI em que o Canvas estava desenhando algo que era nulo (o caso mais comum que pesquisei no SIGSEGV) e ignorei a possibilidade de que pudesse estar completamente relacionado ao código que escrevi. relacionado à lib .so no despejo de memória. Naturalmente, o java.security usaria um componente nativo no libcrypto.so para obter velocidade, então, depois que eu entrei no Google, pesquisei no Android + SIGSEGV + libcrypto. e encontrou o problema documentado. Boa sorte!

Eu estava recebendo esse erro salvando um objeto nas preferências compartilhadas como uma string convertida gson. Como o gson String não era bom, a recuperação e desserialização do objeto não estavam funcionando corretamente. Isso significava que quaisquer acessos subseqüentes ao objeto resultariam nesse erro. Assustador :)

Eu também recebi esse erro muitas vezes e o resolvi. Este erro será enfrentado no caso de gerenciamento de memória no lado nativo.

Seu aplicativo está acessando a memória fora do espaço de endereço. Provavelmente, é um acesso inválido ao ponteiro. SIGSEGV = falha de segmentação no código nativo. Como não está ocorrendo no código Java, você não verá um rastreamento de pilha com detalhes. No entanto, você ainda poderá ver algumas informações de rastreamento de pilha no logcat se olhar um pouco depois que o processo do aplicativo falha. Ele não informa o número da linha no arquivo, mas informa quais arquivos e endereços de objetos estavam em uso na cadeia de chamadas. A partir daí, muitas vezes você pode descobrir qual área do código é problemática. Você também pode configurar uma conexão nativa gdb com o processo de destino e capturá-la no depurador.

Hoje eu enfrentei um Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161problema e luto meio dia para resolver isso.

Eu tentei muitas coisas limpando o cache e excluindo o arquivo .gradle e tudo.

Finalmente, eu disable Instant Rune agora não estou recebendo esse problema novamente. Agora, meu aplicativo está funcionando depois de ativar a execução instantânea também. Pode ser o problema da execução instantânea. Tente desativar e ativar a execução instantânea.

A partir desta resposta:

Vá para Configurações ou Preferências do Android Studio (para MAC) -> Compilação, Execução, Implantação -> Execução instantânea.

Em seguida, desmarque a caixa de seleção "Ativar execução instantânea" na parte superior.

Tente desativar a aceleração de hardware Android no seu manifesto.

android:hardwareAccelerated="false"

Encontrei este erro quando tentei acessar a 'tela' fora 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

Uma prática muito ruim: /

Eu estava recebendo esse erro ao usar um bitmap como este:

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

O que corrigiu o problema para mim foi reduzir o tamanho do bitmap (> 1000px alto para 700px).

Eu enfrentei o SIGSEGV no Android 4.4.4 (Nexuses, Samsungs). E ocorreu que um erro fatal estava na análise null StringusandoDecimalFormat

 static DecimalFormat decimalFormat = new DecimalFormat("###,###.###");
 void someMethod(String value) {
...
    Number number = decimalFormat.parse(value);//value is null, SIGSEGV will happen`
...
}

No Android> 21, foi tratado com êxito com try / catch

Eu enfrentei esse problema momento atrás, depois de migrar de android.supportpara androidx.

O problema era renderscript.

Solução: removi minhas build.gradleduas linhas:

renderscriptTargetApi 21
renderscriptSupportModeEnabled true

depois que a construção do projeto falhou, devido a referências não resolvidas:

import androidx.renderscript.Allocation;
import androidx.renderscript.Element;
import androidx.renderscript.RenderScript;
import androidx.renderscript.ScriptIntrinsicBlur;

então eu mudei para:

import android.renderscript.Allocation;
import android.renderscript.Element;
import android.renderscript.RenderScript;
import android.renderscript.ScriptIntrinsicBlur;

Depois disso, todos os problemas se foram.

Se você estiver usando a biblioteca vitamio e esse erro fatal ocorrer.

Em seguida, verifique se o gradle targetSdkVersion do seu projeto deve ser menor que 23.

obrigado.

No meu caso (estou usando o Xamarin Forms), esse erro foi gerado devido a um erro de ligação - por exemplo:

<Label Grid.Column="4" Grid.Row="1" VerticalTextAlignment="Start" HorizontalTextAlignment="Center"  VerticalOptions="Start" HorizontalOptions="Start" FontSize="10" TextColor="Pink" Text="{Binding }"></Label>

Basicamente, excluí a propriedade do modelo de exibição por engano. Para desenvolvedores do Xamarin, se você tiver o mesmo problema, verifique suas ligações ...

Se você adicionou algum código C nativo ao seu projeto, esta resposta pode ser útil.

Eu adicionei algum código C nativo no projeto android.

Agora eu estava tentando acessar o código que estava retornando a string nativa para mim, antes de processar a string, eu havia definido seu valor padrão como nullptr. Agora, ao recuperar seu valor no código java, ocorreu esse problema.

Como nosso código C nativo está fora do diretório java, não temos idéia da linha exata de código que está criando o problema. Então, eu sugiro que você verifique o seu arquivo .cpp e tente encontrar alguma pista lá.

Espero que você se livre do problema em breve. :)

No meu caso, o problema estava sendo causado pelo Android Profiler. No Android Studio, clique em "Android Profiler" e "finalizar sessão".

Ironicamente, também estava causando problemas extremos de desempenho no aplicativo.

Adicione essas duas linhas ao seu build.gradle na seção android:

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}

Verifique seu código JNI / nativo. Uma das minhas referências era nula, mas era intermitente, portanto não era muito óbvia.

verifique suas funções nativas, se está retornando corretamente ou não. Se não for retornado, adicione instruções de retorno.

Para mim, esse problema ocorreu devido a um elenco ruim entre duas atividades. Recentemente, mudei esse método da Activity1 para outra 2. Ao fazer isso, o refator deixou esse elenco explícito como antes. Então, ao invés de fazer

((Activity1) mainActivity).hideDialog();

Eu deveria fazer

((Activity2) mainActivity).hideDialog();

Nota: Mas esse erro não ocorreu no Android 8.0. Ainda não sei por que.

*** Espero que ajude.

Eu tive esse erro de falha de segmentação devido a problemas de memória . Meu struct tendo muitas variáveis ​​e matrizes, tinha essa matriz de tamanho 1024.

Reduzindo o tamanho para 512, o erro desapareceu.

PS: Esta é uma solução alternativa e não uma solução. É necessário encontrar o tamanho da estrutura e a alocação dinâmica de memória é uma opção melhor.

Eu recebi esse erro quando usei a onDraw()função interna ViewTreeObserver .

@Override
protected void onDraw(Canvas canvas) {
    // super.onDraw(canvas);
    ViewTreeObserver vto = mTextView.getViewTreeObserver();
    vto.addOnGlobalLayoutListener(new ViewTreeObserver.OnGlobalLayoutListener() {
        @Override
        public void onGlobalLayout() {
            // some animation        
        }
    });
 }

Eu tive esse problema com um pacote que foi adicionado ao meu aplicativo (FancyShowCaseView) e causou esse problema no pré-lolipop. esse pacote foi escrito em kotlin e meus códigos principais foram escritos em java. então agora estou verificando a versão no pré-lolipop e não deixo sua classe ser executada. temporário resolveu o problema. verifique isso se você tiver um problema semelhante como eu

Criar impressão digital: 'motorola / harpia / harpia: 6.0.1 / MPIS24.241-2.50-16 / 16: user / release-keys' Revisão: 'p1b0' ABI: 'arm' pid: 18139, tid: 25935, name: GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<< sinal 11 (SIGSEGV), código 2 (SEGV_ACCERR), erro 0x7452f000

2 de 12 telefones retornaram um erro, descobriram que o problema estava no onDrawFrame (), alguns objetos eram nulos, não sei por que, apenas configurei

if(gears==null) return;.

Eu tive o problema ao criar um PDF usando as APIs de PDF do Android e acidentalmente usei o canvas.save () e canvas.restore () depois de fechar uma página em pdf.