如何分析android tombstone？

前不久一个项目在调用so库的时候出现了tombstone，一开始看打印也是一头雾水，无从下手。但是后面经过分析发现log信息已经将问题说明得很清楚了。

01-06 22:55:44.029  7654  7654 F DEBUG   : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
01-06 22:55:44.029  7654  7654 F DEBUG   : Build fingerprint: 'HiDPT/Hi3751V811_DMO/Hi3751V811:8.0.0/OPR6.170623.013/0704:eng/release-keys'
01-06 22:55:44.029  7654  7654 F DEBUG   : Revision: '0'
01-06 22:55:44.029  7654  7654 F DEBUG   : ABI: 'arm64'
01-06 22:55:44.029  7654  7654 F DEBUG   : pid: 7634, tid: 7634, name: com.android.tp  >>> com.android.tp <<<
01-06 22:55:44.029  7654  7654 F DEBUG   : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
01-06 22:55:44.032  7654  7654 F DEBUG   : Abort message: 'FORTIFY: write: prevented 21-byte read from 18-byte buffer'
01-06 22:55:44.032  7654  7654 F DEBUG   :     x0   0000000000000000  x1   0000000000001dd2  x2   0000000000000006  x3   0000000000000008
01-06 22:55:44.032  7654  7654 F DEBUG   :     x4   0000000000000000  x5   0000000000000000  x6   0000000000000000  x7   0000000000000018
01-06 22:55:44.032  7654  7654 F DEBUG   :     x8   0000000000000083  x9   0ca59d5ffcfaec84  x10  0000000000000000  x11  0000000000000001
01-06 22:55:44.033  7654  7654 F DEBUG   :     x12  ffffffffffffffff  x13  0000000000000001  x14  0039a3410b62d6c0  x15  00000177a6aaadac
01-06 22:55:44.033  7654  7654 F DEBUG   :     x16  0000007658aec2f8  x17  0000007658a8e5d0  x18  0000000000000020  x19  0000000000001dd2
01-06 22:55:44.033  7654  7654 F DEBUG   :     x20  0000000000001dd2  x21  000000763ec97000  x22  0000007fe6ff2f8c  x23  000000763ee752dd
01-06 22:55:44.033  7654  7654 F DEBUG   :     x24  0000000000000000  x25  00000076578bea98  x26  0000000000000000  x27  0000000000000000
01-06 22:55:44.033  7654  7654 F DEBUG   :     x28  0000007fe6ff2ce0  x29  0000007fe6ff26c0  x30  0000007658a42994
01-06 22:55:44.033  7654  7654 F DEBUG   :     sp   0000007fe6ff2680  pc   0000007658a8e5d8  pstate 0000000060000000
01-06 22:55:44.254  6665  7039 E UpnpBootBroadcastServiceDMR: timerExpire ==35
01-06 22:55:44.255  6665  7039 D UpnpBootBroadcastServiceDMR: sleep 1000 for net check
01-06 22:55:44.280  6680  7045 E MediaService: timerExpire ==35
01-06 22:55:44.282  6680  7045 D MediaService: sleep 1000 for net check
01-06 22:55:44.437  7654  7654 F DEBUG   :
01-06 22:55:44.437  7654  7654 F DEBUG   : backtrace:
01-06 22:55:44.437  7654  7654 F DEBUG   :     #00 pc 00000000000695d8  /system/lib64/libc.so (tgkill+8)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #01 pc 000000000001d990  /system/lib64/libc.so (abort+88)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #02 pc 00000000000253b4  /system/lib64/libc.so (__fortify_fatal+120)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #03 pc 0000000000021568  /system/lib64/libc.so (__write_chk+104)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #04 pc 00000000000015d8  /system/app/AutoTest/lib/arm64/libtouchuart_fac.so (InitVirtualInput+88)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #05 pc 0000000000002e7c  /system/app/AutoTest/lib/arm64/libtouchuart_fac.so (Java_com_android_tp_TouchNative_setup+216)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #06 pc 000000000050ff00  /system/lib64/libart.so (art_quick_generic_jni_trampoline+144)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #07 pc 0000000000506e38  /system/lib64/libart.so (art_quick_invoke_static_stub+600)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #08 pc 00000000000d804c  /system/lib64/libart.so (_ZN3art9ArtMethod6InvokeEPNS_6ThreadEPjjPNS_6JValueEPKc+260)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #09 pc 0000000000281bbc  /system/lib64/libart.so (_ZN3art11interpreter34ArtInterpreterToCompiledCodeBridgeEPNS_6ThreadEPNS_9ArtMethodEPKNS_7DexFile8CodeItemEPNS_11ShadowFrameEPNS_6JValueE+352)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #10 pc 000000000027c284  /system/lib64/libart.so (_ZN3art11interpreter6DoCallILb0ELb0EEEbPNS_9ArtMethodEPNS_6ThreadERNS_11ShadowFrameEPKNS_11InstructionEtPNS_6JValueE+672)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #11 pc 00000000004ef868  /system/lib64/libart.so (MterpInvokeStatic+468)
01-06 22:55:44.437  7654  7654 F DEBUG   :     #12 pc 00000000004f8614  /system/lib64/libart.so (ExecuteMterpImpl+14612)

