物业管理实务案例分析_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
文档贡献者
评价文档：
&&¥4.00
喜欢此文档的还喜欢
物业管理实务案例分析
把文档贴到Blog、BBS或个人站等：
普通尺寸(450*500pix)
较大尺寸(630*500pix)
大小：628.00KB
登录百度文库，专享文档复制特权，财富值每天免费拿！
你可能喜欢最难调试修复的 bug 是怎样的？
由Quora上的同名问题引过来
按投票排序
133 个回答
放眼望去怎么基本都是纯软件的bug。。。。。。。。广大的硬件工程师固件工程师驱动工程师在哪里？来吧，我来分享一下硬件相关的bug吧（线路设计，固件，驱动，etc）。在以前的回答中，我曾经零零碎碎写过一些，这里先搬一点儿过来。如这个答案（）里的我的回答。本答案会继续更新，有空就来写点儿：==============更新============================(搬过来的答案，懒得重新整理了）
不严谨的USB驱动撰写者：一个英国的驱动高手（56岁的老头），有一次客户报bug说在一家医院里他们的一个USB设备就是没法在新一代电脑上用，而且是时好时坏，没有规律可言。客户派了硬件软件BIOS几个工程师过去解都没解出来。我请到这位高手出马，高手拿到USB设备和电脑后，花了一天的时间做初步验证，然后花了一个晚上写了个小程序模拟那个USB设备的驱动的挂起/卸载，然后花了2小时运行那个程序，发现USB设备的驱动在挂起/卸载很多次以后Windows就会有一定的几率拒绝挂载这个设备，然后他在和微软以及那个设备的厂商联系，花了一天时间确定USB设备的驱动里的一个bug，第三天，USB设备的厂商出了一个测试驱动，问题完美解决。粗心的硬件工程师某台式机机型，出厂后大约一年后，开始出现大批量的返厂。返厂的现象惊人一致：主板挂了无法开机，挂掉的是主板上的芯片组。 由于该机型芯片组损坏率远高于其他机型，我们一开始怀疑是客户使用不当（因为最早返回的都是某一特定大客户的在某国工厂退回来的机器），但随着时间的推移，全世界各地都有返厂的现象。于是目标转向怀疑该主板设计有问题。但是，妖异的来了，从工厂抽调数百台该机型进行压力测试（没日没夜跑高压程序，进烤箱，各种设备插拔），就是没有一台机器挂掉。前前后后折腾了一个月，大家都丧气了。最后，好不容易，从客户手中拿到一些坏掉的机器，我们把芯片组拆下，重新植球，检测后发现是芯片里有一部分电路已经损坏，多块芯片组损坏的地方完全一致。最后，我们去检查该主板的设计，发现芯片组的某个输入电源，应该使用1.5V，却使用了3.3V电压。由于芯片组本身质量不错，尽管设计需要1.5V但是在3.3V下仍旧可以忍辱负重工作很久才烧掉，所以这也就解释了为什么我们无论怎么压力测试都测不出来，要等机器在客户手里使用一年左右才会烧掉。 最后，全球召回更换主板，问题解决。奇异的环境某台式机墨西哥工厂生产线，操作系统有时会无法download（这边普及一下知识，生产线上的操作系统不是安装的，都是通过网络直接把image下载到硬盘）。该问题在其他国家的产线上完全无法复制。经过多个工厂严格的对比检验（工程师飞来飞去好几个星期），发现唯一的区别是墨西哥工厂生产线上的网络环境使用的是hub（有点穷），而其他工厂使用的是switch（别的富裕一点）。进一步debug发现，台式机自带的网卡的驱动，在用hub的环境下会丢包导致image download失败，而在switch环境下就不会。通过网卡厂商驱动程序工程师debug之后，更新了驱动，问题解决。==================更新===================躺着都中枪某机型，量产后稳定发售大半年，一切OK，用户反映良好，销售订单不断，大家都很开心。不料，从某个月起，返厂的数量逐渐增加，故障完全相同：主板上供电模块烧毁。由于该供电模块应用在非常多的机型中，只有这一个机型有大量返厂，于是怀疑供应商的供货质量管控不佳，某一批次产品质量有问题。供应商被challenge的狗血淋头，使用各种手段验证，得出结论是产品质量控制没问题。我们当然不信，继续challenge供应商，逼得大家鸡飞狗跳。后来，随着时间推移，返厂的机器越来越多，损坏的供电模块广泛散布于各个批次之间，这下供应商抬起头来：总不见得我每批货都有问题吧！好，只能继续debug，供应商对模块进行检测后，告知损坏的原因是长期超负荷运行导致，基本上超负荷连续运行超过3个月，模块就会损坏。我们很奇怪，电路设计各方面都符合标准，为啥模块会超负荷运行？于是，开始各方面排查，经过两个月的仔细研究，把每台返厂的机器的所有config都拉出来做对比，终于得出一个共同点：所有损坏的机器，都是从某年某月某日开始使用了某个新的显卡驱动之后才发生的。神了，显卡驱动能烧毁供电模块？这时候，工藤新一开始附体：如果排除所有可能，剩下最后一个可能，即使它是多么的不可思议，也一定就是真相！ 好吧，继续研究，发现这一版的显卡驱动，在调配显卡功耗的时候，会在供电模块的输出电路上产生一个尖峰（电压高达额定电压的十倍以上），尽管这个尖峰时间很短（以微秒计），但由于驱动会不断的调整功耗，导致这个尖峰会极其频繁的出现。所以，如果电脑是24小时开机并一直在运行高压程序的话，这个尖峰的持续出现会导致供电模块的损坏。后来，修正显卡驱动，问题解决。供电模块的供应商感慨道：这真是躺着都中枪啊！====解释的分割线======有人提到没事不要更新驱动，其实这个有点草木皆兵的味道了。该更新的时候还是要更新的，毕竟新的驱动很多时候是解了不少bug以及提升不少性能的。这个bug当时存在的原因是该显卡第一次内置动态功耗调整，所以驱动开发人员经验不足。后续的产品在驱动开发的时候都会配合硬件工程师一起做测试来保证不出现类似的bug。 ========更新=====================不差钱的土豪也有倒霉的时候某机型，量产后稳定发售半年有余，忽然从某个月开始，产线上不良率骤然提升，具体表现在某个出厂测试无法通过，不良品广泛散布于各条生产线各种配置上，毫无规律可言。工厂端仔细检查后确认近期没有引入任何新的物料，也没有更改任何生产步骤，产线上的工人也没有任何变动，于是将问题上报。研发人员介入后发现，似乎问题是跟着PCB板走的，因为在不良品上即使更换处理器芯片组，不良品依旧是不良品，而当你把不良品上的处理器芯片组换到良好的产品上，测试就通过了。于是，矛头指向PCB制造厂，怀疑他们品控不良。PCB厂经过两周的排查，确定他们出厂的PCB品控良好，并且他们对不良PCB做过检验，各项指标都在标准范围之内。这下研发人员抓瞎了，问题被推送到我这里。不巧的是，正好没几天就农历新年了，我只好要求工厂把不良品寄给我，我再寄给美国总部的工程师帮助debug（老美不过新年也有好处啊）。随后，工厂停产过年，等待年后复产。大家开开心心过年回来后，老美的报告出来了，经过不良品和良品的检验，发现不良品上处理器的某个控制电压超出范围，导致处理器工作不正常。研发人员进一步检查后发现，原来在那个控制电压上，研发过程中曾经为了debug的需要，串联了一颗 0 欧姆的电阻，而那个电压就是在通过了 0 欧姆的电阻后，压降超出范围导致的问题。随后，经过对不良品上的 0 欧姆电阻检测发现，该0 欧姆电阻的阻值远超spec，原来是电阻厂品控不良啊！ 研发通报了该事故给采购，采购立即将该电阻厂除名，问题解决。解释一下，开发过程中，电路上经常会预留一些0 欧姆的电阻，可以作为监测点来debug。通常来说，量产后，这些0欧姆的电阻都应该去除，改为直连，以节省成本。有趣的是，当初该客户正好处于不差钱的状态，又十分保守，决定在研发结束到量产的过程中，所有电路一条线都不能改，于是这些用于debug的0 欧姆电阻依旧被保留着，直到该问题被发现。========更新=====================强势的事实垄断者前面写了很多量产后的bug，这里写一个还未量产的bug吧，其实这个bug的核心不在于技术问题，而是钱的问题。某机型，研发过程中的小批量生产的时候一切正常，研发进行的异常顺利。大家都很开心，准备等8月份宣布量产后开香槟庆祝。6月下旬，按研发流程，工厂开始了量产前最后一批大规模试产，同时对产线进行最后的调试。6月底，工厂开始报问题，这批试产的机型大约会出现千分之三左右的花屏现象，现象完全随机出现，经过数次排查，无法确认花屏出现的规律。咣当！大家都懵了！没有规律的bug是最头疼的，何况现在接近产品发布日期，如果在发布之前无法解决，产品上市就会延期，大家都死啦死啦滴。得，工程师全部驻厂，没日没夜debug，硬件软件固件工程师就在产线上趴着，逮到一台花屏机就开始debug。幸运的是，在产品发布会延期的巨大压力下，工程师被逼出了无穷潜能，居然最后debug出来了。原因很简单：屏幕控制芯片的一个时序不符合规范，有个信号理论上延时不得大于30ms，实测值什么样的都有，最大的能跑到300ms，翻了10倍。大家长出一口气：行了，替死鬼找到了，有人担纲了。万万没想到的是，当工程师找到屏幕控制芯片的厂商的时候，他们一脸轻松：我知道啊，这个时序我的确没符合规范！工程师当场跳起来了：靠我去年买了个表，你知道你怎么不早说！有毛病的片子你敢出厂！看我不告死你！厂商一脸傲娇：没办法，这个时序如果要控制在规范内，我自己没法量产，因为良率不达标！大家大怒：TMD良率不达标关我屁事，你的片子卖给我你就得达标！不达标我就告你！厂商说：你丫懂不懂，这个规范不知道那个脑子进水的人定的，你要我时序符合规范，可以，良率降4成，我的价格要翻倍！你出双倍价格我就给你达标的片子！ 七嘴八舌吵了一个多小时，大家一拍桌子不欢而散。工程师回来找到采购：TMD采购你怎么搞得，这种厂商你也放进来！采购一脸无辜：你知道么？！这是目前市面上唯一能提供你需要参数的厂商！只此一家，别无分店！你要我换厂商，可以，你把你的参数改了！ 工程师说：靠难道赚钱的活没人干？这片子又不是什么高精尖造火箭！采购说：别的厂商有，但人家要年底才能出货，你能忍？工程师没办法，回去找大老板：老大，这活没法干了！老大了解了来龙去脉，嘿嘿一笑：能用钱解决的问题就不是问题。采购，你去把第二家厂商拖进来，让他们年底开始供货，然后去跟第一家谈，我出双倍价，让他们供货，等到了年底第二家上来了我们再去治治第一家。工程师，你现在就去跟第二家开始合作，测试他们的片子，确保年底能供上。最后问题解决了，靠的不是技术，是砸钱，砸钱，砸钱。。。。。。。。。=========待续-===================
手机版app好像没法设置引用，不过 whatever这是Dave Baggett发表在Quora上一篇The hardest bug you've ever debugged，读起来让人十分惊叹。（如果是我的话，在代码中找不到可能就直接放弃了。。。）回想起这个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的问题。Retrieve fromBaggett, D.
多线程环境下高压力导致的并发bug。难在重现上，本身也就个把月出现一次，调试模式下完全不会出现。
在我的桌面上躺着一个文件，它不用面朝大海春暖花开，也会引起我无限的悲痛。在我的桌面上躺着一个文件，它不用面朝大海春暖花开，也会引起我无限的悲痛。_______________没有长答就不符合知乎的气质了————————先上图节选里面一部分内容记载在册的bug都是非逻辑错误引起的具有严重影响的bug（请无视第一个bug，它是拿来开题的）。但是题主问的是最难调试修复的bug， 那必须就是第2个！这个bug历时3个月时隐时现，就像鬼魅一样，一来就直接死机躺在那里。复现它至少需要2个小时高频率的发送才能重现。而且出现时必须立刻抓住否则连临终遗言都看不到了。（编译器坑爹的临终遗言法）这就算难了吗？重点是它写的遗言（指向问题的代码）根本就没重复过好吗！开始debug的时候我们用临终遗言法，发现指向了一段问题代码，把这一大段代码直接屏蔽了，居然能换一凶手一指，又死了！！！！现象就是掉入硬件中断，但是并不像普通的硬件故障，因为一旦重启过了它又开始了下一轮跑的很欢跑着跑着又死机了。题主你看到了吗？这种bug符合你最难调试的口味吗？你感受到我内心深处的对它深深的恐惧了吗？于是我开始了艰难的排错过程，从虚焊，芯片过热到内存溢出，空指针...答主我要平复一下心情去吃饭了，过一段时间再把艰难的排错过程写上来。——————————我是过了一段时间的分割线—————————嗯……关于调试，开始是从软件着手的。因为以前也并没有出现这种现象，所以没有前车之鉴。只有自己发挥神经病人思路广的优势慢慢找。经过一番观察，我们得出的结论是：只有进行频繁通信2小时以后才会出现这个bug，其它模块并不会导致该现象的发生。所以答主开始查看通信模块的代码部分。因为通信模块的主要组成是对一段用指针写的双链表（父链表的内容指向子链表）进行操作，申请内存释放内存的过程有很大概率出现内存泄露。一番查找，果然，链表里面有bug！赋值的时候没有做异常处理，有概率出现申请的内存不够用。修改了以后，开始测试。2个小时过去了，还没有出现以前那种死机的现象，于是答主就休息去了，让测试程序跑一晚上过过瘾。就在第2天早上，答主一起床就直奔测试机，结果还是死机了，此时的心情你们随意感受一下。痛定思痛，答主再测一了次，果不其然在4小时后死机了（这是不负所望吗？）。编译器在死前指向一段看起来很无辜的代码。在多次的测试之后，得出了的结论是：现象完全相同，只是在发作时间由2小时左右改成了4-6个小时（复现时间增加了1倍多，不知是喜是忧）。这时答主按照正常人的逻辑猜测，可能是另一个内存泄露导致了bug没有修复干净。再找！与此同时，答主的硬件小伙伴们也在检查板子的虚焊或者元件质量不合格的可能性。（在此感谢一下2个小伙伴，他们在被答主当成制造bug的嫌疑犯时没有隔岸观火，而是帮答主出谋划策，还顺带照顾答主三餐饮食保证答主没有饿死在测试现场，嗯，他们好像不混知乎，就不点名了）在检查了元件的可靠性和焊接以后，答主的小伙伴们拿出了3个认为不存在问题的板子开始同时跑这一段程序。因为是通信bug所以还顺道检查了通信模块也没有任何发现。———————我是答案很快就会浮出水面的分割线————————在长时间的查找无果后。答主神经病人思路广的优势终于在一次debug中发挥了作用。因为通信程序涉及了通信后存储参数的过程，比按键后修改参数要快很多，于是答主索性屏蔽掉了通信后存储参数的过程来排除可能性。果然再也没有出现死机的现象了！不能高兴的太早，先跑1整天试试，然后当然是没有出现了啊！答主手舞足蹈！普天同庆！老泪纵横！终于找到原因了！终于知道是怎么死的了！原来是存储芯片是后来扩容过的，比最初设计的大了不少，在保持极高的通信操作时会因为芯片增大引脚只能弯曲了以后焊接，弯折过的引脚导致电流的流通出现故障，存储芯片无法访问，编译器当然认为是硬件问题咯。而当死机以后重启有一个启动时间和通信握手的时间使得芯片冷却又恢复正常了。所以现象并不像硬件损坏引起的。以前也就听说存取如果频繁会影响芯片寿命，原来还会导致芯片工作异常啊。知道怎么死的了还治不了你？治不了我也可以绕过去啊！修复bug的过程比较简单，直接把存储最小间隔调整为5分钟。这时距离最初制造bug已经过去了3个月，期间由于在外测试错过了母上大人的50岁生日，让答主一度产生了放弃的念头。不过出于好奇、责任、还有小伙伴的支持，还有！一想到终于有一天会找到bug那种骄傲的心情，还是度过了这一段艰难的时光。好吧，这个bug在大牛的眼中可能不值一提，可是这已经是答主遇到最难最难调试的bug了。以上。
java程序员，很久以前，刚接触javascript的时候，写了一个for循环for(int i=0; i&xxx.length; i++){
但是死活不起作用，那时候还不会用FF和Chrome这类的可以F12的神器，我自己调了好久好久，把身边的同学喊来，他们也都表示吃惊，然后纷纷摇头，结果我把教我的老师喊来了，老师也是java出身，也对这我这段代码表示不理解，怎么他妈的就没有结果呢。也不知道过了多久，我发现了问题，我偷偷的把int 改成了var，然后为了在同学面前保全老师的颜面，我说：你看，可以了，突然可以了，是浏览器问题吗？这太奇怪了。老师仍然不解，让我把这断代码发给他，他自己回去研究了。
在C++ debug的书中看到的。一个服务器每天半夜3点都会重启一次，各种Debug无解。后来发现胖子网管每天半夜3点习惯去趟厕所，体重让地板向下弯曲了一点点，断路了电源。
转一个网上看到的奇闻：那还是80年代初期，我爸爸在一家存储设备公司工作，这个公司现在已经不存在了，它生产磁带机和驱动这些磁带高速运转的气动系统 —— 这是那个时代的产物。(Used under license from Laughing Squid. 原始图片可以在 这里找到。)他们技术改造了磁带驱动器，使得你可以只有一个中心驱动器 —— “A”盘 —— 由它连接着数个“B”盘，在跟A盘连接的内存里驻留这一个小型的操作系统，负责代理所有B盘的数据的读写操作。每次当你启动A驱动器，你需要在外围驱动器里插入一张软盘，操作系统会把A盘加载到内存里。这个操作系统简单的出奇 —— 它的处理能力全部从一个8字节的微型控制器产生。这种设备的目标用户是拥有大量数据的企业 —— 银行，杂志等等 —— 他们需要打印大量的地址簿或银行帐目。有个客户出现了一个问题。在打印的过程中，有个别的驱动器会停止工作，导致整个打印过程终止。为了重载驱动器，值班人员必须重启所有驱动 —— 如果这种事情发生在一个6小时的打印任务中，大量宝贵的计算机使用时间都会浪费，整个任务将不能按时间完成。公司派出了技术人员。技术人员尽了他最大的努力也不能在测试环境复制出这个问题：这个问题似乎只会出现在打印大量任务的过程中。尽管问题出在硬件上可能性微乎其微，他还是更换了所有的设备 —— 内存，微处理器，磁盘驱动，所有跟磁带机相关的部件 —— 但问题仍然出现。于是技术人员打电话给总部叫来了一位专家。专家要了一把椅子和一杯咖啡，坐在了计算机房 —— 那个时候他们已经专门为计算机提供了机房 —— 值班人员准备了一大堆的打印任务，他就在旁边看着。他等着，一直到机器崩溃。机器果真崩溃了，所有人都看着专家 —— 专家没有发现任何的线索。他命令把打印任务重新执行一次，所有的值班人员和技术人员都回各自岗位工作。专家又在椅子上做下来，等着机器崩溃。这一等就是六小时，但真的又发生了。专家仍然没有弄清是什么导致了崩溃 —— 除了有一点他注意到，崩溃总是发生在屋内人比较多的时候。他命令再打印一次，重新坐下，等着。当第三次崩溃时，他发现了一件事情。崩溃总是在值班人员更换其他没有关联的启动盘时发生的。进一步研究，他意识到当一个值班人员走过某块地板时崩溃就会发生。地板是由铝制的板块拼成，下面有6 到 8 英寸高的隔空层，计算机所使用的大量的电缆都走地板下，这样可以避免值班人员无意间踢到它们。地板块间拼合的很紧密，这是为了保证垃圾不掉进电缆通过的空间。专家说有一块地板变形了。当值班人员踩着这块变形的地板的一角时，地板块的边缘相互摩擦，这就会跟连接各地板的塑料之间产生静电，进而造成电磁干扰。如今所有的RAM都有防电磁干扰功能。但当时并没有这种技术。专家指出，电磁干扰破坏的RAM的工作，操作系统也就崩溃了。专家打电话给维护部门，拿来了一块新地板，他自己把它装上，问题就这样解决了。
这个我一定要怒答！当年在IBM 的CellBE上 （就是PS3上那块）做了不少图像处理、视频编解码的工作。这个奇葩的异构体系结构有如下几个特性：虽然号称一个芯片上有9个核，但是只有一个是通用核，普通程序只能在这个核上跑，没法和x86一样直接多线程！另外的8个运算核只有一种模式那就是128位的向量运算，只能跑一些及其精简的指令，需要在C程序中嵌入伪汇编来编程。啊？加减乘除运算符？在运算核上放多了那个会被开除吧！通用核与运算核并不共享内存空间， 他们之间所有的数据共享和同步都必须完全手工管理，想要传数据得自己调用硬件DMA，然后自己同步！因为代码全部展开能最大增加优化潜力，基本一切函数都被变成了宏！要想发挥性能一定把程序并行、向量化。用trick，gotcha一堆！人能看懂的程序都不是好程序！8个运算核上跑的程序不能用gdb debug，唯一靠谱的调试手段就是printf，但是因为运算核上printf也是通过DMA跑去通用核打印到终端，所以不同核之间的printf并不能保证同步！只有terminal access都不算问题了，至少还有vim！这一年我需要在上面从头写一个MJPEG编解码器。视频编码过的二进制流你们见过的！！！大年三十在家加班debug看dump出来的二进制流再调这种坑爹的程序你们脑补下！！！不行了我一定要贴段代码恶心下你们，哼！！这段566行气势恢宏的代码有且只有一个功能，那就是把rgba转成了yuv！！！！看不到图的请戳大！！！！哈哈哈哈哈哈！！！！
大一时候参加ABU Robocon机器人大赛，我不懂机械也不懂电子，只会写写C++，于是就负责编写机器视觉的闭环控制程序，大部分时间做图像处理，小部分时间调用串口驱动电机。结果有一天机器人突然一动不动了。赶紧改代码，改了一会儿。正当我怀疑是不是把板子烧了的时候，F5一跑发现，机器人居然又能动了！以为修复了bug，赶紧保存。继续写程序不到半个小时，机器人再次罢工。我又以为自己把刚才修好的bug又触发了。再赶紧回头改。如此，在“我操（四声）”和“我操（二声）”中不断往复。调bug大家都懂的，吃饭睡觉都得尽量避免，必须得通宵才有感觉。当折腾到第三天我人都快熬死了的时候，做硬件的师兄过来发现，有块电容他忘了接地了。。。于是电容充满电，机器人就罢工。断电呆半个小时，等这块儿质量不怎么好的电容放干净电，就可以继续正常调试了。。。
Bug有一个特点，就是你没调出来之前千难万难，你觉得自己一辈子都不会忘，可是一旦调出来了，90%的时候都会觉得，怎么这么简单……然后不出一星期就全忘了……至少我现在是一个也想不起來了……
也许有些不切题，但我说下曾遇到过最诡异的PC问题：一台办公用PC，无论在任何情况下，键入"12."都会自动变成13任何情况，指的是无论用任何软件，记事本、写字板、word、浏览器，只要存在输入框的地方，输入12.时是正常的，但只要按下回车，12.就会变成13。这个问题，可以无限重现：无论是更换键盘、重装系统、更换内存条之后，都是一样的结果。到最后也没有找到原因，也没办法修复。
贴一个图。。
高中的时候试图用OpenGL在ATI的傻逼GPU上搞HDR渲染，结果总是全屏幕NaN。调试了一个月到现在都不知道为什么，在nVidia上则没有问题。现在想来可能是driver有bug(可能没开centroid sampling导致光照中某个像素算出了nan，blur之后就污染了全部像素).做GPU还是要珍爱生命远离ATI。
客户说这是BUG。
大学学Fortran的时候，那时候学的是 if case，上机敲老师出的题目，就是无法运行助教，老师都来了，搞不定老师满脸黑线的拿着鼠标对着屏幕很久之后，老师发现我把 一个true写成ture了然后老师很不耐烦的凶了我一顿，这让我觉得万分沮丧万幸的是后来在图书馆勤工助学，利用休息的时候随手翻到几本不错的书，读完之后才对Fortran理解了一些
表示当前排名第一的所说的bug对整天搞软硬结合的小众系统的人来说就是家常便饭。特定的硬件，特定的操作系统，特定的组件，特定的应用，出了问题没有厂商支持，没有社区讨论，只能苦逼的调试。曾经遇到的一个逆天的bug是应用程序的数据，应该写入到作为存储使用的块设备中，但是居然结果就是有极低的几率把随机数据写入存储系统固件的空间。由于问题复杂，难以调试，追溯（这时候啥都不可靠了，系统？驱动？硬件？应用？），最后只能把这个问题绕过去了事。还有一个是，生产出来的外设可以对整个系统从SLEEP模式转换到普通模式的过程造成不可预知的影响。有的外设就OK，有的就不行。滋滋的电流声简直炫酷。@赵佳栋 说上述都是没能解决的不算。那就随便写个解决了的。特定的嵌入式设备和特定的某个品牌的笔记本电脑进行数据传输时可能会出现莫名其妙的中断。反复尝试后更改了一个容错设置，这项设置可以让windows在出现某种硬件错时对传输进行容错。然后，这个问题解决了。这个问题仅发生在使用自行编写的对时序有一定要求的通信程序与特定品牌的电脑进行通信的情况下，而且这种容错设置自我感觉是属于比较玄妙的范畴的……调试这个问题简直是噩梦。反复的压力测试，排查代码，比对不同设备出现的不同现象，尝试更改各种不同的针对硬件的设定。我想表达的是在特定平台，常跟硬件打交道的程序员都会遇到很多奇怪的问题。很虐心。能否解决问题往往不在于你个人有多优秀或者多努力。
写了很多次这种脑残bug了。。。手一抖，就要花好久才能找出来=.=
记得有个bug大概是酱紫...已经上线的200多个设备链接在交管局的大型交换机上, 正常运行了很久之后的某天开始, 程序开始不定期的关闭..然后重启...(通过web看到的现象是不定时的上线,下线)最开始简单粗暴的更换了设备, 但问题依旧, 拿着笔记本在现场蹲着调了好多天, 甚至亲眼目睹了工控机自动重启. 作为一个搞软件的感觉黔驴技穷的时候, 吾看到了工控机电源上的灯闪了一下= =!于是找来硬件的测了半天, 最后结论是电压不稳.... ===========================还有一个bug, 实现了某国标协议的服务系统, 用自己的客户端没问提, 用别人家的平台测试也能通过. 就是送去北京国标检测的时候过不了, 而且只有一条控制指令过不了.国标中有一行类似:Seq : 000001
Seq是标签名,000001是数值,于是吾拼字串时就直接拼成"Seq:000001"这样, 冒号前后少了空格. 加上后就过了....
2002年，爱立信RBS2202，表现在上电工作随机一段时间后不稳定，各载频板无规律时间点挂掉，软复位无效，现场硬复位后故障消失，但过一段时间后问题重现。通过对比测试，参数设置没问题，软件没问题，驱动没问题，硬件没问题。那，问题在哪？后来一场持续了一周的大雨揭示了答案——由于当地地下水水位不断下降，接地电阻持续升高导致机箱静电不能释放持续积累。硬复位时人体接触机箱门会释放静电，故障会暂时消失。你可以重写代码，重新设计硬件，但无法模拟大自然！