Bug 千千万，文中提到的 bug，你遇见过吗？
原文链接：https://engineering.gusto.com/the-weirdest-bug-ive-seen-yet/
未经允许，禁止转载！
作者 | Amy Lai 译者 | 弯月
责编 | 夏萌
出品 | CSDN（ID：CSDNnews）
问题介绍
最近，我们收到了一份报告，说用户在使用内部软件时Chrome突然崩溃了。这导致我们正常的客户服务受到了各种干扰，他们在回复客户的电子邮件或与客户通话期间，突然就看不到工作所必需的客户账户信息了。
图：Chrome窗口崩溃
本来这并不属于我们的工作范围，通常浏览器兼容性之类的问题由其他团队负责，所以我对调试浏览器一窍不通。我应该从哪里着手呢？于是，我求助于一位经验更丰富的队友，我们的产品基础设施团队以及IT团队。
第一条线索
我们首先尝试找出受影响的用户有哪些共同点。
我们很快了解到：
-
并非所有员工都受到了影响。
-
面向客户的软件似乎没有受到影响。
-
其他内部软件页面似乎都很正常。
-
这个页面并不是每次都会崩溃。遇到此问题后，用户反复尝试重新加载该页面，有时会崩溃，而有时则不会。
-
并非所有的内部页面都会崩溃，但其中有多个页面崩溃，包括访问最多的页面。
-
在Safari或Firefox中未发生此问题。
猜测一：Chrome的版本问题
我们最初猜测可能是Chrome的版本问题。于是，我们让其中一个受影响的用户升级他们的Chrome版本，初步迹象看起来问题有希望得到解决。然而，我们很快了解到，尽管安装新的Chrome版本后，页面的崩溃频率降低了，但问题并没有得到根除。
此次尝试，我们获得了以下新线索：
-
特定Chrome版本的发布已经有一段时间了。
-
受影响的用户使用了不同版本的Chrome。
-
使用相同版本的Chrome版本，有的用户受到了影响，而有些则未受影响。
-
升级/降级受影响用户的Chrome版本无法解决问题。
猜测二：Chrome扩展问题
也许是Chrome扩展的问题？我们尝试让其中一个用户禁用了三个核心扩展，崩溃就停止了，于是我们以为问题得到了解决。然而，当我们尝试使用访客配置文件（没有扩展）重现修复操作时，仍然看到了崩溃。我们又回到了起点。
难以重现的bug
我们的基础设施团队向所有工程人员发送了一条消息，询问是否有人能够重现这个问题。令人沮丧的是，尽管我们的许多客户服务代表都受到了影响，但除了两名土耳其的工程师外，所有工程团队都没有报告任何崩溃。经过几周的努力，我们逐渐了解到以下情况：
-
出于安全原因，我们未启用Chrome崩溃报告。
-
从几周前的代码库中检出代码并没有解决问题，这表明该问题不是由于最近的代码变更引起的。
-
加载页面的静态HTML版本并不会引发崩溃。
-
使用开源的Chromium代替Chrome不会引发崩溃，因此我们无法得知哪一段Chrome代码出现了问题。
-
引起Chrome崩溃的不仅仅是一个内部应用，还有好几个。
-
删除页面的特定内容并没有解决问题。
-
禁用内部字体并没有解决问题。
为了回避这个问题，我们的用户开始使用其他浏览器，因此这个问题的紧迫性也有所缓解。由于还有其他重要的工作，因此这个bug的调查进度缓慢。在无法重现Bug的情况下，我们没有太多的线索。然而，我们希望解决这个问题，因为用户在Chrome中设置了书签/设置/首选项。我们认为，我们不应该要求用户避免使用这款流行的浏览器，并且我们仍然会定期收到来自各种用户的询问，问我们这个Bug的调查是否有了进展。
好运降临
有一天，一名工程师突然报告说她也受到了影响。她唯一的改变是下载了Grammarly桌面应用程序。
等等，真的吗？我们必须试试看能否重现这个bug。
-
下载Grammarly桌面应用程序。问题立即重现了！
-
删除Grammarly。问题没有消失。重启电脑，问题又消失了。
-
重新安装Grammarly。Chrome又开始崩溃了。
我们与许多受影响的用户确认，他们也在计算机上安装了Grammarly。于是，我们有了突破口！
进展
由于调试能力得到了极大改善，所以我们进行了一些尝试：反复修改代码，然后重新加载页面，直到页面崩溃。
我们的主内部应用构建于ActiveAdmin之上，但新的一部分使用了React。用React构建的页面没有崩溃。这么说是我们的ActiveAdmin代码引发了崩溃？
早些时候，我们了解到删除页面上的特定内容无法解决问题，因此我们开始查看多个页面共同的代码，比如主导航栏和侧边栏。值得注意的是，我们的React页面使用了不同的导航栏。
我们的主导航栏代码涉及很多元编程，追踪这些线索常常会让人更加困惑。最终，我们弄清楚了如何注释掉导航栏的一部分，直到最后我们找到了一行代码，注释掉该行代码Chrome就不会再崩溃：
这个小节叫做“My History”，它不同于主导航的其余部分，所有用户看到的内容不一定相同，它是针对每个用户定制的，显示的是每个用户最近访问的几个页面。我们发现即使页面成功加载，将鼠标悬停在“My History”上也会导致Chrome立即崩溃。
接近真相
猜测三：Turbo
我们的目光停留在了turbo: true。这可能是导致问题的原因吗？Turbo是一个gem，是我们为了提高Rails应用程序的速度而添加进来的，但事实证明这并非问题所在：Turbo是在Bug报告之后才引入的，我们了解到引入Turbo的工程师在这之前的几个月就遇到过Chrome崩溃的问题，甚至在问题报告给我们之前几个月。
那么dropdown的定义在哪里呢？我们使用一款名为Arbre的框架从这种类型的方法中元编程HTML。为了浏览内部结构，我向中一位对Rails有深刻了解的工程师寻求帮助。最后获得的相关代码如下：
这段代码生成的HTML如下：
我们用生成的HTML替换dropdown的调用，然后逐步删除这些HTML，直到最后我们锁定了罪魁祸首。
真相大白
当我删除loader-spinner.gif（菜单选项加载时显示的占位符）之后，页面停止崩溃。真相揭晓！就是这个gif！我们替换成了另一个gif，页面没有崩溃。
我们下载了这个图片文件，将其拖入浏览器窗口。伴随着莎士比亚式的戏剧化，页面当即崩溃了。我和同伴都倒吸了一口气。
我们还发现：
-
在Safari中打开该文件不会导致崩溃。
-
卸载Grammarly并重启计算机后，在Chrome中加载该文件不会崩溃。
于是，我们通知了设计系统团队这个非常奇怪的现象，这个导致Chrome崩溃的gif，他们迅速换了一个新的文件。
为什么在安装了Grammarly的情况下，这个特定的gif会导致Chrome崩溃？不幸的是，由于无法访问Chrome和Grammarly的源代码，所以我们只能猜测。在我们替换了这个gif之后，Grammarly或Chrome（或二者共同）都解决了这个问题，因为原来的gif也不会再导致Chrome崩溃了。
结束语
我永远都想不到调试的尽头有一个gif在等着我。
尽管我们找到了解决方法，但在这期间内，这个bug的优先级也发生了变化，但最终我们的好奇心战胜了一切。虽然无法靠个人的力量独自解决这个bug，但我们通过坚持不懈的努力和共同协作，最终解决了这个问题。
本文文字及图片出自 CSDN
你的反应是：