滴滴国际化外卖 Android 商户端正常迭代版本过程中,新版本发布并且线上稳定一段时间后,突然触发线上 Crash 报警。
第一次排查发现是在依赖的底层平台 so 库中崩溃,经过沟通了解到其之前也存在过崩溃问题,所以升级相关底层 so 版本。重新发版后短期没有出现 Crash 大面积上报情况,只有零星上报,但不久后又发生了第二次大面积 Crash 上报。具体信息如下图所示:
在定位分析问题的过程中收获很多,通过这篇文章分享该 Crash 的排查过程、问题根因以及一些经验总结,希望能为读者在遇到同类型问题时提供一些参考。
排查流程
Crash 描述
Crash 的量级,从两次高峰期的峰值来看,集中爆发的峰值为每日50次左右,第二次爆发的峰值最高为173次。同时,Crash 和影响用户数量是一比一。
两次大面积爆发的问题设备集中在华为的三款机型,运行时间都在14天左右,内存情况正常,线程情况正常,此时还没有相关线索指向句柄,所以这个时候没有关注句柄,如下图:
定位分析
从整体的 Crash 描述以及 Crash 统计平台的相关数据来分析,每隔14天就大面积爆发一次,可以确定是周期性问题,这种问题的排查难度较高。
根据上报的错误日志,明确其崩溃位置是在底层的 libpush.so 库,同时和其维护的同学沟通后发现依赖的 so 版本出现过问题,所以我们在第一次大面积上报之后,升级了底层 so 库版本。虽然当时增发版本后没有明显的 Crash 上报,但还是存在零星的 Crash 上报,这让我们放松了警惕,未对问题的根因进行定位,才导致了后面更严重的第二次爆发。
第二次爆发后,通过分析 Crash 统计平台上的173次 Crash 日志信息发现,Crash 代码地址都是“000000000007ce08”,如下图,由于静态库中的代码地址都是固定的,所以对底层 so 库进行了代码定位。