编程与软件工程nedbatchelder.com
打印这个文件，你的打印机会卡纸（2008）
Print this file, your printer will jam (2008)
2014 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章记录了一个离奇但可复现的 bug：有一个文件，只要打印它，打印机就会卡纸。作者围绕这种“特定输入触发特定硬件故障”的现象展开，说明看似荒谬的 bug 报告也可能是真的，并且值得认真复现和排查。
为什么经久不衰：它用一个具体而反直觉的案例提醒人们：离奇 bug 往往有可验证的机制，今天仍是排查“只在我这里/只对这个文件出错”类问题的经典教材。
HN 评论精选
离奇 bug 报告确实可复现；根因是整数回绕、高速送纸、纸尘与火花共同导致终端起火。
我父亲有一个类似的 bug 报告故事。那还是终端仍用纸而不是 CRT 的年代；真正的电传打字机。bug 报告大概是：“如果我在某某型号终端上打印换页，它会着火。”当时的 bug 报告表（那时还是纸质的）有常见的复选框和字段，包括“问题可复现吗？”那个框被勾上了。真有人特意站在终端旁拿着灭火器，运行同一条命令，并在它再次着火时把火扑灭。原来问题出在某个用重复换行来模拟换页的软件。某个溢出/下溢 bug 导致整数回绕，于是它不是前进几行到下一页，而是试图前进成千上万行。这个终端型号是新的高速型号，所以它会试图非常快地送纸。它用的是两侧带齿孔、齿轮插入孔中的穿孔纸带。齿和孔没有完全对齐，所以齿有时会刮到孔，撕下一些纸屑并扬起纸尘。再加上火花——我记不清是来自电机还是纸摩擦产生的静电——纸尘被点燃，终端就着火了。我就是很喜欢那位提交 bug 报告的人的画面……
lambda查看英文原文
My dad had a similar story about a bug report. This was back in the day when terminals still used paper rather than CRTs; actual teletypes. The bug report was something like "if I print a page feed on such and such terminal model, it will catch fire." The bug report form (which was paper in those days) had a few of the usual checkboxes and fields to fill in, including one for "is the problem reproducible?" That box was checked. Someone had actually gone to the effort of standing by their terminal with a fire extinguisher, running the same command and putting out the fire when it caught fire again. It turns out the problem was in some software that emulated page feeds by doing repeated line feeds. Some overflow or underflow bug caused an integer to wrap around, so instead of advancing a few lines to the next page, it would try to advance thousands or millions of lines. This particular terminal model was a new, high speed one, so it would try to advance the paper really fast. It was using those perforated strips at the sides, with the pegs that went into the holes. The pegs and holes weren't perfectly aligned, so the pegs would sometimes clip the holes a bit, causing some bits of paper to shred and get kicked up as dust. Along with a spark, I don't recall if it was from the motor or just static buildup caused by the friction of the paper, and the paper dust would ignite, causing the terminal to catch fire. I just love the image of whoever submitted that bug report, seeing the "is it reproducible" checkbox on the form, and standing by the terminal with a fire extinguisher to put it out while doing the same thing to make sure the problem was reproducible.
轮胎直径差导致牵引力控制把右前轮误判为打滑。
告诉我这算不算 bug……开一辆新车上班两年后，牵引力控制在某些弯道开始介入。我上班走一条多弯的路，之前从未触发过牵引力控制。它介入时会脉冲式制动右前轮，让车迅速减速，很可能吓到后面跟车的人。这发生了好几次，上下班都有。路面完全干燥，没有雪或雨。同样的弯、同样的速度，和以往一样。线索是我后轮磨损了，几天前换了后轮。而且我开的是特斯拉 Model 3，后驱版，前轮胎纹还很好所以没换。为什么是右前轮？我最终想明白的（你可能很快想到了）是：磨损的前轮和新后轮的直径当时略有不同。前轮直径比后轮小，因此行驶时转速略快。当我急转弯时，外侧车轮和任何转弯一样比内侧转得快。这最大程度放大了外侧磨损前轮与内侧新后轮之间的转速差。牵引力控制判定右前轮在打滑，于是对它脉冲制动。我换了前轮，一切恢复正常。
11thEarlOfMar查看英文原文
Tell me if this is a bug... After driving a new car to work for 2 years, the traction control started kicking in on certain curves. I take a windy road to work and had never had traction control activate. When it kicked in, it pulsed the right front brake and slowed the car quickly, likely unnerving the guy tailgating me. This happened several times, both going to and from work. The road was perfectly dry, no snow or rain. Same turns at the same speed as always. The clues are was that my rear tires had worn and I replaced them a few days before. And, I drive a Tesla Model 3. It's a rear-wheel drive version and the front tires still had good tread so I didn't replace them. Why the right front tire? What I finally brained out, which you may have quickly realized, is that the diameters of the worn front and new rear tires were then slightly different. The front had a lower diameter than the rear and therefore turned at a slightly faster rate when driving. When I took a hard bank, the outside wheels also turned faster than the inside as they do in any turn. That increased the delta in spin rate the most between the outside worn front tire and the inside new rear tire. The traction control determined that the right front must be slipping and pulsed the brake on it. I replaced the front tires and everything went back to normal.
单张照片能触发扫描仪缓冲区溢出，后来被收入回归测试资产。
我可能讲过这个故事（如果这篇 2008 年就发过，那可能当时就讲过）——我在科技行业的第一份工作是在惠普做 QA，测试打印机/扫描仪/复印机。某次我扫描了当时女友的一张照片，把机器搞崩了。只要以端正/干净的方式扫描这张图，我就能反复复现。我没遇到其他能复现问题的图片，只有这一张照片。底层 bug 是某种缓冲区溢出，在出货前修好了——那张图后来成了该部门持久回归测试套件的一部分。
famousactress查看英文原文
I may have told this story before (perhaps back in 2008 if this was posted then) -- but my first gig in tech was QA for Hewlett Packard testing printer/scanner/copier units. At some point I scanned a photo of my then-girlfriend and crashed the unit. Was able to do it repeatedly, provided I scanned the image in straight/cleanly. I didn't come across any other images that reproduced the issue, only this one photo. The underlying bug was a buffer overrun of some sort, was fixed before shipping -- and the image became a part of the durable regression test suite for that department.
坏网线只对特定数据序列产生 CRC 错误，导致文件传输在固定位置挂起。
让我想起很久以前调试过的一个问题。最初的抱怨是：通过防火墙的某个文件传输会挂起。进一步测试：它总在同一位置挂起。更多测试：不只是这个文件，来自无关位置的其他一些文件传输也会——而且总是在文件内的相同位置（不同文件位置不同）。两边抓 tcpdump——每次文件传输中总是同一段数据无法通过 PIX。把出问题的数据段单独做成一个小文件——这个文件无法下载，会被丢弃。不用说，这一切只在那套特定环境里可观察，实验室里没有。最后我注意到，每次我尝试推送那个出问题的小文件时，入站接口的 CRC 错误计数器都会加一。更换连接该接口的以太网线后，所有“挂起”的传输问题都解决了。我们没有进一步研究根因（用户不想换回旧线），但当时的理论是：原来的线缆坏了，但没坏到完全不能用——故障只在特定数据序列上显现。鉴于 10BaseT 和 100BaseT 都没有加扰，这个理论似乎足够合理，但无论如何还是很迷人。
ay查看英文原文
Reminded me of a problem I had been debugging ages ago. The initial complaint was that the particular file transfer through a firewall was hanging. Further tests: it hangs at the same place. More testing: not just this file, some other file transfers from unrelated places as well - and always at the same places within the file (but different across different files). Take the tcpdump on both sides - always the same segment of data within each of the file transfers does not make it through the PIX. Take the offending segment and convert it into a small file of its own - this file is impossible to download through, gets dropped. Needless to say, this all was observable only on that particular setup - not in the lab. Finally I noticed that the CRC error counter on the inbound interface increments by one every time I try to push through the offending small file. Replacing the Ethernet cable connecting that interface had solved the problem with all of the "hanging" transfers. We did not do any further research into the root cause (the user did not want to put back the previous cable), but the working theory was that the initial cable was made bad, but not bad enough to not work at all - and the fault only showed up on particular sequences of data. Given that neither 10BaseT nor 100BaseT used scrambling, this seemed plausible enough of a theory, but was quite fascinating nonetheless.
历次讨论
同类还值得读
开源应用架构
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编辑精选