浅谈 Android Tombstone（墓碑日志）分析步骤 - 02

原创已于 2023-07-03 10:22:38 修改 · 2.7k 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#android

于 2023-06-30 19:15:22 首次发布

文章详细描述了如何解析一个Android系统的tombstone日志，特别是针对一个与相机服务相关的崩溃事件。通过addr2line工具定位到代码中的问题方法，虽然由于logd日志被覆盖，无法获取完整上下文，但作者提到了使用stack脚本可以简化这一过程。

tomestone 日志：



*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'qti/trinket/trinket:11/RKQ1.211119.001/37:user/test-keys'
Revision: '0'
ABI: 'arm'
Timestamp: 2023-06-19 23:47:31+0800
pid: 742, tid: 32482, name: CAM_MctBus_3  >>> /vendor/bin/hw/android.hardware.camera.provider@2.4-service <<<
uid: 1047
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0xf1c0b000
    r0  f1c0b000  r1  f0bc2e30  r2  a3e7e031  r3  00000000
    r4  00000030  r5  e30a2000  r6  e41c0010  r7  e41cf1e8
    r8  e41cf1e8  r9  e9140010  r10 f101b124  r11 e9141718
    ip  f10104a8  sp  e7cfbf48  lr  eed906ed  pc  eed9e7c2

backtrace:
      #00 pc 0001a7c2  /vendor/lib/libmmcamera2_mct.so (mct_stream_process_bus_msg+1090) (BuildId: c7b8b07e3cfc6442102b77d8c5cb2c94)
      #01 pc 00011b07  /vendor/lib/libmmcamera2_mct.so (mct_pipeline_process_bus_msg+66) (BuildId: c7b8b07e3cfc6442102b77d8c5cb2c94)
      #02 pc 00015f77  /vendor/lib/libmmcamera2_mct.so (mct_bus_handler_thread_run+722) (BuildId: c7b8b07e3cfc6442102b77d8c5cb2c94)
      #03 pc 0008175b  /apex/com.android.runtime/lib/bionic/libc.so (__pthread_start(void*)+40) (BuildId: ce538316b794b365cfbcadf267fef2dc)
      #04 pc 0003a3ed  /apex/com.android.runtime/lib/bionic/libc.so (__start_thread+30) (BuildId: ce538316b794b365cfbcadf267fef2dc)

先看 #04。

首先，确认 #04 所对应的 libc.so 所在的位置，在 ./out/target/ 下执行命令：

/out/target$ find . -name libc.so*

找到 so 位置：

   ./out/target/product/qssi/symbols/apex/com.android.runtime/lib/bionic/libc.so

接着再执行命令：

./prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-addr2line -f -e ./out/target/product/qssi/symbols/apex/com.android.runtime/lib/bionic/libc.so 0003a3ed

定位出问题方法具体位置：

打开代码，找到方法调用链中的首个方法：

找到首个方法位置后，再看，这个链其实不长，而且墓碑日志记录很清晰，是 /vendor/bin/hw/android.hardware.camera.provider@2.4-service 发生了问题，因此接下来直接找链中最后一个方法调用，也就是 #00。

看#00，首先确认 libmmcamera2_mct.so 所在位置，在 ./out/target/ 下执行命令：

find . -name libmmcamera2_mct.so*

如下图找到带符号的 so 库位置：

即：

./out/target/product/trinket/symbols/vendor/lib/libmmcamera2_mct.so

接着再执行命令：

./prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-addr2line -f -e ./out/target/product/trinket/symbols/vendor/lib/libmmcamera2_mct.so 0001a7c2

定位出问题方法位置：

查看文件
~/workspace/code_v01_dev/LINUX/android/vendor/qcom/proprietary/mm-camera/mm-camera2/media-controller/mct/stream/mct_stream.c 的 4196 行：

当前是找到了首、尾两处，但是具体的问题分析，还得再结合日志进行分析。

结合 logd 日志，墓碑日志记录于 2023-06-19 23:47:31，logd 中最旧的日志记录的最早时间是 06-20 14:12:02.454747，所以前置操作日志已经被覆盖冲掉，无法参考 logd 日志分析问题。

待继续分析。。

---------------------------------------------------------------------------------------------------------------------------------

我去，上面吭哧吭哧，执行了一堆命令才找到两处代码调用。刚发现一篇博客（博客），其实可以直接使用 stack 就可以一键发现所有地方，即使找到的不全，再结合使用 addr3line 自己转一下，也就差不多就找全了。

以上面这个 tombstone 日志为例，在 ./development/scripts 目录下执行命令：



// hgd_tombstone_01 ：tombstone文件名字
// hgd_01_check ：保存转换后的文本


stack hgd_tombstone_01 > hgd_01_check

打开转换后的 hgd_01_check 文件：

也定位到了 4196行处。