微信号:w2bc-com

介绍:为程序员(码农)提供最新最全的编程技术文章,分享程序员的有趣故事.提供全面的前端、php、java、android、ios、.net学习教程

你见过最难调的bug长啥样?

2016-10-13 12:29 爱编程

调试、修改bug是每个程序员最头疼的事,在发现bug时,首先要在自己代码中找问题,然后可能在测试一万次之后,把问题归咎于编译器,在所有的问题都不解决之后,再考虑硬件问题,这样的过程,大概是程序员生涯最痛苦的事了。





那作为一个苦逼的程序员,究竟碰见过哪些高难度的bug呢?在知乎的热帖中,很多相关从业者给出了自己的答案:


条件状语从句

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

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


辛晓晨
每次想起这个bug,虽然很多很多年了,我仍然满脸都是泪水啊!


当年做x86 BIOS,客户是长城电脑。有一回我们的新版本发布给他们后进行系统重启测试,就是安装好操作系统后反复不停的重启机器,看看重启几百上千次后情况如何。原因是客户买了电脑每天用,至少得保障人家用个俩三年没事吧。


结果我们的新版本重启到一百多次的时候挂了,现象就是开机黑屏,没有任何输出,就和当年的CIH病毒发作一模一样,经验判断系统压根还没有boot OS就跑飞了,我们自己测试也是这样,而且一旦出现问题就只能重新刷BIOS


这个bug非常难调,因为当时我们的版本将近300万行源代码,大概2%的汇编与98%的C,几千个源文件,光是用来参与build过程的工具就有十几个。而且这些工具都是自己写的,构建项目的时候先编译这些工具,再去用这些工具加编译器来生成最后的ROM文件


并且更加恼人的是,我们当时没有source level的debug tool,甚至连汇编级别的单步调试工具也没有,压根没法对代码做step into/over,更没法加个断点。。。当时可以用来调试BIOS的工具有两个,一个是Intel自己内部用的ITP,这个是人家公司自己的,一般不给外面人用,当时我们公司与I公司的关系尚处蜜月期,给了我们两个,但是当时被Chipset team霸占着做porting用;另一个工具就是American Arium(这家鸟公司不知道现在还活着不),这个东西说白了就是商品化的ITP,因为目标客户少,所以价格巨贵巨贵!一套系统价格几万美金,而且每一代CPU都要换一个插座上的适配器,这个适配器又是一万美金好像,还不太稳定,用着用着就挂了。。。我们公司当时有俩,但是因为没有买新一代处理器的适配器,于是只能吃灰了


于是我们唯一的调试手段就是serial debug,就是系统启动的时候会通过port 80把一些重要信息打出来,然后我们根据这些信息判断执行到哪里了,系统的情况如何。这类似原始的printf打印。如果要看一个变量的值或者验证一下我们的判断,就得重新写代码,在需要的地方加入调试语句,然后花上半个小时rebuild bios,再重新烧录,再上电运行看看打出来的到底是啥。如果有疑问,或者发现这里没有问题,又或者有了新的思路,重复上述过程。记忆中整整一个礼拜,我们都在不停的看debug info,反复烧录bios 哭啊!简直不是人过的日子!


最后发现系统可以成功的跑过PEI,到了DXE阶段的某个环节,突然就像心脏骤停一样,跑飞了!去看疑似跑飞的DXE Driver,是个很普通的平台硬件初始化程序,没什么疑点,压根没有头绪。那段时间,几乎每时每刻都在想着这个bug,实在是茶饭不思,根本没心情做任何事!


就这样差不多过了俩礼拜,经过了无数次的重启与烧录bios,以及猜测,验证,被否定,再猜测,再验证,再否定。。。。。的过程后,我们终于发现了问题的原因:


大家可能还记得电脑主板上有个CMOS,传统上用来存bios设置,但是现代的系统已经逐渐弃用这个东西。我们现在的bios芯片都是可擦写的,也就是用程序可编程。bios大小是8MB,里面会规划好,哪里是code,哪里放设置等等,然后代码里有专门写flash的函数,让大家可以保存一些东西,比如你想用硬盘还是光驱启动等等。同时系统每次启动也都会自己写一点没什么鸟用的信息进来。


问题就出在这个写flash的函数上,我们后来发现,这哥们算错了存储区域的地址,导致写很多次后终于越界,误写到了人家代码区,把人家好端端的代码给写的乱七八糟,就如同当年CIH破坏系统的方法一模一样,照这样哪个机器能点亮才怪呢!又因为每次系统写的信息不一样,比如启动时间就不太一样,所以越界需要的次数不是恒定,更加重了我们排错的难度,泪啊!


