使用Bugly对Native lib的crash bug进行定位

Bugly对产品质量的帮助

Tencent的Bugly算得上是APP开发质量保证的良心之作，可以将APP的crash log收集到bugly上，这样我们可以从后台看到不同版本APP的所有crash信息，通过对应的callstack就可以定位到crash发生的位置，从而解决问题。
对APP code来讲，bugly已经非常好用，callstack非常详尽的信息足够用，但是对C++的native lib carsh，对应的信息就不太够用了（在没有导入符号表的情况下）。

使用Bugly进行Native lib的crash定位

为了让bugly对native lib的crash也提供足够的帮助，我们需要在bugly上有对应native lib的符号表，当bugly上有了符号表以后，当native crash info上传bugly后，bugly会自动帮我们查到符号表显示出来，从而给我们更友好的crash callstack显示。
让bugly有native lib符号表有两种方式：

1. 手动生成符号表，手动上传到bugly；
2. 使用Android Studio插件在build APK的时候自动生成符号表上传；

下面分别对两种方式进行介绍。

手动生成符号表

0. 前提：找到对应的debug lib

使用readelf -S来确定是否是debug lib，如果是debug lib，readelf的结果中会有debug info的section

readelf -S debuglib.so

Snipaste_2018-10-16_16-31-11.jpg

后续的操作都需要使用debug lib来进行。

1. 生成符号表

java -jar buglySymbolAndroid.jar -i ../debug/debuglib.so -a armeabi

-i: 指定so的路径
-a: 指定so的对应架构

2. 上传符号表

在对应native lib crash的崩溃分析页面，进行符号表的上传。

自动生成符号表上传

参考
Bugly符号表插件使用指南

bugly上没有符号表时的本地定位

在bugly上的error部分有如下

#02 pc 0038fef8 libicatch_iot_sdk.so aacSampling [armeabi-v7a]

其中0038fef8就是对应的地址，可以通过addr2line工具和原始的包含debug信息的so file来获得对应是在哪个函数的多少行的位置。

addr2line -e debuglib.so 0038fef8 

如上的cmd可以在addr2line的帮助下得到是在哪个source file的行数

参考

1. Bugly Android SO 符号表配置