编程与软件工程marcan.st编辑精选
调试一个诡异的 Go 运行时 Bug
Debugging an evil Go runtime bug
2017 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者记录了 Go 程序反复随机崩溃的完整排查过程：先怀疑内存与硬件，再用 GOMAXPROCS、二进制哈希比对等手段逐步缩小范围，最终追到 Go runtime 与 Linux 线程栈/vDSO 交互相关的深层 bug。文章既是一次硬核系统调试实录，也把极隐蔽的 runtime 问题讲得清晰有趣。
为什么经久不衰：它展示了顶级系统调试的完整方法论和追根究底的耐心，把一次几乎无从下手的随机崩溃拆解成可验证的线索，多年后仍是学习排查复杂问题的范本。
HN 评论精选
赞赏用二进制哈希/正则快速定位问题目标文件的调试技巧。
我特别喜欢他用二进制 SHA 哈希上的正则来缩小问题目标文件的做法。当年我做内核开发时用 cscope+kdb 找 bug，要是会这招能省下大量瞎猜的时间！
ereyes01查看英文原文
Man I loved the approach to narrow down the offending object file using the regex on the SHA hash of the binaries. That would've saved me lots of time hunting and guessing bugs with cscope+kdb back in my kernel hacker days!
佩服作者不满足于绕过问题，而是继续追查根因。
这些调试技能真厉害，我也佩服他追根究底的毅力和意愿。> 我试着设置 GOMAXPROCS=1，让 Go 只用一个 OS 线程运行 Go 代码，崩溃也停了，这再次强烈指向并发问题。换我大概就停在这里了。
donquichotte查看英文原文
Wow, these are some serious debugging skills. I also admire the tenacity and the will to investigate the root cause. > I tried setting GOMAXPROCS=1, which tells Go to only use a single OS-level thread to run Go code. This also stopped the crashes, again pointing strongly to a concurrency issue. I think I would have stopped there.
强调作者搭建多内核测试环境追根究底，远超一般 workaround。
这真的很疯狂。99% 的开发者找到 workaround 就继续了。他居然搭了多内核测试台来缩小不稳定来源，这种投入我很少见，致敬。
BobbyJo查看英文原文
This is honestly wild. 99% of devs would have found a work around and moved on. Going so far as to create a multi-kernel test bench to narrow down the source of the instability is a level of dedication I have not personally seen, and I respect it.
尝试用自己的话总结根因：Go 自建栈与 vDSO 假设栈可自动增长之间的冲突。
我感觉还没完全搞懂这里发生了什么。下面这个理解对吗：‘线程有一个由 OS 自动增长的“标准”栈。但你也可以把任意值放进 RSP 来创建自己的栈。这个 Go 程序就是这么做的，而 vDSO 假设自己运行在自动增长的栈上，试图探测它，结果导致内存破坏。’
im3w1l查看英文原文
I feel like I still didnt fully understand what's going on here. Is the following correct? "Threads hava a 'canonical' stack that the OS auto-grows for you as you use more of it. But you can also create your own stack by putting any value you want in RSP. This is what the Go program did, and the vDSO, assuming it ran on an auto-growing stack, tried to probe it, which lead to corruption."
历次讨论
同类还值得读
开源应用架构
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编辑精选