Loading...
墨滴

斟茶兵

2021/12/11  阅读:52  主题:雁栖湖

破案混淆惨剧的全过程

Part1背景

周二晚上上线了新版本,在周三早上收到产品反馈,说用户在结算页点击提交订单支付不了,并附上了视频

看上面现象是在点击提交订单的时候崩溃了

Part2分析

既然是崩溃,那还不简单?去听云上看上报记录,不过有点蹊跷的是听云并没有上报该异常(这里怀疑听云出问题了,又人为去触发异常,发现是可以上报的)。

好吧,既然没有崩溃日志,那就只能发动脑筋猜了:1、机型适配问题;2、后台个别商品数据问题! 接下来就是尝试复现了,通过后台同事找到用户的 usercode,同时去神策上查用户的操作以及上报数据,查到用户的手机型号,然而我们并没有同型号的测试机 那就只好上云测去验证了,验证发现并不会出现异常,排除第一个猜测。 继续验证第二个猜想,找出用户下单的商品,用同样的商品及数量去下单,也正常,排除第二个猜测。 还好之前的版本解决奔溃后,新增了不少日志上报,接下来就只好看我们之前为了帮助定位问题上报的 log 事件'androidDev_log_Error', 'androidDev_log_Debug' ,结合这两个事件,加上上面的异常视频,基本确定崩溃是在接口请求之前就发生了。后续就反复的看代码,带着不信任的目光看每一行代码,大概能够确定是在点击提交订单的时候,我们为了埋点上报到神策,在进行数据组装的时候出现了异常。问题到这里进行不下去了,只知道这一块有问题,但又不知道哪里有问题。 很不幸的是到 10 点多以后,BD 通过产品又陆续反馈有用户加不了购物车,幸运的是云测有上报,而且是上报了同一个异常 有日志了就好办了 可以看到是这个类 PitLocationManager 现了异常,而这个类正是处理上报数据坑位的,结合混淆后的 mapping 文件定位到是在解析的时候出现了问题,目标类型是 int,但是碰到了一个""空字符,所以导致了异常

同时了解到新版本对 DetailStatParams 这个类的字段有改动,去掉了 string 类型的 recommendtag,加上了 int 类型的 recommend_product_type 字段

(这里不要纠结命名规范,因为这些字段是数据组定的)

可以确定的是就是因为这个改动导致了问题,但是为什么会出现这个问题还是一个很大的问号。因为即使有这个改动,原有的本地缓存有 recommendtag 字段也不会影响,新版去除这个字段就不会去解析,而 recommen_product_type 由于老缓存没有这个字段,解析出来也会是默认的 0,似乎也就不会出问题。 同时下午测试有台机器可以复现这个问题,但由于是 release 版本,看不到日志,所以安装了一个 debug 版本,因为覆盖安装并不会影响缓存数据,可是神奇的是,装上 debug 版本后异常又消失了。 现在问题找到了,可以解决,但又没解决。为了不影响用户使用,下午的时候出了一个新版本的包,开始给应用市场审核,但并没有给用户强更,同时观察神策和听云的数据。直到晚上,1.1.4 版本也没有任何异常,看神策数据也有用户通过 1.1.4 下单购买成功,但这也并不能说明什么,因为这个问题本来就是很少的用户会出现。问题也就只能这样了?

Part3复现

到周四的时候,去神策上查看 1.1.4 的上报数据,因为在这个版本我们新增了 log 来确认问题,其中有一条就是会上报用户的缓存,正好我们看到了几条异常的缓存数据 这几条数据有两个问题:

  1. 有实体被混淆了,正常来说实体不应该被混淆;
  2. 这两条数据的 f 值类型不一致,一个是 string,一个是 int; 第 2 个问题就佐证了听云上报的异常,现在我们来看第 1 个问题,既然是混淆了,那么我们就看 1.1.2 和 1.1.3 的 mapping 文件,这是一个混淆映射文件 1.1.2的映射文件 1.1.3的映射文件 我们可以看到, 在 1.1.2 版本 recommendtag 混淆成了 f,是 string 类型;在 1.1.3 版本 recommend_product_type 也被混淆成了 f,是 int 型。 所以 1.1.2 缓存的 recommendtag 会被解析成 recommend_product_type,由于类型不对,所以报错了。 既然我们知道是这个数据问题引起的,那么用户这些数据是怎么来的呢? 联想到只有少数的用户有这个问题,我们推测应该是我们发版当日用老版本操做引起的。在周二我们后台发了版,去掉了 recommendtag,而用户用 1.1.2 版本去加购了,那么缓存的 recommendtag 自然就变成了"",所以等到我们强推 1.1.3 的时候,再去操作就碰到了这条数据,引起了异常。 既然有了这个推测,那我们就很好复现了,先用 1.1.2app 加购,然后再用 1.1.3 版本加购,两个版本都加上混淆,果然问题出现了,看日志

跟听云以及神策上报的数据表现一致,至此整个问题就清楚了,同时也确认 1.1.4 版本这个问题解决。

Part4总结

整个排查过程其实是非常曲折,因为正常场景下是不会现,但是用户侧又有多个用户有这个问题。所以只能一步步推测,一步步验证来解决这个问题。 到周四 1.1.4 版本强推后,周五已经没有崩溃上报,这个问题总共影响 10 个用户。其实问题并不深奥,但找到问题的来龙去脉才是最关键往往也是最困难的,解决bug的过程就像是破案,一点一点的找线索,合理假设验证,最终找到那个真相并解决。

斟茶兵

2021/12/11  阅读:52  主题:雁栖湖

作者介绍

斟茶兵