您现在的位置: 主页 > 上位机技术 > python > 那些诡异难调的Bug
本文所属标签:
为本文创立个标签吧:

那些诡异难调的Bug

来源:网络整理 网络用户发布,如有版权联系网管删除 2018-08-13 

(点击上方公号,可快速关注)


转自:「程序员的那些事」微信公号综合 知乎 网友分享

网址:http://www.zhihu.com/question/34787444


记得是上个月中旬(应该是8月18日和19日),主页君连着两天发了【程序员调 Bug】的故事分享。


  • 《程序员,你碰到过的最难调的 Bug 是什么样的?》

  • 《别人遇到量子力学 Bug,我遇到了 CPU 的 Bug》

  • (其实我们伯乐在线网站 2013 年早早就发啦)


起因上在 Quora 上有一个和 Bug 相关的热门问答帖:《What’s the hardest bug you’ve debugged? | 你调试过的最难 Bug 是?》。


http://www.quora.com/Whats-the-hardest-bug-youve-debugged


在众多回复中,Dave Baggett 的经历最让人惊叹,得到了 5500 多个顶。


8月18日晚,后来有童鞋把这个话题,转到了知乎。开始引发国内程序员同行分享故事了。


主页君今天摘选了 5 位程序员的故事:


Tim Chen,786 顶


以前做windows技术支持,一直调试crash dump。就我个人的体验,有关线程安全的dump是最难调试的,来无影去无踪,看到的就是一坨已经被破坏的现场(dump),然后你需要在大脑中还原案发经过。


有一天香港某大公司(名字不透露了)上了一个case,他们自己的一个应用在生产环境中会莫名奇妙地crash。当时我就想:你自己应用crash找我们干什么,肯定是你自己代码问题,而你还不给我看你的代码!


所以几个难点:


第一,没有客户代码。


第二:客户用的系统是NT4!NT4什么概念?就是没有pdb文件的,符号文件只能对应到函数入口,对应不到具体的源代码行号。你只能把整个函数的汇编都读懂才能知道crash的地点是在做什么事。


第三:只有dump,不可能设断点调式,因为根本不知道如何重现。


反正就这么读了几百上千行的汇编(此处省略两千字),最后定位crash的地点,能看到进到EnterCriticalSection的api之后发现这个CRITICAL_SECTION结构其实已经坏了,然后就挂了。从heap结构可以看出似乎那个heap block已经被用作它用了,所以有可能那个CRITICAL_SECTION已经被delete了。


然后看谁管理这个CRITICAL_SECTION的, 发现是msvcrt,还是VC5的。好吧去找代码,还好那个代码是找得到的。然后就把所以处理这个CRITICAL_SECTION的代码全部找出来,把所有代码在不同线程中的不同执行顺序都排列出来,最后发现在某一个特殊的执行次序下会有一个race condition,导致这个CRITICAL_SECTION会被过早delete掉。还好一开始就怀疑是线程安全问题,入手方向没错。


好吧,最后居然是vc runtime的bug。当初错怪客户了。


调完这个bug的副作用就是之后看到汇编就想吐。看看现在c#的调试那根本不是事。



阿九,3211 顶


评论里信誓旦旦要小护士的兄弟,你真觉得长着一张工程师脸的你能搞定么? 木有高富帅的命,却得了高富帅的病……洗洗睡吧亲,一个成功的工程师是注孤生的……


--------- 分隔线 ---------

网络硬件相关


现象:

某医院部署的网络,不定期会有半夜断网或者不稳定情况,但天亮就会恢复,客户投诉抱怨。


调试过程:

现场查看全部网络硬件正常,查看log发现有一台汇聚交换机有反复重启动作,在重启前有高温告警。于是重点关注该机器。


该机器放在一个机柜中,机柜在一个小储藏间的角落里,储藏间不大,一边还摆着张破沙发,正好可以坐着用电脑调机器,但是实在查不出什么可疑情况会导致过热,因为投诉等级较高,于是连夜蹲守。


