Core Dump 流行病學：修復一個 18 年的 bug

有時候，最棘手的 Bug 不是報錯資訊最扎眼的那種，而是那些讓系統間歇性抽風、日誌乾淨得像被洗過一樣的幽靈故障。OpenAI 的工程師最近就攤上了這麼一件事：他們的基礎設施偶爾會毫無徵兆地崩潰，頻率不高，但足夠讓人抓狂。為了揪出元凶，他們幹起了類似「法醫流行病學」的活兒——大規模分析 Core Dump。

Core Dump 裡的犯罪現場

所謂 Core Dump，就是程序崩潰時記憶體的快照。通常沒人會去翻它，除非你像 OpenAI 的 SRE 團隊一樣，面對一個持續多年、來歷不明的崩潰模式。他們每天收集數千份 Core Dump，像病理學家一樣尋找共性。這一找就是好幾個月。

最終，他們鎖定了兩種截然不同的病因。一種來自記憶體硬體錯誤：某個 CPU 的快取偶爾會吐出錯誤資料。另一種則是一個軟體 Bug，在 Linux 核心的某個邊緣路徑裡已經藏了 18 年，從 2006 年 Linux 2.6 時代就存在了。兩個問題同時出現時，系統才會崩潰——就像槍裡有兩顆子彈，只有同時上膛才會走火。

為什麼花了 18 年才被發現？

這個軟體 Bug 的觸發條件極其苛刻。它涉及核心的 SLUB 記憶體分配器在特定競態條件下返回錯誤指標，而硬體錯誤恰好會在同一時刻把錯誤指標變成可執行的畸形程式碼。單獨看，每個問題都不致命；湊在一起，就是災難。大部分時候硬體錯誤被 ECC 糾錯掩蓋了，只有軟硬體共同出錯時才會露出馬腳。

OpenAI 的團隊用了一個巧妙的辦法來確認關聯：他們寫了一個核心模組，主動在特定記憶體地址注入錯誤，發現只有當核心 Bug 也被觸發時，系統才會崩潰。這種「協同故障」模式在分散式系統中極為罕見，但一旦發生，診斷難度呈指數級上升。

一些關鍵發現來自對 Core Dump 中特定暫存器的分析——比如某個 CPU 的 MCA（Machine Check Architecture）記錄顯示快取奇偶校驗錯誤，而另一個核心執行緒的呼叫棧正好指向了 SLUB 分配器的那個古老 bug。

修復之後，能學到什麼？

修復方案本身並不複雜：硬體層面通過微碼更新禁用有問題的快取預取邏輯，軟體層面給核心的那段分配程式碼加了一個記憶體屏障。真正有價值的是除錯過程本身——大規模 Core Dump 分析從一種被動的事後檢查，變成了主動的流行病學調查。

對運維工程師而言，這個案例有幾個值得記住的點：

• 不要只關注日誌中的顯式錯誤，Core Dump 裡的每一位元都可能藏著線索。
• 當多個軟硬體元件同時表現出「輕微異常」時，要考慮它們之間是否存在耦合故障。
• 自動化分析工具在處理海量 Core Dump 時不可或缺，但最終判斷仍需要工程師對核心機制有深入理解。

OpenAI 並沒有止步於修復這個單一 Bug。他們把整套分析框架沉澱下來，用於持續監控生產環境中的類似模式。用他們自己的話說：「我們不再是等崩潰發生再排查，而是主動掃描所有 Core Dump，尋找那些尚未引爆的定時炸彈。」

這大概是 18 年 bug 帶給我們的最好啟示：有些故障註定只能被耐心、資料和一點運氣發現。但做好準備的人，運氣往往更好。