目录

前言

关于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为平台,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 [1024*1024*1024] 开始逐个可能造成内存错误的代码块插入上述测试代码,开始测试。

Logo

分享前沿Unity技术干货和开发经验,精彩的Unity活动和社区相关信息

更多推荐