编程与软件工程beza1e1.tuxen.de
软件民间传说：奇怪的 Bug 故事合集
Software Folklore – A collection of weird bug stories
2020 — 2025，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 Andreas Zwinkau 维护的“软件怪谈”合集，收录了大量真实发生的诡异 bug 故事：从只在特定月相才失败的程序、被宇宙射线翻转的内存位，到神秘消失的变量。每条故事都附有最终查明的原因，读起来像软件界的都市传说，但全部有据可查。
为什么经久不衰：诡异 bug 故事兼具娱乐性和实战价值——它们展示了调试思维的极限案例，提醒我们真实世界的问题往往出在意想不到的地方（散热、电源、编译器、历法），因此多年来反复被翻出传阅。
HN 评论精选
寄存器分配让栈溢出以极隐蔽的方式改写了看似不可能变化的变量
我以前发过这个故事，但放在这里正合适。我有个函数：flag 为 true 时无限循环调用 g()，可它有时会退出——尽管没有任何代码写 flag。我怀疑是 g() 破坏了栈，但返回地址没被破坏，函数是正常返回的。最后我绝望到去看编译器（ARM 上的 g++）生成的汇编，才恍然大悟：flag 被存在寄存器 R11 里而不是内存。g() 被调用时会把 R11 压栈保存，而 g() 里某个栈变量越界 4 字节，恰好覆盖了 f() 保存的 flag 值。更糟的是，越界的根源是 mesgrecv() 这个函数——它接收结构体指针和大小，但大小参数指的不是整个结构体，而是其中一个子结构的大小，一位承包商用错了这个细节……
AnimalMuppet查看英文原文
I've posted this story before, but it fits here rather nicely. I had a function that looked like this: void f() { bool flag = true; while (flag) { g(); } } This function would sometimes exit. But that's really all there was to the function. Somehow flag was becoming false, even though nothing ever wrote to it. So you might think about g() smashing the stack, when a variable is mysteriously changing, but you'd expect the return address to also get written, and it wasn't - the function returned from g() to f(), found flag to be false, exited the loop, and returned from f(). Eventually I got desperate enough to look at the assembly code produced by the compiler, and I became enlightened. (This was g++ on an ARM, by the way.) flag was being stored in R11, not in memory. (Might have been R12 - it's been a while.) When g() was called, f() just pushed the return address. Then g() pushed R11, because it was going to have its own variable to stash there, and then created space for its stack variables. And one of those variables was smashing the stack by 4 bytes, over-writing the saved flag value from f(). Worse, the way the stack was getting smashed was on a call to mesgrecv(). This takes a pointer to a structure and a size, but the relationship between the two isn't what you'd expect. The size isn't the size of the structure, but rather the size of a substructure within that structure. A contractor had gotten that detail wrong when they used that mechanism for IPC between two chips. (They'd gotten it wrong on the sending side, too, so the data stayed in sync.) The net result was that the flag got cleared when four next-door-but-unrelated bytes on another CPU were all zero. It took me a month, off and on, to figure that out.
再资深的工程师也会被思维盲区困住，而“调试传奇”有时只是运气
我喜欢这些难题，尤其是那个 SSH 的故事，真正的调试巫师。不过“低级”问题也会发生在任何人身上。有一次我路过一位知名开源开发者的工位，他正被一个神秘 bug 折磨，已经定位到具体函数，正在逐行查看编译器生成的函数序言代码。我一眼就看到一个未初始化的变量被读取了。这不是因为他水平差——他有几十年的经验——只是人有时会陷入思维定势，看不见就在眼前的东西。他很尴尬（所以我不提名字），但他完全不必尴尬，这恰恰证明这种事谁都可能遇到。相关的是：我在某个组织里调试能力被传得神乎其神……原因其实只是我某天早上随手拨了几个终端设置开关，去倒了杯咖啡，回来时问题就“修好”了。
gumby查看英文原文
I love these toughies, especially the full ssh one! A true debugging wizard. “Dumb” problems can happen to anyone too. I once walked by the desk of$well_known_open_source_developer who was struggling with a mysterious bug. He’d narrowed it down to the specific function and was groveling in the function setup code (what the compiler generates before your code is called) He asked me to take a look and within seconds I saw an uninitialized variable being read. This is not because he was a bozo! He had decades of experience. It’s simply that sometimes we get slightly wedged and can’t see the thing that is “staring us in the face”. He was embarrassed (so not mentioning his name) but he should not have been. If anything it simply proves that it can happen to anyone. Related to this: at one organization my debugging skills were (spoiler: undeservedly) legendary...literally word got around until some new hire asked me about it months later. Why? I came in one morning to find some folks trying to get some new model of terminals to work with the mainframe. Back then you needed the right combo of byte length, stop bits etc. they asked me if I could fix it and I said sure. As one does I poked at the setting switches and walked off to get my coffee So I could come back and think clearly. By the time I came back all the terminals were in use so I just went on with my day. Apparently I had randomly toggled the necessary bit. But the way the story was told: I had walked in, agreed to help, rubbed my chin then simply pushed the right button and walked off without another word. Which in some sense is true, But gave me completely undeserved credit.
诡异故障的根源可能完全在硬件物理层面，如高原散热导致的电源电压跌落
说一个我亲身经历的最离谱的案例。我们公司在 Boulder 装了一台小型超级计算机，开始收到报告：计算节点间的内部通信链路只在傍晚高负载时故障。我负责相关软件，被派去排查。连续两天，我们想尽办法复现和调试，我一离开现场就收到故障通知。我们最初怀疑是宇宙射线导致的位翻转——这在当地是有名的问题——但早已做过防护，不是它。最终真相是气流和散热：高原空气稀薄，散热能力差。过热的不是处理器或链路，而是电源。电源变热后效率下降，傍晚持续高负载足以造成轻微电压跌落，让链路变得不稳定。而停机冷却后重启又一切正常……
notacoward查看英文原文
Here's the craziest one that actually happened to me. The company I worked for had installed what's best described as a mini-supercomputer (though we avoided the term) at a site in Boulder. We started getting reports of failures on the internal communication links between the compute nodes ... only at high load, late in the day. Since I was responsible for the software that managed those links, I got sent out. Two days in a row, after trying everything we could to reproduce or debug the problem, I got paged minutes after I'd left (and couldn't get back in) to tell me that it had failed again. Our original theory was that it had to do with cosmic rays causing bit-flips. This was a well known problem with installations in that area, having caused multi-month delays for some of the larger supercomputer installations in the area. But we'd already corrected for that. It wasn't the problem. What it ultimately turned out to be was airflow and cooling. The air's thinner up there, so it carries less heat. But it wasn't the processors or links that were getting too hot. It was the power supply. When a power supply gets warmer it gets less efficient. Earlier in the day or with shorter runs as we tried different things this wasn't enough to cause a problem. With it being warmer later in the day, continuous load for longer periods was enough to cause slight brown-outs, and those were making our links flaky. And of course it would always restart just fine because it had cooled down a bit. The fix ended up being one line in a fan-controller config.
历法与闰年计算错误竟能让软件在每天凌晨 3 点自动撤销用户的编辑
“只在特定月相失败”让我想起一个 C++ bug。2008 年（碰巧是闰年）我们为 NAB 展会准备数字电视节目指南的演示，我负责制作节目单。我通宵编辑发给老板，第二天早上却总因发送了空白节目单挨骂，完全不知原因。有一次我凌晨 3 点还在编辑，亲眼看到我的修改一条条被回滚，就像有人接管了 Excel 逐个撤销字段。我第一反应是该睡觉了，但后来发现：自动保存功能在凌晨 3 点整会反转行为，把每条增量逐个回滚。bug 出在春分时刻的计算上——春分时刻会在 3am、9pm、3pm 之间变动，触发了闰年代码，于是 6 小时的时间连同所有编辑一起被回滚了。
wolfspider查看英文原文
"Fail on certain moon phases" reminds me of a C++ bug I encountered while trying to set up the demo for PSIP (Digital TV Guide) destined for NAB in Las Vegas. We had programming schedules resembling excel spreadsheets and my job was just to create a good one for the demo. I would spend all night making one and sent it to my boss and each morning would get in trouble for sending in blank schedules and had no idea why. On one occasion I happened to be editing at 3am and noticed all of my edits rolling back one by one. It was actually viewable on the screen as if someone took control of excel and was rolling back each field. My immediate thought was I really need to get some sleep but later we found the auto-save feature inverted itself after 3am exactly and would go through each delta one by one rolling itself back as it had been edited. The bug was found in the calculation of the vernal equinox which moves from 3am to 9pm to 3pm. Since it was triggering the leap year code 6 hours of time would get rolled back edits and all! This was of course 2008 year of the digital transition from analog cable which happened to also be a leap year.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选