一次活见鬼的调试经历

本篇文章没有什么干货,仅是我的一次调试经历。

昨天在调试FIDO项目,运行时发现某个变量的值和我设置的不对。调试进去,几番折腾,吓呆了我:

img1
img2

仅仅经过一个赋值,就把赋值和被赋值的变量都改变了?我的所有知识都无法解释这个问题。

没办法,现实摆在眼前。只能通过一系列的实验排除问题。

  1. 我怀疑是外部变量的问题。于是我传入常量,问题依然存在。

  2. 我在赋值前进行clone(),入参不再改变。根据1和2,我觉得应该是该对象的变量出的问题。

  3. 我不再进行入参的赋值,而是在构造器直接赋值this.attestationType = new short[1]; this.attestationType[0] = 1;。结果:第一句赋值成功,第二句没有效果。

  4. 我不再在构造函数中赋值,而是另开一个方法单独赋值。问题依然存在。
    img3

  5. 我开始怀疑是不是注解的问题。@TagMember是一个RUNTIME注解,功能类似GSON,用于进行对象和特定数据格式(TLV)之间的转换。我把注解注释掉,问题不再复现!
    img4

  6. 我怀疑是注解里面的变量有问题。于是我把supportedExtensionIDs的注解复制到attestationType上。问题依然不再复现。

  7. 这就奇怪了,为什么注解里的值会影响变量本身呢?这和注解的原理和功能并不一致。为了防止“改动完又改回去,突然就可以了”这样的怪圈,我回归了一下原代码,问题重新出现。
    img5

  8. 接下来更奇怪的事情出现了。我把supportedExtensionIDs的值从null改回到{"1", "2"},问题不再出现!这个问题我在步骤1就已经测试过了,这是真的出现了“改动完又改回去,突然就可以了”的致命事件。。我被打懵了。。
    img6

  9. 我再改回null,问题又回来了。
    img7

  10. 我试着精简我的问题模型。我把其他变量都删掉了,只留下attestationType。问题依然存在。

  11. 继续关注刚刚注释注解的线索。我的其他变量都有注解,却偏偏只有这个变量出现了问题。由于步骤7的现象,我把attestationTypesupportedExtensionIDs的位置交换,并把注解的值也交换了。问题依然存在。

  12. 我把attestationType的类型修改为byte[]和int[]。赋值问题不再出现!于是我现在得到的结论是:被注解的short[]类型会出现赋值问题

  13. 为什么偏偏是short[]类型呢?我想的有点偏,我认为是注解的short tag()这个方法导致的问题。但修改TagMember这个tag又会影响太多代码,于是我拷贝了@TagMember类,并定义为@TagMember2。将attestationType的注解改为@TagMember2,并改为int tag()。问题消失了。我自豪的猜想:难道我遇到了JAVA编译器的问题?

  14. 就都麻袋,还不能太早下结论。我把@TagMember2改回short tag()。现在两个注解除了类名都一样了。运行,没有赋值问题。意思就是:和short tag()没有关系。

  15. 一样的注解,但是却不一样的结果?只有@TagMember才会出现问题,@TagMember2没有问题,但他们明明是一样的。@TagMember到底有什么特别之处呢?

  16. 哦,我想起来了。我在父类里面会对其进行反射调用,取值构造新数据结构(步骤4有提到)。而这个方法会通过toString()执行。

  17. caocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocaocao!!!!!!!!!!!一下子都想通了。

  18. 验证一下,我把父类的继承去掉,让该类继承Object。赋值问题消失。

  19. 我检查了一下toString()中我对short[]类型的处理,发现我在赋值的时候仅做了浅拷贝(也就是直接赋值),然后做了修改值的操作。而在debug过程中每一个单步调试IDE都会调用对象的toString()方法,而toString()方法会修改short[]类型的变量,所以出现了一开始的赋值问题。

  20. 关于步骤7里面的线索(supportedExtensionIDs会影响attestationType的赋值成功):是因为我的toString()方法里没有对String[]类型的处理分支。而在null的时候,我的处理会忽略这个变量,则流程继续走下去,把short[]的处理分支执行了。而在非null的时候,因为toString()无法处理,会直接报错,则没有走到处理short[]的分支。所以supportedExtensionIDs在非null的时候,attestationType的赋值不受影响。

  21. 关于步骤7和步骤1的同样环境不同结果的问题:最后我无法复现步骤1的情况,恐怕是调试期间我不小心改了哪里吧。。我认为不会是很值得研究的原因,解决了主要疑惑和次要疑惑,有时候该放手就放手吧。

  22. 我在整理文章的时候想通了步骤21的疑惑。是断点位置的问题。在后面的调试中,我把断点设在了构造函数末尾,则supportedExtensionIDs的值会影响到attestationType(因为在那个时候IDE才开始调用toString())。而如果是一步一步调试,则supportedExtensionIDs被赋值前attestationType已经被修改了。

  23. 步骤6的问题,是因为我刚好把步骤22所说的断电给移动了,导致了这个现象,其实和值并没有关系。

所以整个“活见鬼”的原因是这样的:

  1. 该类的父类重写了toString,toString里面会反射调用各个成员的值,组成一个新的数据格式。
  2. toString()中我对short[]类型的处理有问题,我没考虑浅拷贝的问题,在里面做一个修改值的行为,把原变量修改了。导致变量本身的值出现的变化。
  3. 在debug的每一次都会调用该变量的toString(),所以值在点击下一步的时候,就会被改变。
  4. 该问题一开始暴露在运行时,是因为运行时后面代码也有调toString(),所以造成了假象。如果我只是用打印的方法查询该变量值而不是debug,在运行时的构造函数中该值不会被改变。
  5. 所以表面看起来只是单步调试了一个赋值语句,而值就被变化了。深层结果是调试器调用了toString()导致的修改值行为。

本次经历给我的经验是:

  1. 对数组的赋值和操作,尤其是在构造函数时,应当进行拷贝而不是直接引用(数组直接clone()就可以了)。之前没因为浅拷贝遇到问题,所以一直没有在意。
  2. 一些莫名其妙的表象其实背后可能是清晰可推理的故障多米诺。我们要做的是,先找出复现和修复规律,然后慢慢精简问题模型,再通过控制变量法找到问题所在。而不是困与一时无法解释花哨表象,无法前进。其实想通之后,原来乱七八糟的bug现象都可以解释了。
  3. debug阶段可能会因为toString()方法影响真实运行时结果。

版权所有,转载请注明出处:
http://sickworm.com/?p=184

2 thoughts on “一次活见鬼的调试经历

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据