第一夜无事。

第二夜无事,到半夜,忽然进来个小护士,吓一跳,说,哟怎么有人啊,然后就走了。一夜无事。

第三夜无事,到半夜,又来个小护士,探头看一眼走了。一夜无事。

第四夜无事。


于是告诉院方,发现问题马上打电话,回家。


第五夜出事,赶到时已是早上,网络已经正常,查看log发现还是过热告警重启,时间在半夜3点多。联想到前几天的小护士,于是问院方半夜是否有人进入,答一些值夜班的护士会偶尔在里面休息。


于是找到进去的小护士,问是否动交换机,答没有,问进去后做了些什么动作,答只是睡觉。再追问,除此之外呢?答:就是那个排风扇太吵,睡觉的时候把电源拔了。


她把机柜的冷却排风扇电源拔了!

她把机柜的冷却排风扇电源拔了!

她把机柜的冷却排风扇电源拔了!

她以为就是个通气风扇!


居然睡醒走了还知道再插回去 _

你有胆拔插头你倒是别插回去啊…


----------- 分 割----------


再说一个吧。


研发的一块新电路板,调试正常,往机箱里面装,装上螺丝拧好后不上电了,没有电压,确认是电源短路保护。


把板子拆下来,又能用了。

装上去,又不能用了。

跟白鹿原里白孝文在窑洞里穿裤子一样。


机箱是金属并且接地的,检查了全部连接,电源肯定木有碰到地,但是用万用表量的明明就是电源地短路,而且就是裸板能用,带机壳就短路,于是怀疑螺丝。


螺丝都拧上就短路,都拆下来就正常。

然后挨个拧螺丝,定位到某个螺丝。

那个螺丝一拧上就短路。


但是电路板正面反面都是地,螺丝本来拧上去就是为了接地用的,怎么会把电源短路了呢……

这tmd不科学啊。


仔细端详该螺丝孔,发现内壁有些黑,凑近闻略有焦味。心里大概有数了,一查pcb图,果然,6层电路板,内层电源层的铺铜几乎直接铺到了螺丝孔,安全距离只留了一点点。


其实本来也没什么,螺丝只是固定用的,不会和螺丝孔内侧有什么触碰,好死不死的那块板子那个螺丝孔公差偏大,螺丝拧上去是没有完全对齐的,直接卡到了螺丝孔内壁……使劲一拧,就像刀一样切了进去,碰到了内层电源。


所以,所有灾难,都是一连串小概率事件的巧合扎堆,搞科学,也得信命。



李幼萌, 1614 顶


实在忍不住了,第一次答题。


08年的时候,我所在的公司调试三星的一款新的arm9 CPU,型号是S3C2416,是S3C2450的简配版。开发板刚入手的时候还是热乎的,因为三星的这个芯片刚刚出来,国内的代理商一共就几块开发板。各公司评估开发板都是分时使用的,只能预约几天。开发板入手的时候,三星那面连BSP都没有准备好,没有test code,没有u-boot,没有linux-kernel,甚至连Spec都是错误百出。还好我公司虽然小,研发能力在本地区还算不差,没有的东西可以自己移植。


公司急着要出新品,在没有完全验证处理器的情况下,已经layout好了PCB,并且去打样了(当时竞争确实比较激烈,400M主频处理器而且这么低的价格绝对非常有诱惑力,所以公司决定冒这个险了)。在没黑没白的工作两周后,硬件和软件做的都差不多稳定了。这时候经理说,功能上问题不大了,我们来调一调休眠时的功耗吧(我们的产品一直以待机时极低功耗作为产品的卖点之一)。然而这却是噩梦的开始……


公司的指标是待机时休眠电流500uA~800uA(电源电压4V)之间。以前所有的产品都在这个范围之内,三星方面的技术支持也明确表示,他们的解决方案达到这个指标。


