【bug传奇】12个bug个个成经典,最后一个毁了一个帝国

1、世界第一个bug--万“虫”之母

1947年9月9日,葛丽丝·霍普(Grace Hopper)发现了第一个电脑上的bug。当在Mark II计算机上工作时,整个团队都搞不清楚为什么电脑不能正常运作了。
经挖掘真相为:
第一代的计算机是由许多庞大且昂贵的真空管组成,并利用大量的电力来使真空管发光。可能正是由于计算机运行产生的光和热,引得一只小虫子飞入了一支真空管内而引起的故障。这个团队把错误解除了,并在日记本中记录下了这一事件。也因此,人们逐渐开始用“Bug”(原意为“虫子”)来称呼计算机中的隐错。

点评:
感谢伟大的“虫母”,让我们有了为bug奋斗一辈子的人生。如果钻入的是只耗子,也许我们拥有的就是rat人生了。

2、声势最大的bug--千年虫

“一个人的灾难造就了其他人的创富”,这句话来形容臭名昭著的千年虫Bug再合适不过了。全球各IT公司提供数十亿资金给给程序员,让他们来解决“遗产”软件中的小问题。
经挖掘真相为:
在上个世纪,开发员从来没想过他们的代码和产品会跨入新千年。因此,很多开发员为了节省内存省略掉代表年份的前两位数字“19”,而当日历越来越接近1999年12月31日时,人们越来越担心在千禧年的新年夜大家的电脑系统都会崩溃,因为系统日期会更新为1900年1月1日而不是2000年1月1日,这样可能意味着无数的灾难事件,甚至是世界末日。
点评:
声势浩大的千年虫最终几乎没造成什么破坏,除了:在西班牙,停车场计费表坏了;法国气象局公布了19100年1月1日的天气预报;在澳洲,公共汽车验票系统崩溃。经过这个bug后,我们似乎有理由相信,不会再遇到下一个千年虫,或者万年虫?

3、电子邮件无法发送到 500 英里以外

用户中有位地理统计人员,还制作了一张邮件发送失败地图,地图显示,她的邮件送达区域半径比500英里多一点点:半径内的收件人全收到,外面的,全失败。

经挖掘真相为:
某次软件升级导致远程服务器超时时间被设为0。在具有典型负载的特定机器上,0超时意味着连接时间超过3ms,服务器就会停止连接。以光速传播的电信号,在3ms的时间内所能到达的距离大约:0.003 * c = 558.84719 miles
点评:
软件配置那是相当重要,软件配置那是相当重要,软件配置那是相当重要!老铁,你认为bug仅指的就是程序bug吗?too young!

4、只有在星期三才会崩溃的系统

某医院监控病人健康的数据库,一到周三,就会崩溃。
经挖掘真相为:

周三的日志时间一栏,缓冲区恰好溢出了,居然就差一个字节写不下 QAQ!
点评:
虽然医院似乎很容易与灵异事件联系起来,但软件中的灵异事件出现的频率更为频繁,“一字”疏忽可能导致的结果是骇到医生,吓死病人,作为测试员的你怕了嘛?!


5、坐在窗边时,内存读写会失败

一个程序员给自己设计的SD卡控制器写驱动,五月份开始调试,一直很顺,到了七月突然开始出现间歇性SD卡读写失败,而且越靠近窗户,失败频率越高。
经挖掘真相为:
电路板上芯片有正常工作的温度限制,超过限定温度时就会带不动负载,在7月的正午,该程序员所在地的太阳正好会通过窗户会照到电路板,导致电路板温度过高,读写失败。
点评:
看后,果断让“似乎坏了”的SD卡控制器冰敷下再试试看,纳尼,现在是真坏了?!硬件可能会在各种环境下出现问题,伴随着的是软件随之失常,所以做物联网测试的小伙伴,get这个测试点~

6、摇动游戏手柄,游戏存档就失败

