Crash定位

crash定位

转至元数据结尾

./prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-addr2line -a 000000000000be74 -e out/target/product/cas/symbols/vendor/lib64/camera/components/com.anc.node.sat.so

mi@mi-HP-ProDesk-680-G4-MT:~/K2_1006$prebuilts/./gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-addr2line-a0x00000000001c4270-eout/target/product/venus/symbols/vendor/lib64/hw/[com.qti.chi.override.so](http://com.qti.chi.override.so/)0x00000000001c4270vendor/qcom/proprietary/chi-cdk/core/chiframework/chimcxroitranslator.cpp:2338mi@mi-HP-ProDesk-680-G4-MT:/K{2}_{1}006$ prebuilts/./gcc/linux-x86/aarch64/aarch64-linux-android-4.9/bin/aarch64-linux-android-addr2line -a 0x00000000001c4288 -e out/target/product/venus/symbols/vendor/lib64/hw/com.qti.chi.override.so 0x00000000001c4288 vendor/qcom/proprietary/chi-cdk/core/chiframework/chimcxroitranslator.cpp:2386

参考：

分析流程很到位：https://blog.csdn.net/aa787282301/article/details/103464927

crash问题定位

定位crash方法总结

Native Crash的分析定位方法

[Tool][python] 自动解析Tombstone文件调用栈脚本

[方法][Debug] NativeCrash定位方法

[](https://wiki.n.miui.com/download/attachments/341510960/稳定性专题-Native Crash分析方法.pptx?version=1&modificationDate=1587995823000&api=v2) 演示

实际测试：

**自己编译的chi.so文件push手机里，相机打不开了，你说说难受不。。。。 **

第一步：~/Tool/crash$ adb pull /data/tombstones . （这个文件也可以抓取log实现，adb logcat > open.txt ,当打开相机后截断。此时open.txt中会包含如下内容）

先看最上面一句，821线程发生错误，查找相关的821线程，信号signal显示SIGSEGV

信号机制是 Linux 进程间通信的一种重要方式，Linux 信号一方面用于正常的进程间通信和同步，如任务控制(SIGINT, SIGTSTP,SIGKILL, SIGCONT，……)；另一方面，它还负责监控系统异常及中断。 当应用程序运行异常时， Linux 内核将产生错误信号并通知当前进程。 当前进程在接收到该错误信号后，可以有三种不同的处理方式。

（1）忽略该信号。

（2）捕捉该信号并执行对应的信号处理函数(signal handler)。

（3）执行该信号的缺省操作(如 SIGSEGV， 其缺省操作是终止进程)。

当 Linux 应用程序在执行时发生严重错误，一般会导致程序 crash。其中，Linux 专门提供了一类 crash 信号，在程序接收到此类信号时，缺省操作是将 crash 的现场信息记录到 core 文件，然后终止进程。

抓取tombstone文件如上，此文件含义：（来源陈阳老师PPt）tombstone文件的确就像墓碑一样记录了死亡了的进程的基本信息（例如进程的进程号，线程号），死亡的地址（在哪个地址上发生了 Crash），死亡时的现场是什么样的（记录了一系列的堆栈调用信息）等等，生成在 /data/tombstones/ 下面。显示如下：

第二步：主要关注 backtrace：它保存了发生 crash 时候的函数调用关系，但是需要注意的是它的调用顺序是从下向上执行的, 通过这些函数调用关系，我们就可以大概定位出问题发生的地方。

**#18调用了#17，#17调用了#16，以此类推，如果是库函数调用错误，比如_string，不用管。 **

#00 pc 0000000000241c80 /vendor/lib64/hw/com.qti.chi.override.so (UsecaseSelector::FreeUsecaseDescriptor(ChiUsecase*)+72) (BuildId: 29e3feacaae52367cf5c280337732b2b) #01 pc 000000000021b378 /vendor/lib64/hw/com.qti.chi.override.so (UsecaseMultiCamera::CreatePipelines(ChiUsecase*, camera3_stream_configuration*, int)+14240) (BuildId: 29e3feacaae52367cf5c280337732b2b) #02 pc 0000000000206d10 /vendor/lib64/hw/com.qti.chi.override.so (UsecaseMultiCamera::Initialize(LogicalCameraInfo*, camera3_stream_configuration*)+10640) (BuildId: 29e3feacaae52367cf5c280337732b2b) #03 pc 0000000000204294 /vendor/lib64/hw/com.qti.chi.override.so (UsecaseMultiCamera::Create(LogicalCameraInfo*, camera3_stream_configuration*)+236) (BuildId: 29e3feacaae52367cf5c280337732b2b) #04 pc 0000000000249ca8 /vendor/lib64/hw/com.qti.chi.override.so (UsecaseFactory::CreateUsecaseObject(LogicalCameraInfo*, UsecaseId, camera3_stream_configuration*)+2032) (BuildId: 29e3feacaae52367cf5c280337732b2b) #05 pc 000000000018e424 /vendor/lib64/hw/com.qti.chi.override.so (ExtensionModule::InitializeOverrideSession(unsigned int, camera3_device const*, chi_hal_ops const*, camera3_stream_configuration*, int*, void**)+4140) (BuildId: 29e3feacaae52367cf5c280337732b2b) #06 pc 00000000001828b0 /vendor/lib64/hw/com.qti.chi.override.so (chi_initialize_override_session(unsigned int, camera3_device const*, chi_hal_ops const*, camera3_stream_configuration*, int*, void**)+72) (BuildId: 29e3feacaae52367cf5c280337732b2b) #07 pc 000000000032a304 /vendor/lib64/hw/camera.qcom.so (CamX::HALDevice::ConfigureStreams(CamX::Camera3StreamConfig*)+6076) (BuildId: 183e3bdece192fb987f88c3725b1db3b) #08 pc 000000000031f2f8 /vendor/lib64/hw/camera.qcom.so (CamX::configure_streams(camera3_device const*, camera3_stream_configuration*)+3152) (BuildId: 183e3bdece192fb987f88c3725b1db3b)

问题很可能定位在第一行UsecaseSelector::FreeUsecaseDescriptor(ChiUsecase*)这个方法中。

分析工具：

**方法一： **

1**.Android NDK (来源聂磊wiki)** Linux下NDK安装和配置: 1.下载NDK：https://developer.android.com/ndk/downloads/index.html 2.解压:$unzipandroid-ndk-r12b-linux-x86_{6}4.zip(如果解压失败，可能是权限问题，给上级目录文件夹权限:$chamod 777 -R 上级文件名) 3.配置环境变量: $vim/etc/profile添加:exportNDKROOT=/home/mi/NDK/android/android-ndk-r20exportPATH=$NDKROOT/ndk-build:$PATHexportPATH=$NDKROOT/ndk-stack:$PATHexportPATH=$NDKROOT/ndk-gdb:$PATHexportPATH=$NDKROOT/ndk-which:$PATH然后使生效$source /etc/profile

2.脚本自动分析

~/Tool/crash$ python as_tomba.py ./tombstone_00.txt ./out/target/product/umi/symbols/

2.1先从以下地址找到出问题的jira对应的版本的symbol下载下来，在右侧相关文件里有symbol文件(根据源码名称一栏找对应刷机包) http://husky.pt.miui.com/buildFile/flashPackage?profileType=dev&romType=root

2.2解压文件，生成一个out文件夹，执行以上指令。（注意：后面两个必须带上路径）最后在终端显示信息及生成一个.out文件。

全部文件如下：

**as_tomba.py text filetombstone_00_820_vendor#bin#hw#android.hardware.camera.provider@2.4-service_64.out **

方法二：

addr2line：用来分析单个pc地址对应的源代码的行数，比如上log中 pc 0000000000241c80 ，0000000000241c80 就是cash时pc调用的堆栈地址。addr2line可利用这个地址分析出对应的代码行数。

命令： addr2line -e com.qti.chi.override.so 0000000000241c80 -f

或者：addr2line -Cfe com.qti.chi.override.so 241c80

解释：-e 后加上.so的文件名；-f 可同时输出函数名称

** **

注意：必须是symbols下的so文件

一般来说出问题的so对应的带symbols的so都在/j2_mi_code/out/target/product/umi/symbols/vendor/lib64/hw下面，而不能是~/j2_mi_code/out/target/product/umi/vendor/lib64/hw的，这里面的是不包含symbols信息的，拿这个去分析，输出的结果就是“??:?”。其实这两个so的体积对比也是很明显的的，在我的应用中，前一个带symbols的so的体积为7M多，而后一个只有2M。

总结：

1.一般只要看第一行错误就行！

2.远程下载下来是正确的，如果push之前没有备份导致相机打不开，又不想刷机，可以用远程下载下来替换

3.以上命令用本地的out去检查错误，才能查出本地代码错误行！

赞成为第一个赞同者

• 无标签
• 编辑标签

编写评论…

• 基于 Atlassian Confluence 7.4.17 (node4: 4ae287a7) 技术构建
• 报告缺陷
• Atlassian 新闻

Atlassian

小米信息部