錯誤的修法：GOMEMLIMIT 調錯 process、git 考古才找到原因

fix-locus（修的地方）≠ failure-locus（壞的地方）→ 修了等於沒修。

調錯 process

• 確認 fix-locus == failure-locus：同一個 process、同一個被 kernel kill 的資源。看起來「相關」的控制可能完全不相關。
• GOMEMLIMIT 管的是 Go heap only，不管 cgo、mmap、stack、其他 process（執行環境）。
• Red flag：一個標題寫「fix OOM」的 commit，調的卻是另一個 process。

git 考古：為什麼以前不會？

• Bug 是「新的」但程式碼從來沒有保護。問題是「什麼改變了條件」。git log 回答。
• 看 architecture swaps（獨立→共用）、retry changes（倍增器）、resource-limit edits（錯誤目標）。
• chore: / refactor: commit 可能靜默翻轉 failure mode，diff 看機制，不看 ticket title。

教訓

1. 修之前，確認你要修的東西跟掛的東西是同一個 process。
2. 「以前不會」→ git log --since=<date> --reverse -- <hot-file> 找出什麼改了條件。
3. 找之前的「修復嘗試」：它們透露團隊的 mental model，有時候也透露 model 是錯的。

最危險的修法是「看起來相關、其實完全不相關」，因為它在 code review 裡不會被質疑，在 OOM 裡也不會有任何效果。

參考來源：

• https://go.dev/doc/gc-guide
• https://pkg.go.dev/runtime/debug
• https://git-scm.com/docs/git-bisect
• https://blog.xargs.io/2014/03/15/git-archeology-find-the-secrets-of-those-who-came-before/
• https://gun.io/news/2025/05/git-bisect-debugging-guide/

Related： 參見執行環境、GOMAXPROCS 限制平行不限並發、共享資源的影響範圍，或回到系列總覽。