某有限公司员工在开发PS1游戏的存档/读档时候遇到的bug。它的症状是每隔一段时间存档/读档都会超时失败。十分随机。但只要一摆动游戏手柄一边存档,该bug就会立刻出现。
经挖掘真相为:
PS1的时钟在高频率运行时,会影响主板旁的晶振,这进而会导致手柄控制器和内存卡控制器之间的串扰。手柄上一有信号,内存就会被干扰。
点评:
每一次灵异bug的背后,可能隐藏一个不太灵异的缘由,重点是科学地重现它。当开发人员把可能出错的代码已经注释到了四大皆空的时候,bug依然随机出现;偶然间,测试发现了快速重现Bug的方法:一边摆动手柄,一边存档。

7、魔兽世界 堕落之血bug

2005年9月,魔兽世界整个艾泽拉斯遍地尸骨,所有人都在回避人口密集的区域,所有服务器超过半数的角色受到了感染(玩家死亡次数超过一百万)。

经挖掘真相为:
当年9月13日推出了一个全新的地下城boss--“血神”哈卡,这个兄弟会使用一招名为“堕落之血”的法术,一旦中招,你的角色每2s就会受到300点的持续伤害,而且靠近你的角色也会被你传染。正常情况下咱们只要离开副本就能够摆脱疫情,然而有人却发现了一个bug,只要在地下城中将感染这个法术的宠物遣散,然后在游戏的主城里将其召回,宠物的疫情就会被保留,这场瘟疫也因此以无辜的宠物作为载体冲出了地下城。
点评:
这个事件的影响力之大,甚至引起了流行病学教授的关注,他们认为网络游戏可以作为参考模型,去研究人类在无法控制的传染病时,会以何种方式进行应对,显然就结果而言,这个bug带来的更多是积极的意义。

8、阿丽亚娜5型运载火箭,昂贵的简单复制

1996年6月4日,阿丽亚娜5型运载火箭的首次发射点火后,火箭开始偏离路线,最终被逼引爆自毁,整个过程只有短短30秒。
经挖掘真相为:
阿丽亚娜5型运载火箭基于前一代4型火箭开发。在4型火箭系统中,对一个水平速率的测量值使用了16位的变量及内存,因为在4型火箭系统中反复验证过,这一值不会超过16位的变量,而5型火箭的开发人员简单复制了这部分程序,而没有对新火箭进行数值的验证,结果发生了致命的数值溢出。发射后这个64位带小数点的变量被转换成16位不带小数点的变量,引发了一系列的错误,从而影响了火箭上所有的计算机和硬件,瘫痪了整个系统,因而不得不选择自毁,4亿美金变成一个巨大的烟花。
点评:
“复制、粘贴”可谓程序猿“搬砖”神技。但搬完砖,不要天真认为“以前没有出bug,现在也不会有bug”,否则可能丢的是老板的钱,要的是用的人的命!

9、宰赫兰导弹事件,毫秒的误差

在1991年2月的第一次海湾战争中,一枚伊拉克发射的飞毛腿导弹准确击中美国在沙地阿拉伯的宰赫兰基地,当场炸死28个美国士兵,炸伤100多人,造成美军海湾战争中唯一一次伤亡超过百人的损失。
经挖掘真相为:
当时,负责防卫该基地的爱国者反导弹系统已经连续工作了100个小时,每工作一个小时,系统内的时钟会有一个微小的毫秒级延迟,这就是这个失效悲剧的根源。爱国者反导弹系统的时钟寄存器设计为24位,因而时间的精度也只限于24位的精度。在长时间的工作后,这个微小的精度误差被渐渐放大。在工作了100小时后,系统时间的延迟是三分之一秒。侯赛因飞毛腿导弹空速达4.2马赫(每秒1.5公里),这个“微不足道的”0.33秒相当于大约600米的误差。在宰赫兰导弹事件中,雷达在空中发现了导弹,但是由于时钟误差没有能够准确地跟踪它,因此基地的反导弹并没有发射。
点评:
这个bug太(gan)糟(de)糕(piao)了(liang)!数据精度导致的bug屡见不鲜,这个事件充分告诉我们,招聘国防系统的程序猿一定谨慎招以前做过应用软件的,数据精度处理往往惨不忍睹。