在我们调试过程中发现,整个系统休眠时的功耗在1800uA左右,一直降不下来。我们重新核对了所有的IO和外围电路的所有连接,以及IO口的电平配制,都没有问题。这时,我们决定测试每一个单元的功耗,用电流表分别串联进每一个外围电路,每个单元都很正常,就是系统总体偏大1000uA。


我们连flash和ram的待机电流都测过了,仍然正常。好了,通过排除法已经确定了就是CPU的功耗过大。但是在开发板上调试休眠的时候,CPU功耗却是正常的。


我们怀疑是开发板上CPU批号和我们自己拿到的CPU样品的批号之间有区别导致的,因为三星那面也在同步修正CPU的BUG,所以我们“大胆地”把开发板上的CPU用风枪吹下来,换到我们的PCB上,把我们的CPU贴到了开发板上进行交叉验证。结果是开发板仍然功耗正常,我们自己的板子上功耗偏大,还是大了1000uA。


CPU周边的核心电路设计出现了问题!这是我们一致的判断!但是问题出在哪里,我们反复核对开发板的原理图和我们自己板子的原理图,简直就是一模一样!因为整个核心电路这部分就是从开发板上抄过来的,实在没有什么可比对的。我们转而又去怀疑PCB的问题了。


我是做系统移植和软件的,纯电气的问题我就无能为力了。闲着没事,我就反复检查我在linux中对系统休眠的IO引脚配置。然后挂着电流表做反复测试。电流表也对的起我,每次都是那个数。在一次系统待机的时候,我实在忍无可忍,一把抓起了板子。突然之间,电流表的读数飞快下降,降到了300uA!我松开手电流表的读数就又爬回来了。我把我这个惊奇的发现告诉了同事一个硬件工程师。同事说可能是哪儿摸短路了,让我试试还能不能唤醒系统。我给了一个外部中断,系统神奇的正常唤醒了!


“难道这就是问题?”,我想重现一下。但是再次在待机的时候抓起电路板的时候,读数并没有显著发生变化。“可能是手法不好”,我这么想着,用手在板子上继续抚摸着。果然!当我的手指按到PCB中的某一个位置时,电流又降了下来!反复试了几次,都是这样,就是在我手指按压的这一片,只要是用手指按着,电流就正常!


这回同事开始重视了,打开PCB图,拿着电路图和万用表,查查我摸的到底是那块电路。硬件工程师觉得不可思议,因为我摸的部分并没有连接任何的电路焊盘是空的。他于是用万用表的表笔去检查是不是PCB制版的问题,测一下这些空焊盘到底哪一个有电压。但是万用表中没有读数,这块都没有电。但是当万用表的表笔落在一处空焊盘的时候,电流表的读数又降下来了!


这可是重大发现,我们对照了一下电路图。这处空焊盘是CPU中USB-Host模块的D+信号。由于我们的产品不需要USB的主机功能,所以这一块儿没有做任何处理。多亏了画原理图和PCB的同事,多留了一手,把USB Host的引脚都在PCB上做了个引出。谁也没想到是这个引脚出现了问题,辛亏这个信号引出来了,要是没有引出来,一辈子也查不出问题。我们给D+信号加了一个下拉电阻后,系统的功耗瞬间正常了。


事后分析,三星自己开发板上有USB-Host的功能,所以USB-Host的外围电路也是完备的,所以功耗不会有问题。但是我们自己的产品上不使用USB-Host功能,没有相关外围电路,所以出了问题。这是因为在CPU休眠的时候,D+信号内部被悬空了!一句话,是三星CPU自己的BUG。我们修改了我们的PCB,增加了一个下拉电阻,同时将问题反馈给了三星。


一个月后,当我们的产品量产时,三星也及时的解决了这个问题。那个下拉电阻也不需要再贴上去了。


最后用手指头找到了CPU的BUG,不知道这算不算是最难调的。


反正这么多年了,这个经历留给我的印象是最深的。



扬帆大海,948 顶


刚看其他人的回答,又想起来一个。


