這是一篇關於 OpenAI 如何處理其資料基礎設施 Rockset 中極其罕見且難以追蹤的崩潰（Crash）案例分析。對於初級工程師來說，這篇文章最大的價值在於展示了當「單一案例分析」失效時，如何透過「群體數據分析」來定位問題。
背景：高效能與記憶體安全的權衡
OpenAI 的許多資料服務（如 Rockset）為了追求極致的效能與低記憶體佔用，使用了 C++ 編寫。C++ 允許開發者直接控制底層記憶體，但這也帶來了風險：一旦程式碼寫入錯誤的記憶體位址，就會觸發 Segmentation Fault（記憶體分段錯誤）導致崩潰。
當崩潰發生時，工程師通常會分析 Core Dump（核心轉儲文件），這是一種程式崩潰瞬間的記憶體快照，包含了當時的所有暫存器狀態與堆疊（Stack）內容。
令人困惑的崩潰現象
OpenAI 的團隊發現了一些極其詭異的崩潰模式：程式在執行完一個正常的 C++ 函數後，嘗試返回（Return）時崩潰。崩潰的原因是指令指標（Instruction Pointer）指向了一個無效位址（例如 NULL），或者堆疊指標（Stack Pointer, %rsp）莫名其妙地偏移了 8 個位元組。
在正常的 C++ 編譯代碼中，除非使用了內聯彙編（Inline Assembly）或特定的上下文切換函數（如 setcontext），否則 %rsp 不應該在函數執行中途被隨意修改。這讓工程師陷入僵局：如果不是程式碼 Bug，難道是編譯器出錯？還是 Linux 核心（Kernel）有 Bug？
診斷思維的轉向：從醫生模式到流行病學模式
最初，團隊採取的是醫生模式（Doctor Mode）：仔細研究少數幾個 Core Dump，嘗試推論單一原因。但因為證據相互矛盾，他們無法得出結論。
隨後，他們切換到流行病學模式（Epidemiologist Mode）：不再糾結於單個案例，而是分析整個崩潰群體。他們利用 ChatGPT 寫腳本，自動分析過去一年所有生產環境的 Core Dump，提取暫存器狀態並分類。
結果發現，原本以為是同一個 Bug 的現象，實際上是兩個完全獨立的問題：
第一類：硬體故障（Bad Host） 這類崩潰僅發生在特定區域的單一物理主機上。該主機的 CPU 運算出現靜默錯誤（Silent Hardware Corruption），導致暫存器數值被隨機篡改。解決方案很簡單：將該主機列入黑名單並停用。
第二類：18 年前的開源庫 Bug（libunwind） 排除硬體問題後，剩下的崩潰全部發生在 C++ 異常處理（Exception Unwinding）過程中。
技術深挖：GNU libunwind 的競態條件
當 C++ 拋出異常時， runtime 需要執行 Unwinding（堆疊回溯）來尋找對應的 catch 區塊並清理資源。這個過程由 libunwind 庫完成。
工程師發現 libunwind 在恢復暫存器狀態時，會先在堆疊上建立一個 ucontext_t 結構體。關鍵在於其彙編指令的執行順序： 程式先更新 %rsp 指標，使其指向新的堆疊底部。 隨後才從 ucontext_t 結構體中讀取指令指標（RIP）來跳轉。
問題就在於：一旦 %rsp 被更新，原先存放 ucontext_t 的記憶體區域就不再屬於活動堆疊（Active Stack）或紅區（Red Zone）。此時如果系統恰好收到一個信號（Signal），Linux 核心會將信號處理幀（Signal Frame）壓入堆疊，極有可能覆蓋掉剛才那個 ucontext_t 結構體。
這是一個極其狹窄的競態條件（Race Condition）：信號必須在 %rsp 更新後、RIP 讀取前的這「單個指令週期」（約 100 皮秒）內到達。
為什麼這個 Bug 現在才被發現？
這個 Bug 已經存在 18 年，但觸發它需要三個條件同時滿足： 高頻率的異常拋出：Rockset 使用異常來實現背壓（Backpressure）機制，導致異常發生率極高。 高頻率的信號遞送：為了精確計算 CPU 時間，OpenAI 頻繁發送 SIGUSR2 信號。 信號處理程序佔用較多堆疊：近期更新增加了信號處理函數的堆疊深度，使其更容易覆蓋到被釋放的 ucontext_t 記憶體。
當這三個因素相乘，原本機率極低的事件在大規模集群中變成了每天發生數十次的常態。
總結與啟發
OpenAI 最終透過將 libunwind 替換為 libgcc 的實現來解決問題，並將修復提交給上游開源社群。
這次經驗給工程師的啟發是：面對複雜的系統崩潰，單純的邏輯推理有時會被錯誤的假設誤導。建立高品質的群體數據集（Population-level data），透過數據關聯性（如區域、硬體型號、版本）來拆分問題，往往比深鑽單一 Core Dump 更有效率。
來源：openai.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。