10、差点引发第三次世界大战的bug

前苏联政府的报警系统错误的报出美国发射了五枚弹道导弹,幸运的是苏联值勤员推断如果真的是美国政府袭击他们的话,发射的导弹肯定不止5枚,所以他推断这只是一场虚惊。
经挖掘真相为:
前苏联软件的一个Bug,因阳光反射云顶,给出了错误的报警信息。
点评:
感谢苏联值勤员睿智的推断能力,否则碰到一个“缺心眼”,想想小心肝就一颤一颤的。极端场景测试,狠狠地说明了它的存在感。

11、一串代码,毁掉了一个空中帝国

一串代码毁掉了一个空中帝国!157名遇难者,令世人痛心!波音公司的一夜崩溃(波音股市两日暴跌11.15%,市值蒸发210亿美金)。

经挖掘真相为:
737系列都是延续的737机型设计。尽管737MAX这些机型出现后对设计提出更多需求,但波音不想重新设计,打补丁应对。后果就是飞机气动变得不稳定,有抬头倾向,容易导致失速。面对50年前的气动布局,波音同样不想重新写飞控,而是采用打补丁去防止失速。只要机翼上的空速管探测到失速,就自动俯冲加速。这个补丁叫做MCAS。

历史上,大飞机打补丁本来挺常见的,但神奇的地方就在于,美国把737max的补丁交给了开挂的阿三,重点来了:
①空速管本来有两个,一边一个。但神奇的阿三程序员逻辑很神,两边空速管的数据没有交叉检查,只要有一个空速管故障,飞机就发疯一样的俯冲。
②阿三上场之前,飞行员只要拉杆,就自动取消俯冲。但是把在737MAX上,阿三程序员把自动俯冲的逻辑改了,必须手动在触摸屏上关掉一个设置才能取消俯冲。但是MCAS一旦解除,恢复不易,严重影响后续的正常飞行。
③软件猜度飞行员的意图和正确表达依然处在自动模式的功能。如果飞行员发现异常,就只能和俯冲的飞机拼体力。拉不起来,就只能高速撞地球。
点评:
此后,阿三的程序梦毁了。不妨想想这些场景是否似曾相识?软件打了一个又一个补丁后,最后变得补不胜补。如果补丁不堪烦扰,是否可以考虑推倒重来了?

12、坐等,求一个世界级传奇bug(后面求来答案再补充)

想学习却无从下手,该如何学习?

这里我准备了对应上面的每个知识点的学习资料、可以自学神器,已经项目练手。

如果我的博客对你有帮助、如果你喜欢我的文章内容,请 “点赞” “评论” “收藏” 一键三连哦!

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在实际开发中,判断一个问题是前端bug还是后端bug需要根据具体情况来分析。以下是一些常见的判断方法: 1. 查看报错信息 如果出现了报错信息,可以先查看报错信息所在的文件或者位置。如果是前端代码报错,通常报错信息会指向前端代码的某一行,而如果是后端代码报错,报错信息则会指向后端代码的某一行。 2. 查看数据 如果数据没有正确返回或者返回的数据与预期不符,可以先查看数据返回的格式和内容,如果数据格式正确,但内容不符合预期,那么很可能是后端代码逻辑问题导致的。如果数据格式不正确,那么很可能是前端代码处理数据的问题。 3. 查看网络请求 如果是网络请求的问题,可以通过查看请求和响应信息来判断问题所在。如果请求没有发出去或者没有得到正确的响应,那么问题可能出现在前端代码或者网络环境;如果请求正确,但是后端没有正确地返回数据,那么问题可能出现在后端代码。 4. 分析业务逻辑 有些问题可能需要分析业务逻辑才能确定问题所在。比如,如果涉及到用户登录或者权限控制方面的问题,需要分析前端和后端代码的交互过程,才能确定问题所在。 综上所述,判断一个问题是前端bug还是后端bug需要综合考虑多个因素,包括报错信息、数据、网络请求和业务逻辑等方面的因素。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值