大侦探福老师——幽灵崩溃谜踪案

  

  闲鱼摆动技术的基础设施已基本趋于稳定,就在我们准备松口气的时候,一个崩溃却异军突起冲击着我们的稳定性防线!闲鱼技术火速成立侦探小组执行嫌犯侦查行动,经理重重磨难终于在一个隐蔽的角落将其绳之以法!   

  

  幽灵崩溃   

  

  问题要从闲鱼颤振基础设施上一次大规模升级说起.2018年我们对闲鱼的颤振基建作了比较大的重构,目标在于提高基建的稳定性和可扩展性。这个过程当然是挑战重重,在上一次大规模的重构集成发版后,我们虽然没有发现非常明显的异常问题,但是失事率却出现了一个比较明显的增长,虽然总体数值还在可控范围之内,但这一个崩溃却占据了几乎一大半。这个问题引起了我们警觉,我们立刻成立专项小组重点进行排查。   

  

  一般崩溃日志能够为我们定位崩溃提供主要信息,我们一起看看这个崩溃的日志:   

     <前>   Thread  0,崩溃:   0,,,libobjc.A.dylib ,,,,,,,,,,,,,,,, 0 x00000001c1b42b00  objc_object::释放(),:16,(libobjc.A.dylib拷贝)   1,,,libobjc.A.dylib ,,,,,,,,,,,,,,,, 0 x00000001c1b4338c  (anonymous 名称空间)::AutoreleasePoolPage::流行(void *), 676, (libobjc.A.dylib拷贝)   2,,,CoreFoundation ,,,,,,,,,,,,,,,,, 0 x00000001c28e8804  __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ : 28日,(CoreFoundation)必要拷贝   3,,,CoreFoundation ,,,,,,,,,,,,,,,,, 0 x00000001c28e8534  __CFRunLoopDoTimer : 864, (CoreFoundation)必要拷贝   4,,,CoreFoundation ,,,,,,,,,,,,,,,,, 0 x00000001c28e7d68  __CFRunLoopDoTimers : 248, (CoreFoundation)必要拷贝   5,,,CoreFoundation ,,,,,,,,,,,,,,,,, 0 x00000001c28e2c44  __CFRunLoopRun : 1880, (CoreFoundation)必要拷贝   6,,,CoreFoundation ,,,,,,,,,,,,,,,,, 0 x00000001c28e21cc  _CFRunLoopRunSpecific : 436, (CoreFoundation)必要拷贝   7,,,GraphicsServices ,,,,,,,,,,,,,,, 0 x00000001c4b59584  _GSEventRunModal : 100, (GraphicsServices拷贝)   8,,,UIKitCore ,,,,,,,,,,,,,,,,,,,,,, 0 x00000001efb59054  _UIApplicationMain : 212, (UIKitCore拷贝)   9,,,Runner ,,,,,,,,,,,,,,,,,,,,,,,,, 0 x0000000102df4eb4  main  main.m: 49,(运动员)拷贝   10,,libdyld.dylib ,,,,,,,,,,,,,,,,,, 0 x00000001c23a2bb4  _start : 4, (libdyld.dylib拷贝)   之前      

  这是一个很典型的野指针崩溃日志,是其中一种俗称在发布的问题。但是具体是哪个对象和方法,很难直接从日志上面得知,况且电弧下面的野指针更令人费解。   

  

  一些推测   

  

  崩溃理因由变更引入的,我们直觉地从最近发版引入的主要变更去推测,考虑到我们开始出现问题的版本有几个比较大的改造,我们让相关的同学重新审查了一下自己的代码,主要关注内存方面的问题。虽然没有找到非常确切的问题,我们还是进行了一次可疑代码优化,进行技术灰度却没有任何效果。在庞大的代码库数不清的提交中去找寻毫无头绪的野指针问题看起来不是一件容易的事情,   

  

  机型iOS版本闲鱼版本   

  

  我们详细的分析了崩溃的数据以及用户操作日志,然后得出结论这个崩溃与机型,系统版本都没明显联系。但是我们可以发现用户基本上都是在颤振容器的详情页容易.Flutter不可避免成为了被怀疑对象,包括我们自己实现的基础设施,以及颤振底层的库。   

  

  但是颤振已经在闲鱼应用比较长的一段时间,颤振底层我们几乎确定是稳定的,不然早就出问题了。这个时候主要怀疑点转移到了我们自己实现的组件,主要包括混合栈组件以及一些监控埋点设施。但是我们随后将这些怀疑对象通过技术灰度手段一一排除了嫌疑。   

  

  版本走势   

  

  从版本的失事率的走势看,我们还发现这个问题有一个缓慢增长放量的过程,这不免让我们开始怀疑应用是否存在类似的慢慢放量的功能需求。然而事实证明,这个方向没有任何收获。   

  

  无法复现的问题   

  

  不断有用户向我们反馈容易遇到闪退,但是我们自己的设备经过大量尝试却没有复现这个问题。这是最为头疼的,从用户的操作路径来看并无特殊的地方。无论是测试还是开发同学都无法在自己设备上面复现出来,无法复现的野指针问题非常难以定位。   

  

  线上监控技术   

大侦探福老师——幽灵崩溃谜踪案