现象:


很简单,有段时间学校宿舍电信的网络,经常大面积集体掉线,时间不固定,但发现最常掉线的时间是晚上10点多,各种投诉抱怨,问候学校网管家人的。(心塞呀,学校其实真的维护设备的都是我们这帮兼职的学生,那帮老师就管收钱和发钱,工资那么低,累成汪还被骂。。。)


调试:


白 天去看了下机房设备硬件一切正常,当时以为是认证服务器配置太low,晚上上线人太多就卡死,导致心跳包中断,集体被下线,后来发现发现虽然到5000多 人后会有部分心跳包没回应,但是客户端允许部分掉包,人再多也不至于丢包到集体下线,最后查log发现这台机架上的所有交换机到那个时候都会重启一下,于 是重点关注。


机房是5号宿舍楼1楼的一间宿舍改造的,加了空调,另外从配电箱里接了不限电的电源(宿舍的电嘛,晚上会断电,还有功率限制),联通电信移动每家一个宿舍做机房,于是我在机房里蹲守。


第一晚是周六,一晚无事。


第二晚,到10点多一点,咔嚓一下机架上所有交换机的灯一下全灭了,过了几秒后通电,重启。诶,我什么都没做呀,我就在机柜前坐着,也没人碰机柜呀!肿么就断电重启了,


然后又看了log,发现其他机柜切换到UPS电源供电了一小段时间,交换机的机柜是没UPS的,明显是断电了,但是我人在机房,没人碰设备呀

怀疑是插头接触不良,换了机柜里的排插。(其实想想就不太可能,接触不了还能定时发生?)


第三晚还这样,

第四夜还这样,

诶~神奇了,这是什么超自然现象?


难道是进户线有问题了?想起电线是从隔壁联通机房进来的。

于是跑联通的机房看看他们到点会有问题没?发现这边也是每到那个点,就自动切换到UPS供电。(联通给交换机也配置UPS了)怀疑是电路有问题,时不时断电。


于是,第五晚守在隔壁了。。。一夜无事!!!

诶??!!!这是神马情况?

然后就再也没事了,断电情况再也不出现了。。

足足好了1个月。直到下个月的运行商派人来例行检查了以下设备后,又出现上述问题了。


额,这是神马情况嘛!!

我去两个机房看了一下,诶,又好了,电信不掉线了!

抓狂了都!!完全是玄学呀这。

只要我进过联通的机房一次,电信的掉线问题就能解决。。

我居然还有防掉线的功能?


最后只好挨个问机房隔壁的几个宿舍有没有发现在那个点机房有没有奇怪的现象。

他们有人说感觉会掉线的日子里,机房不是那么吵!!


然后在我努力研究调查下,终于知道事情的真相:


========真相的分隔线==========


机房的供电是这样的,红色的是电线,紫色的是一排插座



电线是后改造的从室外的桥架上引入的明线,隔壁是电信的机房,因为进门的墙是承重墙巨厚还有钢筋,布线的时候为了省力,就只从联通这屋进了线,电线到插座高度后,打洞到隔壁。


联通机房隔壁宿舍的嫌睡觉时机架散热风扇太吵,就用偷偷用卡把门捅开(那种A级锁,很好撬的),睡前就偷偷把机柜的风扇电源拔了,早上再偷偷插上。。因为机 房有空调,拔了也没导致设备过热。但是。。。插机柜风扇的那个插座是进户第一个插座,就是那个孔的位置,他拔插时插头会带动插座,导致里边没接好的电线在 连接处断开一下。


为什么周五周六有时没事,因为他们可能周末集体出去了,晚上不在宿舍没人拔插头!


为什么是10点多,因为快睡觉了,才去拔插头。

为什么其他时间不定时,因为他们不一定什么时候想起来插回去。

为什么我进去一次就没事,因为我出机房后,会用钥匙反锁门,他们捅不开了,而其他人出来不反锁,只是关门,他们能捅开。