第一次写这么长的回答,还是手机打的,累!


weishuo1999
也谈谈自己遇到的一个bug吧,我之前是做电商的,某较大的电商平台,突然有一天,C2C的店主反馈,看到的订单不是自己的,看到后台的商品列表也不是自己的。

当时在睡午觉,看到这个问题,立马吓醒了,平时5个投诉就是一个故障单,那还都是一点体验上的小问题,这种订单混乱,商品混乱的错误,真是要紧急死了

于是,主管,总监都来看这个问题,一群大佬在后面看着,赶紧找最近几天的发布,测试情况,一个个回退,一个个检查,最后都无法解决问题,要知道时间一分一秒过去,半个小时还解决不了就要出大事了

后续又有用户来投诉,直接电话联系,远程控制电脑,发现操作起来巨慢,于是顺口问了一下用户的网络是什么网络。

结果他说是:“某城宽带”,一瞬间,有点感觉了,继续问其他几个投诉的客户都是“某城宽带”,然后我们打电话到那个宽带的运营商,得到的回复是“年底了,为了省流量,他们做了一部分缓存”

他们做了缓存
做了缓存
缓存

可是为毛TM的动态请求还做缓存啊,修改商品和订单的时候,随机返回成功或者失败 ......

1.这个和时间戳也没关,我们都加了token的,他们也忽略了
2.你没猜错,他们把POST和GET动态请求也缓存了,就是说你提交了一个POST修改商品的请求,他从环缓存里面随便丢个回复给用户,用户感觉修改成功了,其实请求根本没到我们这边
是的,就是这么丧心病狂。

阿九
网络硬件相关
现象:
某医院部署的网络,不定期会有半夜断网或者不稳定情况,但天亮就会恢复,客户投诉抱怨。

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

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

第一夜无事。
第二夜无事,到半夜,忽然进来个小护士,吓一跳,说,哟怎么有人啊,然后就走了。一夜无事。
第三夜无事,到半夜,又来个小护士,探头看一眼走了。一夜无事。
第四夜无事。
于是告诉院方,发现问题马上打电话,回家。
第五夜出事,赶到时已是早上,网络已经正常,查看log发现还是过热告警重启,时间在半夜3点多。联想到前几天的小护士,于是问院方半夜是否有人进入,答一些值夜班的护士会偶尔在里面休息。

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

她把机柜的冷却排风扇电源拔了!
她把机柜的冷却排风扇电源拔了!
她把机柜的冷却排风扇电源拔了!
她以为就是个通气风扇!

居然睡醒走了还知道再插回去 〒_〒
你有胆拔插头你倒是别插回去啊…

工口
必须是偶现的bug最难调
时间都花在复现问题上面了

还很难验证是否完全解决了


匿名用户
以前在看过有人帮学妹检查代码的故事,bug是学妹写完总是出现随机错误,检查一遍发现有多余字符,但让他重新写一遍就没问题,反复几次如是。每次多余的字符和位置都不一样。

抓狂之后答主直接去找学妹要她当着自己面写一遍。发现了问题:

学妹键盘放的太低,偶尔弯腰拿水杯什么的时候,胸会压到键盘……-_-||

很多时候,程序员并不愿意测试自己的代码,他们更倾向于调式完成以后交给测试去做,而想要尽可能的解决这些问题,最重要的就是在程序员编写代码之前,对代码的整个结构以及逻辑结构有明确的清晰的了解,并将自己的所有文档记录下来。这也正是解放号上线开发协作云服务想要解决的部分问题:随时随地将沟通文档记录,帮助技术人员对代码整理清晰的逻辑思路,并提供代码检测服务,智能检测代码质量,保证代码的规范性,防止后期出现问题。


最后,各位攻城狮们,你们遇到的最难调的bug有哪些呢?快来留言分享下来,让我来帮你解决O(∩_∩)~ 别忘记点击上方关注我们哦,分享出去,给你身边的朋友看看吧(*^__^*) 嘻嘻……


转载至知乎,内容版权为知乎及其作者所有。


近期热文

 
爱编程 更多文章 只能帮到这里了!女生最爱的IT男发型Top10 黑客讲述:我如何用技术逼小偷把iPhone还回来 程序员的自我吐槽 程序员是怎样撩到一个女朋友的? 程序员如何判断是否到了该辞职的时候?
猜您喜欢 像电影里黑客高手一样敲代码攻击入侵网站!屌到爆的装逼神器 ! 利用NSCache提升效率 做个合格的职场人不难 【Python爬虫实战】爬取糗事百科段子 好基友大婚,网站培训9折,仅此一天