最近公司项目切换第三方crash检测工具，切换到了bugly，但是查看崩溃日志记录信息的时候，发现bugly上展示数据的一些异常符号，无法准确解析，如图：
原始符号表
解析后的符号表
上图中看字符名字，筛选关键字，去搜索我们工程的方法名，无匹配项，猜测第三方的静态库函数调用（应该只有第三方的静态库，才会显示我们的项目里面面），然后我们根据进程，去我们工程的静态库里面去查询，通过静态库查看函数是属于谁的，然后反馈给业务方bug，这是我的第一反应（甩锅一流）！
通过定位，猜测和查询到业务方，反馈给业务方，业务方表示方法名，的确是他们的，但是崩溃日志 上面的CoreText等调用堆栈，肯定不是他们调用的，他们不是导致崩溃的元凶，这个时候，的确感觉很尴尬（完全不知道bugly为什么会显示他们的信息），对方说：
中间两行不一定是关键点，可能是刚好崩溃前执行了这两句
但是由于主线程，感觉不太科学，所以放置到了一边，又看了一眼崩溃日志更早的堆栈信息，发现了一个好的信息
更深层的堆栈信息中包含sliderAddress
根据内存管理相关的知识，可以确定的是这个Mach-O文件加入到内存中之后，slideAddress不会变化，那么根据这个信息，可以推出来上面的崩溃日志中的sliderAddress也是这个地址，然后我就可以自己去解析尝试了。
通过尝试，的确解析成功，而且为避免是碰巧，解析了崩溃临近的几个堆栈，发现都是正确的，发现，的确不是第三方库的原因，至于为什么显示的是第三方的函数堆栈，完全无头绪，
自己解析符号表成功
至此，此崩溃日志的代码找到，但是仍旧存在的疑问是 为什么bugly会解析到第三方库的函数上面，是否是bugly的bug，毋庸置疑的是肯定是bug，但是这个bug又不是必现，那么是否和第三方库的语法或者某些特性有关呢？据悉第三方库使用的应该是C++的代码，比较好奇！有遇到过或者了解的同学可以指点一二，还有对方研发说的 中间两行不一定是关键点，可能是刚好崩溃前执行了这两句* 是否有道理，还是在主线程不成立，子线程成立？知识盲区，希望有大佬可以帮忙指点
网友评论