看到这样一大坨打印是有些烦躁，但只需要抓取我们需要的部分。

01-06 22:55:44.029 7654 7654 F DEBUG : pid: 7634, tid: 7634, name: com.android.tp >>> com.android.tp <<<

==>这里是指发生tombstone的pid，以及包名。
01-06 22:55:44.029 7654 7654 F DEBUG : signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
01-06 22:55:44.032 7654 7654 F DEBUG : Abort message: 'FORTIFY: write: prevented 21-byte read from 18-byte buffer'

==》这个地方表明发生了中断，另外注意'FORTIFY: write: prevented 21-byte read from 18-byte buffer'，这句是后面解决问题的关键。那么究竟是哪个地方要阻止从18个字节读取20个字节呢？继续往下看，发现我所使用so库的名称。

01-06 22:55:44.437 7654 7654 F DEBUG : #04 pc 00000000000015d8 /system/app/AutoTest/lib/arm64/libtouchuart_fac.so (InitVirtualInput+88)
01-06 22:55:44.437 7654 7654 F DEBUG : #05 pc 0000000000002e7c /system/app/AutoTest/lib/arm64/libtouchuart_fac.so (Java_com_android_tp_TouchNative_setup+216)

这个so库正是我项目中使用的，我们通过add2line这个工具来定位出问题代码的位置。进入系统代码so库所在位置：

/out/target/product/Hi3751V811/symbols/system/lib64# addr2line -f -e  libtouchuart.so 0x00000000000015d8
InitVirtualInput
lib_tp_uart.c:0
/out/target/product/Hi3751V811/symbols/system/lib64# addr2line -f -e  libtouchuart.so 0x0000000000002e7c
_send_uinput_event
Tp_uart.c:389

注意是要在symbos目录下进行该操作，不然在system目录下会出现解不出来的情况

addr2line -f -e libtouchuart_fac.so 0x00000000000015d8
??
??:0

上面已经定位出了出问题的地方，查看so库的源码，很容易就看出问题所在

write(input_fd,"open /dev/uinput\n",21);

这里实际的长度是18，但是传入的参数却是21，所以开头那句打印FORTIFY: write: prevented 21-byte read from 18-byte buffer已经说明原因了。这里最好使用sizeof来获取长度，即可避免问题。

总结：

本文主要是记录下解决tombstone问题的大概思路。因为是调用自己的so库，所以问题还比较容易定位。

如何分析android tombstone？相关推荐

如何调试分析Android中发生的tombstone
2019独角兽企业重金招聘Python工程师标准>>> 如何调试分析Android中发生的tombstone Android中较容易出现以下三类问题:Force close / AN ...
android tombstone发生过程,如何调试分析Android中发生的tombstone
如何调试分析Android中发生的tombstone Android中较容易出现以下三类问题:Force close / ANR / Tombstone 前两者主要是查看当前的进程或者系统框架层的状态 ...
Android tombstone 分析案例
Android tombstone 分析案例 tombstone文件内容 1. 体系结构 2. 发生Crash线程 3. 原因 4. 寄存器状态 4.1 处理器工作模式下的寄存器 4.2 未分组寄存器 ...
Android10.0 日志系统分析(三)-logd、logcat读写日志源码分析-[Android取经之路]
摘要:本节主要来讲解Android10.0 logd.logcat读写日志源码内容阅读本文大约需要花费20分钟. 文章首发微信公众号:IngresGe 专注于Android系统级源码分析,Andro ...
通过源码分析Android 的消息处理机制
2019独角兽企业重金招聘Python工程师标准>>> #通过源码分析Android 的消息处理机制我们知道,Android应用是通过消息来驱动的,每一个进程被fork之后,都会在 ...
【Android 安全】DEX 加密 ( 不同 Android 版本的 DEX 加载 | Android 8.0 版本 DEX 加载分析 | Android 5.0 版本 DEX 加载分析 )
文章目录一.不同版本的 DEX 加载 1.Android 8.0 版本 DEX 加载分析 2.Android 6.0 版本 DEX 加载分析 3.Android 5.0 版本 DEX 加载分析一. ...
简述用 MAT 分析 Android 应用OOM
OOM(OutOfMemoryError) 相信是所有 Android 开发者遇到的最多的 Error,因此找出个中缘由是非常重要. 这里用到的分析工具主要是 Eclipse MAT 插件http:/ ...
分析Android studio3.0的instant run开启关闭对APK大小的影响
分析Android studio3.0的instant run开启关闭对APK大小的影响首先看下默认开启instant run的截图: Android studio2.0后新增加的功能默认开启ins ...
源码分析Android Handler是如何实现线程间通信的
源码分析Android Handler是如何实现线程间通信的 Handler作为Android消息通信的基础,它的使用是每一个开发者都必须掌握的.开发者从一开始就被告知必须在主线程中进行UI操作.但H ...

如何分析android tombstone？

如何分析android tombstone？相关推荐

最新文章

热门文章