Cómo averiguar la razón de un SIGSEGV en Android

He estado recibiendo un número creciente de informes de que mi aplicación de Android se bloquea, el accidente ocurre en código nativo para que no se produzca un stacktrace. Sólo tengo una función nativa y no es el problema porque se llama una vez durante el inicio y el problema ocurre 2-3 minutos más tarde.

Tengo el siguiente volcado parcial de logcat:

I/DEBUG ( 8704): pid: 9028, tid: 9136 >>> xxxx <<< I/DEBUG ( 8704): at : (2012-10-30 21:10:42.000086303 UTC) 0 I/DEBUG ( 8704): signal 11 (SIGSEGV), fault addr deadbaad I/DEBUG ( 8704): r0 00000000 r1 afd14691 r2 00000027 r3 00000070 I/DEBUG ( 8704): r4 afd42328 r5 00000000 r6 00000000 r7 0000a000 I/DEBUG ( 8704): r8 00000000 r9 4a77b900 10 4a77b8d8 fp 00000046 I/DEBUG ( 8704): ip 00001750 sp 4a77b590 lr deadbaad pc afd11ce4 cpsr 60000030 I/DEBUG ( 8704): d0 643a64696f72646e d1 6472656767756265 I/DEBUG ( 8704): d2 0000005d0000005b d3 0006000600060006 I/DEBUG ( 8704): d4 0120009c009c009c d5 000a000a000a000a I/DEBUG ( 8704): d6 0012000600060006 d7 0000000000000000 I/DEBUG ( 8704): d8 0000004600000000 d9 43f0000000000000 I/DEBUG ( 8704): d10 4040000043080000 d11 0000000043ee464c I/DEBUG ( 8704): d12 0000000000000000 d13 0000000000000000 I/DEBUG ( 8704): d14 0000000000000000 d15 0000000000000000 I/DEBUG ( 8704): d16 0505050507070707 d17 0b0b0b0b10101010 I/DEBUG ( 8704): d18 0707070703030303 d19 0000000000000000 I/DEBUG ( 8704): d20 0100010001000100 d21 0100010001000100 I/DEBUG ( 8704): d22 0000000000000000 d23 0000000000000000 I/DEBUG ( 8704): d24 0000000000000000 d25 0000000000000000 I/DEBUG ( 8704): d26 00f900f900f900f9 d27 00fb00fb00fb00fb I/DEBUG ( 8704): d28 00f000f000f000f0 d29 00f500f500f500f5 I/DEBUG ( 8704): d30 01748000016e0000 d31 01818000017b0000 I/DEBUG ( 8704): scr 20000012 I/DEBUG ( 8704): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** I/DEBUG ( 8704): Build fingerprint: \'lge/lge_bprj/lgp970/lgp970:2.2.2/FRG83G/V10a_07-JUN-2011.422D181D:user/release-keys\' I/DEBUG ( 8704): #00 pc 00011ce4 /system/lib/libc.so I/DEBUG ( 8704): #01 pc 0000be32 /system/lib/libc.so I/DEBUG ( 8704): #02 pc 0000cd92 /system/lib/libc.so I/DEBUG ( 8704): #03 pc 000008d8 /system/lib/libstdc++.so I/DEBUG ( 8704): #04 pc 0004efa4 /system/lib/libskia.so I/DEBUG ( 8704): #05 pc 0006d00c /system/lib/libskia.so I/DEBUG ( 8704): #06 pc 0006f414 /system/lib/libskia.so I/DEBUG ( 8704): I/DEBUG ( 8704): code around pc: I/DEBUG ( 8704): afd11cc4 2d00682d e029d1fb b12b68db c05cf8df I/DEBUG ( 8704): afd11cd4 f8442001 4798000c e054f8df 26002227 I/DEBUG ( 8704): afd11ce4 2000f88e eecaf7fb f7fc2106 f04feff8 I/DEBUG ( 8704): afd11cf4 91035180 460aa901 96012006 f7fc9602 I/DEBUG ( 8704): afd11d04 a905eb6e 20024632 eb78f7fc eeb6f7fb I/DEBUG ( 8704): I/DEBUG ( 8704): code around lr: I/DEBUG ( 8704): deadba8c ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 8704): deadba9c ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 8704): deadbaac ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 8704): deadbabc ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 8704): deadbacc ffffffff ffffffff ffffffff ffffffff I/DEBUG ( 8704): I/DEBUG ( 8704): stack: I/DEBUG ( 8704): 4a77b550 00000015 I/DEBUG ( 8704): 4a77b554 afd146c1 /system/lib/libc.so I/DEBUG ( 8704): 4a77b558 afd425a0 /system/lib/libc.so I/DEBUG ( 8704): 4a77b55c afd4254c /system/lib/libc.so I/DEBUG ( 8704): 4a77b560 00000000 I/DEBUG ( 8704): 4a77b564 afd156db /system/lib/libc.so I/DEBUG ( 8704): 4a77b568 afd14691 /system/lib/libc.so I/DEBUG ( 8704): 4a77b56c afd14691 /system/lib/libc.so I/DEBUG ( 8704): 4a77b570 00000070 I/DEBUG ( 8704): 4a77b574 afd42328 /system/lib/libc.so I/DEBUG ( 8704): 4a77b578 00000000 I/DEBUG ( 8704): 4a77b57c 4a77b5a4 I/DEBUG ( 8704): 4a77b580 0000a000 [heap] I/DEBUG ( 8704): 4a77b584 afd14933 /system/lib/libc.so I/DEBUG ( 8704): 4a77b588 df002777 I/DEBUG ( 8704): 4a77b58c e3a070ad I/DEBUG ( 8704): #00 4a77b590 afd43904 /system/lib/libc.so I/DEBUG ( 8704): 4a77b594 afd103ec /system/lib/libc.so I/DEBUG ( 8704): 4a77b598 afd42328 /system/lib/libc.so I/DEBUG ( 8704): 4a77b59c 49687628 I/DEBUG ( 8704): 4a77b5a0 49687628 I/DEBUG ( 8704): 4a77b5a4 fffffbdf I/DEBUG ( 8704): 4a77b5a8 afd42328 /system/lib/libc.so I/DEBUG ( 8704): 4a77b5ac afd4374c /system/lib/libc.so I/DEBUG ( 8704): 4a77b5b0 49687628 I/DEBUG ( 8704): 4a77b5b4 afd0be37 /system/lib/libc.so I/DEBUG ( 8704): #01 4a77b5b8 49687660 I/DEBUG ( 8704): 4a77b5bc 00430a60 [heap] I/DEBUG ( 8704): 4a77b5c0 00001424 I/DEBUG ( 8704): 4a77b5c4 4a77b8b0 I/DEBUG ( 8704): 4a77b5c8 00000000 I/DEBUG ( 8704): 4a77b5cc 49687628 I/DEBUG ( 8704): 4a77b5d0 49687628 I/DEBUG ( 8704): 4a77b5d4 00000000 I/DEBUG ( 8704): 4a77b5d8 4a77b8b0 I/DEBUG ( 8704): 4a77b5dc afd0cd95 /system/lib/libc.so 

