Unity 符号表

前言

关于Unity符号表

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

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

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

其中1为平台，2为后端（il2cpp、mono），3为release或develop

    注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 [102410241024] 开始逐个可能造成内存错误的代码块插入上述测试代码，开始测试。