Señal fatal de Android 11 (SIGSEGV) en 0x636f7d89 (código = 1). ¿Cómo puede ser rastreado?

He estado leyendo las otras publicaciones sobre cómo rastrear las razones para obtener una SIGSEGVaplicación de Android. Tengo la intención de buscar en mi aplicación los posibles NullPointers relacionados con el uso de Canvas, pero SIGSEGVcada vez que busco una dirección de memoria diferente. Además he visto code=1y code=2. Si la dirección de memoria fuera 0x00000000, tendría una pista de que es un puntero nulo.

El último que obtuve fue un code=2:

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

¿Alguna sugerencia sobre cómo rastrear esto?

Tengo un sospechoso, pero todavía no estoy interesado en experimentar con él. Mi aplicación usa la API OSMDroid para el mapeo fuera de línea. La clase OverlayItem representa marcadores / nodos en el mapa. Tengo un Servicio que recopila datos a través de la red para completar el OverlayItem que luego se muestran en el mapa. En un esfuerzo por simplificar mi diseño, extendí OverlayItem a mi propia clase NodeOverlayItem, que incluye algunos atributos adicionales que uso en la Actividad de la IU y en el Servicio. Esto me dio un solo punto de información del artículo para la interfaz de usuario y el servicio. Utilicé Intentos para transmitir a la Actividad para actualizar el mapa de la interfaz de usuario cuando algo cambió. La Actividad se une al Servicio y hay un método de Servicio para obtener la lista de NodeOverlayItem's. Creo que podría ser el uso de OverlayItem por la API OSMDroid, y mi Servicio actualizando la información del nodo al mismo tiempo. (un problema de concurrencia)

Mientras escribo esto, creo que ese es realmente el problema. El dolor de cabeza no es dividir Node y OverlayItem de NodeOverlayItem, es que la Actividad necesitará algunos datos del Nodo, que el Servicio mantiene. Además, cuando se crea la Actividad (en Currículum, etc.), los objetos OverlayItem deberán volver a crearse a partir de los datos de Nodo que el Servicio ha estado manteniendo mientras la Actividad estaba fuera. p. ej., inicia la aplicación, el Servicio recopila datos, la IU la muestra, va a Inicio, luego vuelve a la aplicación, la Actividad deberá extraer y volver a crear los OverlayItem a partir de los últimos datos del nodo del Servicio.

Sé que esta no es una gran o clara pregunta. Es como si todas mis preguntas SO fueran de nicho u oscuras. Si alguien tiene una sugerencia sobre cómo interpretar esos SIGSEGVerrores, ¡sería muy apreciado!

ACTUALIZACIÓN Aquí está el último bloqueo capturado durante una sesión de depuración. Tengo 3 de estos dispositivos en uso para pruebas y no todos se bloquean de manera confiable cuando estoy desarrollando y probando. Incluí un poco más solo para que se notara el registro de GC. Puede ver que el problema probablemente no esté relacionado con el agotamiento de la memoria.

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

Primero, obtenga el seguimiento de su pila de lápidas, se imprimirá cada vez que su aplicación se bloquee. Algo como esto:

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

Luego, use la addr2lineutilidad (encuéntrela en su cadena de herramientas NDK) para encontrar la función que falla. En esta muestra, haces

addr2line -e -f libc.so 0001173c

Y verás de dónde sacaste el problema. Por supuesto, esto no te ayudará, ya que está en libc.

Por lo tanto, puede combinar las utilidades de arm-eabi-objdumppara encontrar el objetivo final.

Créeme, es una tarea difícil.

Solo para una actualización. Creo que estuve haciendo una compilación nativa de Android desde todo el árbol de fuentes durante bastante tiempo, hasta hoy he leído cuidadosamente los documentos NDK. Desde el lanzamiento de NDK-r6, ha proporcionado una utilidad llamada ndk-stack.

El siguiente es el contenido de los documentos oficiales de NDK con la bola de alquitrán NDK-r9.

Visión general:

ndk-stack es una herramienta simple que le permite filtrar los rastros de la pila tal como aparecen en la salida de 'adb logcat' y reemplazar cualquier dirección dentro de una biblioteca compartida con los valores correspondientes.

En pocas palabras, traducirá 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):

En la salida más legible:

  ********** 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 hacer esto, primero necesitará un directorio que contenga versiones simbólicas de las bibliotecas compartidas de su aplicación. Si utiliza el sistema de compilación NDK (es decir ndk-build), estos siempre se ubican en $ PROJECT_PATH / obj / local /, donde representa la ABI de su dispositivo (es decir, armeabipor defecto).

Puede alimentar el logcattexto como entrada directa al programa, por ejemplo:

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