Mi pregunta:

Sé que puedo encontrar la función nativa en la que el sigsegv sucede a partir de esto, pero no estoy seguro de dónde obtener la biblioteca nativa para encontrar esto. Sucede en el teléfono de un usuario, no tengo acceso directo a él O al usuario … ¿Existe un sitio web con estas bibliotecas o puedo construirlas mientras permanezcan igual que el del teléfono? ¿O hay una mejor manera de depurar estos?

Gracias por leer, cualquier idea es bienvenida 🙂

Actualizar:

Como se sugirió, usando ndk-stack como así:

 ./ndk-stack -sym LONGPATH/armeabi -dump foo.txt 

Donde foo.txt contiene la huella "Build fingerprint", comenzando con una línea con muchas estrellas (busca eso), pero todo lo que obtengo es:

 ********** Crash dump: ********** Build fingerprint: \'lge/lge_bprj/lgp970/lgp970:2.2.2/FRG83G/V10a_07-JUN-2011.422D181D:user/release-keys\' 

Y el programa se detiene ..

Editar2:

Usando arm-linux-androideabi-addr2line y una ROM descargada FRG83G tengo un poco más lejos:

Apunta a alarmar, dlmalloc_trim y realloc en libc.so, para borrar en ligstdc ++. SI8_D16_filter_DXDY y SI8_D16_filter_DXDY , drawBitmap , clipQuad en libskia.so

Ahora viene la parte divertida, qué hacer con esta información .. Voy a continuar mañana, es 0530 aquí ..

Editar3:

Estoy un paso más, pero se quedó de nuevo, los valores de la PC en el punto de volcado a las funciones en libskia.so, he encontrado que el uso de un objeto de pintura en múltiples subprocesos al mismo tiempo puede causar este problema, no lo hago pero Hice reutilizar BitmapFactory.Options , con la esperanza de que ese era el problema, he eliminado esa parte, sigue chocando … El volcado señala a SkBitmapProcShader::SkBitmapProcShader , SkTriColorShader::shadeSpan y SkDraw::drawBitmap . El último es el más obvio para señalar a los problemas de mapa de bits .. Pero no es BitmapFactory.Options o Paint objetos ..

Para encontrar la razón de la señal 11, tiene que usar la herramienta ndk-stack . Para cualquier ayuda utilice el siguiente enlace como referencia.

http://yssays.wordpress.com/2011/12/27/android-ndk-stack-tool/

"Sólo tengo una función nativa y no es el problema porque se llama una vez durante el inicio y el problema ocurre 2-3 minutos después".

Bzzzztt! Incorrecto. Es completamente posible trash memoria en un lugar …. luego fallan cuando intenta acceder a la (ahora corrupto) memoria en una parte completamente diferente del programa.

Supongo que estás usando el NDK.

Sugerencias:

1) poner valores "centinela" alrededor de cualquier memoria global o buffer malloc'ed.

2) Revise cuidadosamente todos los "malloc ()" ("deadbaad" suena sospechosamente como algo que se ha asignado desde el montón)

3) Busque consejos sobre cómo usar ndk-gdb:

PD:

¿Es tu código nativo C o C ++?

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.