⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 网络 「网络」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

今天我们不深聊技术,我们聊一聊世界历史上,最经典且让人摸不着头脑的著名 bug。

整数溢出

1996 年 6 月 4 日,欧洲空间局(European Space Agency,ESA)发射的亚利安 5 号(Ariane 5)运载火箭在法属圭亚那的库鲁发射场发射后仅 40 秒就爆炸了。这枚火箭经过长达十年的研发,耗资 80 亿美元后进行首飞,但这一 Bug 的结果导致了 3.7 亿美元的损失。

首飞失败的原因是整数溢出,这是计算机编程中一个普遍存在的错误。在本例中,有人试图在 16 位空间中设置 64 位数字。

另外,PayPal 也犯过错。PayPal 意外向某人支付 92 千万亿美元。

当 Chris Reynolds 打开他的 PayPal 电子邮件对账单时,这位宾夕法尼亚州公关主管的账户余额显示为 92,233,720,368,547,800 美元。

在 64 位数字的世界里,这个数字太过庞大,意味着存在编程错误。所幸这一错误很快就被发现,当他再次登录时,他的账户已经归零。

PayPal 表示愿意为 Reynolds 选择的事业捐赠一笔数额不详的资金。

Windows 98 演示中的蓝屏死机

BSOD 或蓝屏死机(Blue Screen of Death),是 Windows 系统发生致命系统错误后显示的蓝色错误屏幕。它显示了系统已崩溃,此时操作系统已经处于无法可靠地运行的状态。这是由几个不同问题引起的,例如关键进程意外终止或一般硬件故障。

在 Windows 98 或 Windows 95 中,当系统尝试访问硬盘上的文件 c:\aux\aux 或 c:\con\con 时,就会发生蓝屏死机。

直到 2000 年 3 月 16 日,Microsoft 才发布一个安全更新来解决这个问题。

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

这是 Bug 界最经典的传奇之一。

我在做校园的邮件系统管理员的时候,有用户向我抱怨说:他们不能发送超过 500 英里距离的 email… 如果你之前没有听过这个故事。如果你就是这个管理员。此刻是否一脸懵逼。补充材料:用户中有位地理统计人员,还添油加醋地制作了一张邮件发送失败地图,地图上显示,她邮件的送达区域半径比 500 英里就多那么一点点:半径内的收件人,全收到了,之外的,全失败了。

请给出你的 debug plan。别说是邮票没贴够。

真相:一次软件升级导致远程服务器超时时间被设为 0。在一个具有典型负载的特定机器上,零超时意味着如果连接时间稍微超过 3 毫秒,服务器就会终止连接。而以光速传播的电信号,在 3 毫秒的时间内所能到达的距离大约是:

0.003 * c (光速) = 558.84719 miles

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

这是 Bug 界最经典的传奇之二。

一家医院用来监控病人健康的数据库,每到周三,会自己崩溃。我在周三的时候通常也会崩溃。因为那天有组会。但我感觉这应该不是这道问题的答案。补充材料:该事件中,最大的难度在于,一周只有一天有机会 debug。该系统记录日志是用 C 风格的代码编写的,把日志字符串记录到了一个固定长度的缓冲区中,其中日志时间一栏,格式例如Monday, July 17, 1997, 10:38:47.123。请给出你的debug plan。

真相:

因为周三的日志的时间一栏,缓冲区恰好溢出了。(就差一个字节写不下)不会有来自星星的 bug 也没有哪个 bug 是太阳的后裔所有那些你认为的、不惜穿越过时空,来与你情定今生的 bug 都特么是你曾经的二比惹的祸。

当我坐在窗边的时候,内存读写就会失败

这是 Bug 界最经典的传奇之三。

给一个自己设计的 SD 卡控制器写驱动,从五月开始调试,一直很顺利,到了七月份突然开始出现间歇性的 SD 卡读写失败,而且越靠近窗户,失败频率越高。

真相:电路板上芯片的正常工作温度有限,当超过一定的温度时它就带不动负载了,而7月的正午,太阳正好会通过窗户会照到板子,导致温度过高。

摇动游戏手柄的时候,游戏存档就会失败

这是 Bug 界最经典的传奇之四。

在开发 PS1 游戏“袋鼠大进击”这款游戏的存档/读档时候遇到的。Bug 的症状是每隔一段时间存档/读档都会超时失败。并且十分随机。像我这种游戏从来都是一命通关的人其实不是很在乎能不能存档的补充材料:该事件中的难点在于重现 bug。当开发人员把可能出错的代码已经注释到了四大皆空的时候,bug 依然随机出现。偶然间,测试发现了快速重现 Bug 的方法:一边摆动手柄,一边存档。请给出你的 debug plan。

真相:PS 的时钟在高频率下运行时,会影响到主板旁边的晶振,造成手柄控制器的内存卡控制器之间的串扰。手柄上一有信号,内存就被干扰了。

千年虫 bug

这是 Bug 界最经典的传奇之五。

这个千年问题是由 Bob Bemer(美国,ASCII 之父)在 1958 年第一次提出的。在其后的二十年里,他用了很大的努力,希望政府、企业和国际组织(如 IBM 和 ISO)来关注这个问题,但反响寥寥。直到 2000 年将要到来的时候,人们才感觉到两千年问题的紧迫性。于是社会和政府都投入了大量的人力和物力来避免发生大规模的计算机灾难。而从现在来看,这些努力也取得了相应的成果。

“千年虫”还包括以下两个方面的问题:一个是在一些计算机系统中,对于闰年的计算和识别出现问题,不能把 2000 年识别为闰年,即在该计算机系统的日历中没有 2000 年 2 月 29 日这一天,而是直接由 2000 年 2 月 28 日过渡到了 2000 年 3 月 1 日;另一个是在一些比较老的计算机系统中,在程序中使用了数字串 99(或 99/99 等)来表示文件结束、永久性过期、删除等一些特殊意义的自动操作,这样当 1999 年 9 月 9 日(或 1999 年 4 月 9 日即 1999 年的第 99 天)来临时,计算机系统在处理到内容中有日期的文件时,就会遇到 99 或 99/99 等数字串,从而将文件误认为已经过期或者将文件删除等错误操作,引发系统混乱甚至崩溃等故障。

Y2K 问题,或者 Y2k 问题是两千年问题的一个通常叫法。其中 Y 表示"year"也就是年,而 K 则表示拉丁前缀"kilo",表示 1000。Y2K 或者 Y2k 就是指 2000 年。

文章目录
  1. 1. 整数溢出
  2. 2. Windows 98 演示中的蓝屏死机
  3. 3. 电子邮件无法发送到 500 英里以外
  4. 4. 只有在星期三才会崩溃的系统
  5. 5. 当我坐在窗边的时候,内存读写就会失败
  6. 6. 摇动游戏手柄的时候,游戏存档就会失败
  7. 7. 千年虫 bug