其实现在回想,最诡异的就是,我第一次蹲在联通机房的那一晚(第五晚)他没来撬门拔插头,不然也不至于追查这么久。


又想起来一个:


【关于锐捷和交换机的事】


学校某一天开始,大量用户正常上网情况下突然掉线,再次拨号时认证停顿在“寻找认证服务器”,之后提示框显示“认证失败”。但是有人发现锐捷认证失败后,“禁用”、“启用”网卡后,多次尝试锐捷拨号能够成功认证,但是在上网几分钟后会再次掉线。


锐捷的认证过程就不写了,看这个个问题的估计都大概知道。


先考虑,锐捷认证服务器故障,看了下,CPU占用率60%左右波动,内存占用2G左右。(这渣渣服务器啊。。占用这么高也是醉了)RG-SMP正常,加密狗也没问题。看来服务器没事。


那估计就是网络环境故障,看了下核心交换机到认证服务器之间的网,物理连接没问题,流量看起来也挺正常。


那估计就是核心交换机和用户终端交换机的问题。


然后发现,核心交换机到物理选课平台的服务器间最高峰时一秒快3万的封包。。。这肿么可能嘛,结果联系了那边,到服务器上一看,恩,服务器被人拿下了,被放了好几个成人和赌博网站在上边,还发现有挖流量矿的代码,还被拿来D别人,还被放了个SMTP服务器在发垃圾邮件。里边的学生个人信息被下载都不算事了。


断开与他们的链接后,CPU负载降低,但是认证还是失败。


继续查,发现另一个到行政楼的接口流量也很高,大约每秒1.5W的封包

show arp一下查看,发现一堆arp未完成报文,在Incomplete状态在IP地址无法找到其对应的MAC地址时进行转发,占用了交换机内缓存表。于是猜,要么中毒,要么出现环线,然后就查呀查,发现基础交换机上WLAN102、103流量异常,那就继续查呗,最后发现,某逗比做了这么一件事。


这个基础交换机是直接给这层供网的,大办公室留两个口,小办公室一个口,他们自己用交换机再分。


学校机构调整,部分办公室从新分配了,本来有个大办公室是,两个部门同时用的,他们每个部门自己各占用了一个接口用。后来换给另一个大部门了,他们搬家时,看到有两个接口,于是把这两个同时插到自己的集线器(居然连交换机都不是)上。


始作俑者还特肯定的和我说,这样可以加快网速,可以有双倍的带宽。

我和他说这样不行,他还不行,非说我不懂电脑了,他是在XX之家看到的,还说之前办公室里就这么接,就没事,网速还快了。(后来发现,他原来办公室其中一个接口,交换机端的插头松了,插了等于没插,网速什么的,只能说是心理作用了)


什么时候集线器能当路由器用了。。

什么时候,带负载均衡的双WAN口路由器,只卖20块钱了。。

想多玩多播起码你也要设置下吧,直接插有个毛用。。

不怕遇到小白用户,就怕遇到半懂不懂还装懂的。。



条件状语从句,5815 顶


写一个热乎的,刚发生的:


写JS,自己手机没电了,拿同事老张的安卓机调试,很简单的获取用户微信昵称,结果死活获取不到,一直显示为null。应该是跨平台问题,因为之前在自己iPhone上是没有bug的,拼命看api文档,但是都没提到这方面。急死我了。


8.21更新

刚刚老张告诉我他的昵称就是null。


8.22更新

A:“听说老张昨天被同事打死了。”

B:“哎。前天还发朋友圈呢。”

A:“是啊,年纪轻轻的,挺可惜的。”


说明

前面夸张修辞,老张最后当然没死,腿打断了而已。

有兴趣的可以试试alert(null)和alert("null")~




              查看评论 回复



嵌入式交流网主页 > 上位机技术 > python > 那些诡异难调的Bug
 我们 问题 发现

"那些诡异难调的Bug"的相关文章

网站地图

围观()