O puede usar la opción -dump para especificar el logcat como un archivo de entrada, por ejemplo:

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

IMPORTANTE

La herramienta busca la línea inicial que contiene los inicios en la logcatsalida, es decir, algo que se parece a:

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

Cuando copie / pegue trazas, no olvide esta línea de las trazas, o ndk-stackno funcionará correctamente.

QUE HACER:

Una versión futura de ndk-stackintentará iniciar adb logcaty seleccionar la ruta de la biblioteca automáticamente. Por ahora, tendrás que hacer estos pasos manualmente.

A partir de ahora, ndk-stackno maneja bibliotecas que no tengan información de depuración. Puede ser útil intentar detectar el punto de entrada de la función más cercana a una dirección de PC determinada (por ejemplo, como en el ejemplo libc.so anterior).

¡OKAY! Realmente lo siento por aquellos que realmente han enviado comentarios y respuestas, pero encontré el problema. No creo que esto ayude a muchos otros que intentan rastrear su SIGSEGV personal, pero el mío (y fue muy difícil) estaba completamente relacionado con esto:

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

El libcrypto.so en mi volcado me dio una idea. Hago un hash MD5 de datos de paquetes cuando intento determinar si ya he visto el paquete, y omitirlo si lo hice. En un momento pensé que este era un problema de subproceso feo relacionado con el seguimiento de esos hashes, ¡pero resultó que era la clase java.security.MessageDigest! ¡No es seguro para hilos!

Lo cambié con un UID que estaba rellenando en cada paquete basado en el UUID del dispositivo y una marca de tiempo. No hay problemas desde entonces.

Supongo que la lección que puedo impartir a los que estaban en mi situación es que, incluso si es una aplicación 100% Java, preste atención a la biblioteca nativa y al símbolo anotados en el volcado de bloqueo para obtener pistas. Buscar en Google SIGSEGV + the lib .so name irá mucho más lejos que el código inútil = 1, etc ... Luego piense en dónde su aplicación Java podría tocar el código nativo, incluso si no está haciendo nada. Cometí el error de suponer que se trataba de un problema de subprocesos de Service + UI en el que Canvas dibujaba algo que era nulo (el caso más común que busqué en Google en SIGSEGV) e ignoré la posibilidad de que pudiera haber estado completamente relacionado con el código que escribí que era relacionado con la lib .so en el volcado de memoria. Naturalmente, java.security usaría un componente nativo en libcrypto.so para la velocidad, así que una vez que me di cuenta, busqué en Google para Android + SIGSEGV + libcrypto. así y encontré el problema documentado. ¡Buena suerte!

Estaba recibiendo este error al guardar un objeto en las preferencias compartidas como una cadena convertida de gson. La cadena gson no era buena, por lo que recuperar y deserializar el objeto no funcionaba correctamente. Esto significaba que cualquier acceso posterior al objeto resultó en este error. De miedo :)

También recibí este error muchas veces y lo resolví. Este error se enfrentará en caso de administración de memoria en el lado nativo.

Su aplicación está accediendo a la memoria fuera de su espacio de direcciones. Probablemente sea un acceso de puntero no válido. SIGSEGV = falla de segmentación en código nativo. Como no está ocurriendo en el código Java, no verá un seguimiento de la pila con detalles. Sin embargo, aún puede ver información de seguimiento de la pila en el logcat si observa un poco después de que el proceso de la aplicación se bloquee. No le dirá el número de línea dentro del archivo, pero le dirá qué archivos de objetos y direcciones estaban en uso en la cadena de llamadas. A partir de ahí, a menudo puede averiguar qué área del código es problemática. También puede configurar una conexión nativa de gdb para el proceso de destino y capturarla en el depurador.

Hoy me enfrenté a un Fatal signal 11 (SIGSEGV), code 1, fault addr 0x8 in tid 18161problema y lucho medio día para resolver esto.

Intenté muchas cosas borrando el caché y eliminando el archivo .gradle y todo.

Finalmente, disable Instant Runy ahora no vuelvo a tener este problema. Ahora mi aplicación funciona después de habilitar la ejecución instantánea también. Puede ser el problema de la ejecución instantánea, intente deshabilitar y habilitar la ejecución instantánea

De esta respuesta:

Vaya a Configuración o Preferencias de Android Studio (para MAC) -> Compilación, Ejecución, Implementación -> Ejecución instantánea.

Luego, desmarca la casilla de verificación "Habilitar ejecución instantánea" en la parte superior.

Intente deshabilitar la aceleración de hardware de Android en su manifiesto.

android:hardwareAccelerated="false"

Encontré este error cuando intenté acceder al 'lienzo' fuera 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

