V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
xnyu125
V2EX  ›  程序员

一次集文化差异、网络工程与诸多巧合于一身的 debug!

  •  5
     
  •   xnyu125 · 73 天前 · 3177 次点击
    这是一个创建于 73 天前的主题,其中的信息可能已经有所发展或是发生改变。

    分享一个异常精彩的关于有线网络喜欢红茶的故事,先上为敬:https://qualityfocus.club/fun-debug

    做软件做久了,很容易碰到各种匪夷所思的 bug ,你写过 /改过 /测过 /听过哪些有趣的 bug 呢?欢迎留言讨论。

    28 条回复    2022-05-27 17:17:57 +08:00
    HeyWeGo
        1
    HeyWeGo  
       73 天前
    最后车和冰激淋的例子可以提一下引用的原文,毕竟在你这篇网文内的文字占比还是很大的!
    ahhui
        2
    ahhui  
       73 天前
    很有趣的故事啊!
    Vaspike
        3
    Vaspike  
       73 天前
    有趣
    OutOfMemery
        4
    OutOfMemery  
       73 天前
    绝了!
    sadfQED2
        5
    sadfQED2  
       73 天前 via Android   ❤️ 6
    曾经排查过一个 MySQL 慢 SQL ,无论怎么都找不到原因,而且是偶尔出现,根据主键 id 查也会达到秒级别耗时。最终联合 dba ,sre,rd 组了个 20 多人的调查团队,研究了半个多月,最终发现是机房交换机怀了,交换机导致丢包,进而导致 MySQL 慢查询
    jhiiii
        6
    jhiiii  
       73 天前
    可以出圈的故事哇
    inu
        7
    inu  
       73 天前
    硬件的 bug 果然想到想不到 XD
    shaojz2005
        8
    shaojz2005  
       73 天前
    不错的博客
    tagtag
        9
    tagtag  
       73 天前
    其实挺奇葩的,正常人发现不明热源不应该马上排查防止火灾隐患吗,这怎么还直接利用上用来保温了。
    huangmingyou
        10
    huangmingyou  
       73 天前
    看过一个 bug,有个房间的服务器经常死机,但是当有人去房间呆着就不会死机。有人能猜到啥原因吗。
    boxz
        11
    boxz  
       73 天前
    @huangmingyou #10 房间太热了吗?
    hugo2lee
        12
    hugo2lee  
       73 天前
    @huangmingyou #10 莫不是模拟时代手模电视天线的电磁干扰
    Ycode
        13
    Ycode  
       73 天前
    优秀,至今还有一个 bug 没排查出来。在客户机 localhost 某个端口启动了一个服务,但是在本机用内嵌了 chromium 内核的套壳客户端怎么都访问不了,直接用浏览器就可以访问,百思不得其解。
    尝试过另外启动一个简单服务 √
    换回原来的服务:X
    换一个端口:X
    怀疑是 localhost 映射问题:
    - 切换到 127.0.0.1 X
    - 切换到本地 ip + 端口 X
    属实想不通了
    xnyu125
        14
    xnyu125  
    OP
       73 天前
    分享一个我经历过的 bug ,那还是一个原始的 ASP 页面,我把树状结构的某个父节点上的叶子挪到另一个父节点上,怎么挪都挪不过去,刚拽出来叶子就丢了,但开发每次挪都能挪过去。我们分析了半天,对比数据、机器、配置等等,后来发现是我拖拽的太快了,在操作快速的情况下叶子找不到新父节点就丢了,开发每次都慢慢挪(一个慢性子),所以从来没遇到过这个 bug~
    xnyu125
        15
    xnyu125  
    OP
       73 天前
    @HeyWeGo 感谢反馈,我找一下原 PO 添加引用。
    fretory
        16
    fretory  
       73 天前
    绝了
    abersheeran
        17
    abersheeran  
       73 天前
    一个字:绝。
    DesmondLeo
        18
    DesmondLeo  
       73 天前
    好家伙我觉得这可以拍一部微电影
    huangmingyou
        19
    huangmingyou  
       73 天前
    @boxz 对,有人去的时候就会开空调,不是专业机房
    zpf124
        20
    zpf124  
       73 天前
    @huangmingyou 是不是那个什么保洁大妈去把散热扇拔了充电的那个? 检查的人去的时候大妈看着有人就没进去拔。
    nieboqiang
        21
    nieboqiang  
       73 天前
    想起之前的一个老师遇到的 bug 。

    搞了一个仪器,在实验室里怎么搞怎么灵,但只要搬到厂里,就不行,数据总是不对。来来回回折腾了很久,最后发现是因为厂里接的是农业电网,电压不是稳定 220 ,可能低可能高。而实验室是最高等级的电网,永远是恒定的 220.
    darkengine
        22
    darkengine  
       73 天前
    之前调一个芯片,照着 datasheet 上电、设置寄存器都没问题,就是 I2C 的数据一直出不来。硬件老哥万用表一通量,供电全都是正常。后来硬件老大拿板子看走线,妈蛋芯片的 0.8V 供电根本没连到任何地方。。。硬件老哥量的时候不知道哪里漏过来的又能测出来有个 0.8V
    Chihaya0824
        23
    Chihaya0824  
       73 天前
    太强了
    xnyu125
        24
    xnyu125  
    OP
       73 天前
    讨论很热烈啊,再赠送两个小故事,是我公众号的留言回复,当时看到也是惊了,“事出反常必有妖”系列。

    故事 1:听过一个邮件服务器的故事,这个公司的邮箱经常发不出去邮件,也不是都发不出去,有时候也能发出去
    后来统计了发出去的邮件,发现接收服务器都在 300 公里范围内。追查结果是,邮箱发送超时的设置,应该 1 秒,工程师随手写了 1 ,但是默认单位是毫秒,1 毫秒电信号只能传播 300 公里。

    故事 2:​还听过某医院的故事,每天早上七点到七点半之间,重症监护病房,最门口那个床的病人特别容易死亡,就这个点,就这个病床,谁住这个床谁倒霉,别的时间别的病人都没事。医生怀疑门口漏风,怀疑气温变化,查了很久。后来发现,早上七点,清洁工进来打扫卫生,把门口的电源拔了,插吸尘器。
    Arnie97
        25
    Arnie97  
       72 天前 via Android
    楼上邮件服务器的故事原文: https://www.ibiblio.org/harris/500milemail.html

    医院的也太地狱笑话了
    luozic
        26
    luozic  
       72 天前
    听到的一个 bug:用户反映每次用笔记本播放李娜的青藏高原时,电脑就会死机。经测试发现,唱到最后的“那就是青藏高...”时,硬盘产生了共振,振幅过大,读写头读不出数据了。
    luozic
        27
    luozic  
       72 天前
    @luozic 这个是在搜狐上看到的。
    xnyu125
        28
    xnyu125  
    OP
       72 天前
    亲们,我想把这个帖子改造成“匪夷所思的奇怪 bug 合集”~ 大家没事可以来翻翻这些诡异的 bug ,为 coding 时光添加一些乐趣~~~

    ————————————————————————————

    原文 link: https://www.quora.com/Programming-Interviews/Whats-the-hardest-bug-youve-debugged/answer/Dave-Baggett

    翻译转自知乎: https://www.zhihu.com/question/22108128

    补充故事:

    “这是我全部编程生涯中,唯一一次因为量子力学 debug 的问题”这篇文章中,怎么体现了量子力学?
    回想起这个 bug ,仍然让我有些痛苦。作为一个程序员,在发现 bug 时,你学会了首先在自己代码中找问题,或许在测试一万次之后,你会把问题归咎于编译器。只有在这所有的都不起作用之后,你才会把问题归咎于硬件。

    这是我遭遇一个硬件 bug 的故事。

    抛开别的不说,我曾为《 Crash Bandicoot 》写存储卡(读写)代码。对于一个自大的游戏程序员,这就像是在公园里散步一样轻松愉快,我认为只要几天就写完了。我中止调试六个礼拜。在此期间我做一些其他的事情,但我一直回来处理这个 bug——几天内每天几个小时。这个 bug 实在烦人。

    这个 bug 的症状是,当你需要保存你的进度时,代码会访问存储卡,而大部分情况下没有什么问题…但是偶尔读写会超时…没有任何明显的原因。一个短小的写入经常毁掉存储卡。玩家要保存进度,我们不仅不保存,还擦除他们存储卡上的全部东西。天哪。

    过了一段时间,我们在 Sony 的制作人 Connie Booth 慌了。我们显然不能带着这个 bug 发布游戏,而六个星期之后我对于问题出在哪一点线索都没有。通过 Connie 我们向其他 PS1 开发者求助:有没有人出现过像我们这样的情况?没有。绝对没有任何人在存储卡系统上出现任何问题。

    在你绞尽脑汁之后,你能做的唯一一个调试方法就是分而治之:一点点去除程序中的代码,直到留下的代码很少但你仍然出问题。像木雕一样去除没有问题的代码,留下的就是你的 bug 所在。

    在这样的背景下挑战在于,视频游戏是很难去除某一部分的。在你删除模拟重力或者显示字符的代码后,如何运行游戏?

    你必须做的是用一个假装做真正的事情,但实际上只是做很简单的不会出现 bug 事情的东西来替换掉整个模块。你必须写新的支撑代码来让这些玩意正常工作。这是一个缓慢而痛苦的过程。

    长话短说:我做完了。我移除了大片大片的代码,相当多,只留下了初始化代码——就是准备游戏运行系统,初始化底层硬件等等。当然,我不能显示加载 /保存菜单,因为我截除了所有的图像代码。但是我能够假装用户使用(不可见的)加载 /保存屏幕并且请求保存,然后写入卡中。

    我最终以一个带有这个 bug 的很少量的代码结束——但问题仍然随机出现!在大多数情况下没啥问题,但是偶尔会失效。基本上所有的 Crash 的实际代码都被移除了,但还是这样。这实在是莫名其妙:留下来的代码基本上都没做什么事。

    在那时——估计是凌晨 3 点——一个想法蹦了出来。读写( I/O )涉及精确定时。无论是硬盘、存储卡、蓝牙发送器——随便啥——做读写的底层代码都是根据时钟来的。

    时钟让不直接连接到 CPU 的硬件设备和 cpu 运行的代码同步。时钟决定了波特率——数据从一头传到另一头的速率。如果计时有什么问题,硬件或者软件或者两者都会乱七八糟的。这真的,真的很糟糕,并且通常导致数据损坏。

    如果我们的初始化代码以某种方式弄乱了计时会怎么样?我又看了一遍测试程序中和计时有关的代码,并注意到我们将 PS1 上的可编程计时器设置到了 1kHz ( 1000 跳每秒)。这是比较快了,当 PS1 启动的时候,默认状态大概是 100Hz 。因此,大多数游戏将他们的计时器设置为 100Hz 。

    这个游戏的带头(和除我外的唯一)开发者 Andy ,将计时器设置为 1kHz ,使得 Crash 的动作计算更加准确。Andy 喜欢矫枉过正,如果我们要模拟重力,我们应该尽可能的提高精度!

    然而如果提高计时器频率莫名其妙的干扰了整个程序的计时,故而将这个计时器设置到存储卡的波特率上会怎样呢?

    我将计时器代码注释掉。然后我就无法复原这个 bug 了。但是这并不表示 bug 被修复了,这个问题是随机发生的。万一我只是运气好呢?

    几天过去了,我还是在玩我的测试程序。Bug 没有再出现。我回到全部的 Crash 代码中,修改了加载 /保存代码,在访问存储卡之前将可编程计时器重置为默认设置( 100Hz ),之后设置回 1kHz 。从此之后没有发现问题再次出现。

    但是…为什么?

    我重新回到测试程序上,试着检测当计时器设置为 1kHz 时出现的那些错误的模式。终于,我注意到这些错误出现在使用 PS1 手柄的人身上。因为我自己很少这样做,所以我没有注意到(为啥我要在测试加载 /保存代码的时候用手柄)。但是有一天我们的美工等我去完成测试(我确定那时候我在爆粗口),而他紧张的摆弄着手柄。卡损坏了。“等下,怎么回事?喂,再来一次!”

    一旦我发现了这两件事是联系着的,就很容易重现 bug:开始写入存储卡,动一下手柄,存储卡损坏。在我看来完全是硬件 bug 。

    我去找 Connie 告诉他我的发现。她转述给设计过 PS1 的硬件工程师。她被告知:“不可能,这不可能是硬件问题。”我跟她说问一下我能不能直接和他说。

    那个工程师给我打电话了,他用着他的烂英语,我用着我更烂的日语,我们争论一会。我最后说:“我给你一个 30 行的测试程序,让你在动手柄的时候能够出现这问题。”他答应了。他向我保证,这是浪费时间,而他正在一个新项目上很忙,但因为我们是 Sony 很重要的开发者,他会试的。

    第二天晚上(我们在洛杉矶,而他在东京,所以对于我来说是晚上而他是到了第二天),他给我打电话,不好意思的向我道歉。这是个硬件问题。

    我还是没有完全搞清楚问题到底在哪,但是我的印象中,从 Sony 总部的反馈听到的是,如果将可编程计时器设置到足够高的时钟频率,会影响到主板上时钟晶振附近的一些东西。这些东西之一就是存储卡的波特率控制器,同时也设置手柄的波特率。我不是搞硬件的,所以对于细节我相当模糊。

    但是主旨是主板上两个独立部分的串扰,以及手柄接口和存储卡接口数据发送的结合在 1kHz 的时钟频率下会导致丢位,从而数据丢失,以致卡损坏。

    这是我全部编程生涯中,唯一一次因为量子力学 debug 的问题。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1181 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 23:18 · PVG 07:18 · LAX 16:18 · JFK 19:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.