¿Cómo obtener un volcado de pila más largo (lápida) desde android?

Como he notado, logcat devuelve siempre 34 líneas de crashlog, como esto:

4cf7c700 401c0000 4cf7c704 48463ff0 4cf7c708 44d11f7c 4cf7c70c afd0cd89 4cf7c710 00000000 4cf7c714 82ab29dc libmyproject.so 4cf7c718 00000000 4cf7c71c 4cf7c73c 4cf7c720 836c44f0 libmyproject.so 4cf7c724 82f3a414 libmyproject.so 4cf7c728 4cf7c768 4cf7c72c 0000008d 4cf7c730 007ea0a8 [heap] 4cf7c734 00270100 [heap] 4cf7c738 e3a07077 4cf7c73c ef900077 4cf7c740 00000000 4cf7c744 4cf7c774 4cf7c748 836c44f0 libmyproject.so 4cf7c74c 00000000 4cf7c750 836c44f0 libmyproject.so 4cf7c754 82f63768 libmyproject.so 4cf7c758 00000000 4cf7c75c 4cf7c7e4 4cf7c760 00000000 4cf7c764 00000001 4cf7c768 00000000 4cf7c76c 0badc0de 4cf7c770 fffffff8 4cf7c774 00000000 4cf7c778 00000168 4cf7c77c 00000009 4cf7c780 00000200 4cf7c784 00000000 

Sin embargo, sé que la pila también se guarda en /date/tombstones/tombstone_0[0-9] . Allí puedo encontrar muchas otras pilas (no entiendo completamente de donde vinieron) y algunas de ellas son dos veces más largas que la mencionada pila.

¿Cómo conseguir volcado de pila tan largo de un accidente de mi aplicación?

El programa de manejo de fallos en android, que se llama debuggerd, sólo escribe una parte de la pila en el registro, pero escribe la pila completa en el archivo de la piedra sepulcral. Esto se codifica en el sistema / core / debuggerd / debuggerd.c.

Busque en la rutina debug_stack_and_code () para las llamadas a _LOG (). El segundo parámetro de _LOG controla si las cosas van sólo a la lápida, o al registro y la lápida.

Donde vea (sp_depth>2||only_in_tombstone) , puede cambiar el 2 a algo más para obtener los marcos de pila más profundos informados en el registro. Esto supone que puede volver a compilar debuggerd y reemplazarlo en su sistema. Si no, usted está atascado con examinar los archivos de la piedra sepulcral ellos mismos para los vertederos más largos de la pila.

Los depósitos son creados por debuggerd cuando un programa se bloquea bajo Linux. Cuando esto sucede, el kernel enviará una señal al programa de morir. Esta señal es detectada por un controlador de señal especial instalado en cada aplicación nativa de Android. Por la biblioteca biónica C. El manejador de señales contacta con debuggerd (a través de una canalización con nombre), que luego se conecta al programa de morir usando ptrace para leer los registros y la memoria para producir las entradas de la lápida y el registro.

Sugiero depurar el rastro de la pila encontrado en el archivo de la piedra sepulcral como el ejemplo abajo.

Ejemplo:

 #00 pc 00010a20 /system/lib/libc.so #01 pc 0000b332 /system/lib/libc.so #02 pc 0000ca62 /system/lib/bluez-plugin/audio.so #03 pc 0000d1ce /system/lib/bluez-plugin/audio.so #04 pc 0000e0ba /system/lib/bluez-plugin/audio.so 

Puede utilizar el comando siguiente para conocer el nombre de la función, el nombre del archivo y el número de línea.

 $(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/<SO filename> <PC address> 

Ejemplo:

 $(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/libc.so 0x00010a20 
  • Obtención de seguimiento de pila en Android NDK
  • Cliente autónomo de Logcat
  • Cómo ver el seguimiento de la pila de errores en android?
  • E.printStackTrace (); En cuerda
  • Rastro de la pila de la consola de Google Play
  • Obtenido un stacktrace de Android Market que menciona la aplicación de un competidor
  • Android proguard incompleto stacktrace
  • ARM Ensamblado backtrace PC offset
  • Intenta invocar el método de interfaz 'boolean java.util.List.add (java.lang.Object)' en una referencia de objeto nulo
  • No puedo calcular el problema con un error de stacktrace
  • Trace: requestLayout () incorrectamente llamado?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.