noi*_*isy 11 android stack-trace logcat tombstoning
正如我所注意到的,logcat总是返回34行的crashlog,如下所示:
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
但是我知道堆栈也保存到了/date/tombstones/tombstone_0[0-9].在那里,我可以找到许多其他堆栈(我不完全理解它们来自哪里),其中一些是上述堆栈的两倍.
如何从我的应用程序崩溃中获得如此长的堆栈转储？
Tim*_*ird 25
android中的崩溃处理程序,称为debuggerd,只将堆栈的一部分写入日志,但将完整堆栈写入tombstone文件.这在system/core/debuggerd/debuggerd.c中是硬编码的.
查看例程debug_stack_and_code()以获取对_LOG()的调用._LOG的第二个参数控制东西是仅进入墓碑,还是记录到墓碑和墓碑.
在您看到的地方(sp_depth>2||only_in_tombstone),您可以将2更改为其他内容以获得日志中报告的更深层叠帧.这假设您可以重新编译debuggerd并将其替换为您的系统.如果没有,那么您将不得不检查逻辑删除文件本身以获得更长的堆栈转储.
当程序在Linux下崩溃时,转储是由debuggerd创建的.发生这种情况时,内核会向死亡程序发送信号.此信号由安装在每个原生Android应用程序中的特殊信号处理程序捕获.通过仿生C库.信号处理程序联系debuggerd(通过命名管道),然后使用ptrace连接回死程序以读取寄存器和内存以生成逻辑删除和日志条目.
art*_*lar 12
我建议调试tombstone文件中的堆栈跟踪,如下例所示.
例:
#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
您可以使用以下命令了解函数名称,文件名和行号.
$(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/<SO filename> <PC address>
例:
$(android-root)prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/addr2line -f -e /out/product/xxx/symbols/system/libc.so 0x00010a20
| 归档时间： |
|
| 查看次数： |
30428 次 |
| 最近记录： |