Una muy mala práctica: /

Recibía este error cuando usaba un mapa de bits como este:

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

Lo que solucionó el problema para mí fue reducir el tamaño del mapa de bits (> 1000 px de alto a 700 px).

Me enfrenté a SIGSEGV en Android 4.4.4 (Nexuses, Samsung) y resultó que hubo un error fatal al analizar null StringusandoDecimalFormat

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

En Android> 21 se manejó con éxito con try / catch

Enfrenté este problema hace un momento, después de migrar de android.supporta androidx.

El problema era renderscript.

Solución: eliminé de mis build.gradledos líneas:

renderscriptTargetApi 21
renderscriptSupportModeEnabled true

después de que fallara la construcción de ese proyecto, debido a referencias no resueltas:

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

así que los he cambiado a:

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

Después de eso, todos los problemas se fueron.

Si está utilizando la biblioteca vitamio y se produce este error fatal.

Luego, asegúrese de que en su proyecto gradle targetSdkVersion debe ser inferior a 23.

Gracias.

En mi caso (estoy usando Xamarin Forms), este error se produjo debido a un error vinculante, por ejemplo:

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

Básicamente eliminé la propiedad del modelo de vista por error. Para los desarrolladores de Xamarin, si tiene el mismo problema, verifique sus enlaces ...

Si hubiera agregado algún código C nativo en su proyecto, esta respuesta podría ser útil.

Había agregado un código C nativo en el proyecto de Android.

Ahora estaba tratando de acceder a ese código que me devolvía la cadena nativa, antes de procesar la cadena que había establecido su valor predeterminado como nullptr. Ahora, al recuperar su valor en código java, se encontró con este problema.

Como nuestro código C nativo está fuera del directorio de Java, no tenemos ni idea de la línea exacta de código que está creando el problema. Así que le sugiero que verifique su archivo .cpp e intente encontrar alguna pista allí.

Espero que pronto te deshagas del problema. :)

En mi caso, el problema fue causado por el Android Profiler. En Android Studio, haga clic en "Android Profiler" y "finalizar sesión".

Irónicamente, también estaba causando problemas extremos de rendimiento en la aplicación.

Agregue estas dos líneas a su build.gradle en la sección de Android:

android{
    compileOptions {
            sourceCompatibility 1.8
            targetCompatibility 1.8
        }
}

Verifique su código JNI / nativo. Una de mis referencias era nula, pero era intermitente, por lo que no era muy obvio.

verifique sus funciones nativas, si está regresando correctamente o no. Si no se devuelve, agregue declaraciones de devolución.

Para mí, ese problema se debió a un mal reparto entre dos actividades. Recientemente moví este método de Activity1 a otro 2. Al hacerlo, el refactor dejó este elenco explícito como estaba antes. Entonces, en lugar de hacer

((Activity1) mainActivity).hideDialog();

Se suponía que debía hacer

((Activity2) mainActivity).hideDialog();

Nota: Pero este error no ocurrió en Android 8.0 Todavía no estoy seguro de por qué.

*** Espero eso ayude.

Tuve este error de falla de segmentación debido a problemas de memoria . Mi estructura, que tenía muchas variables y matrices, tenía esta matriz de tamaño 1024.

Al reducir el tamaño a 512, el error desapareció.

PD: Esta es una solución alternativa y no una solución. Es necesario encontrar el tamaño de la estructura y la asignación de memoria dinámica es una mejor opción.

Recibí este error cuando utilicé ViewTreeObserver dentro de la onDraw()función.

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

Tuve este problema con un paquete que se agregó a mi aplicación (FancyShowCaseView) y causó este problema en pre-lolipop. ese paquete fue escrito en kotlin y mis códigos principales fueron escritos en java. así que ahora estoy verificando la versión en pre-lolipop y no dejo que se ejecute su clase. temporal resuelto el problema. mira esto si tienes un problema similar como yo

Generar huella digital: 'motorola / harpia / harpia: 6.0.1 / MPIS24.241-2.50-16 / 16: usuario / liberación-teclas' Revisión: 'p1b0' ABI: 'arm' pid: 18139, tid: 25935, nombre: GLThread 2137 >>> com.portable3d.okt.a3dmap1 <<< señal 11 (SIGSEGV), código 2 (SEGV_ACCERR), addr de fallo 0x7452f000

2 de cada 12 teléfonos devolvieron un error, encontraron que el problema estaba en onDrawFrame (), algunos objetos eran nulos, no sé por qué, solo configuré

if(gears==null) return;.

Tuve el problema cuando estaba creando un PDF usando las API de PDF de Android y accidentalmente usé el canvas.save () y el canvas.restore () después de haber cerrado una página pdf.