目录

前言

关于Unity符号表

正文

程序crash日志：

解析

后记

记一次 Bugly 崩溃查找过程 unity-il2cpp：

前言

关于Unity符号表

        关于项目真机调试时的崩溃问题，一般可以 logcat 或 xcode 看到相关的crash日志，拿到崩溃时的堆栈信息。但是 backtrace 中的地址信息并不直接可见（非debug版本的so库，并不包含符号表等调试信息），因此我们需要拿到对应的符号表，借助 ndk 的 addr2line 工具（arm-linux-androideabi-addr2line.exe，具体须根据调试环境选择）来查看：

        这里主要说下unity的符号表：libunity/libmain——Unity5.3.6 开始的版本都有提供（unity的安装目录下）。

        个人开发主要在 win 平台，对应的符号表目录如下：

        注1：调试时，符号表版本须与打包APK的Editor版本一致；
        注2：addr2line usage：arm-linux-androideabi-addr2line -f -C -e libunity.sym.so %addr_lst%
-f- Show function names 
-C- Demangle function names 
-e- Set the input file name
        注3：cocos2dx亦然，没有单独的符号表文件，调试时使用debug版本的so库文件即可；
        注4：若crash的点在li2cpp，则需要关注其符号表——发出apk包中的libil2cpp.so不包含符号表，需要使用打包apk时自动生成的压缩包。

正文

程序crash日志：

        我们可以通过crash日志信息，查看程序crash在什么地方。

        在这份堆栈信息里，可以看到崩溃时的内存地址，例如0049b647这样的数字。每行的结尾则是所使用的库，例如：libunity.so

        在Unity 5.3.6之后的版本，Unity提供了libunity.so的符号表。

解析

        OK，万事俱备，我们接下来就来解析一下第一条内存地址所对应的方法。

        可以看到crash的方法是三变量的一个方法，如此，我们便可以去debug：

注意：调试so文件，需要使用对应的 addr2line 工具。 

32-bits
 NDK \ toolchains \ arm-linux-androideabi-4.9 \ prebuilt \ windows-x86_64 \ bin \ arm-linux-androideabi- addr2line.exe

64-bits 
NDK \ toolchains \ aarch64-linux-android-4.9 \ prebuilt \ windows-x86_64 \ bin \ aarch64-linux-android- addr2line.exe

c# – Addr2line 64bit tool – Stack Overflowhttps://stackoverflow.com/questions/63709153/addr2line-64bit-tool

后记

记一次 Bugly 崩溃查找过程 unity-il2cpp：

Bugly 上面的崩溃，刚打开根本看不懂什么函数、什么堆栈…

1、 一开始想到的是把 il2cpp 的代码生成符号文件，上传到 bugly 但是找了一大圈，并没有 il2cpp 的符号文件，debug 版本的话 代码也不一样 毫无参考价值；

2、 就算是找到了符号表 也看不懂，il 代码变为 cpp 代码根本看不懂；

3、 开始根据堆栈尝试还原，因为是内存错误，首先想到的是无效指针，或者大内存分配失败，通过可以制造崩溃，然后看 bugly 的堆栈信息是否吻合，如果吻合那么就证明是这里的调用堆栈的问题了。然后查起来就容易多了；

4、崩溃堆栈起始是_pthread_startXXXX, 基本可以断定是我们开的线程里面出错，unity 主线程的话会是 UnityMain。

5、代码里面只有网络部分是自己开的线程，重点审查代码，var x = new byte [1024*1024*1024] 开始逐个可能造成内存错误的代码块插入上述测试代码，开始测试。