當工程師在面對難以解釋的系統崩潰時，最直覺的反應通常是深入分析單一的 Core Dump（核心轉儲文件，即程式崩潰時的記憶體快照），試圖透過邏輯推理找出導致錯誤的單一原因。然而，OpenAI 在維護 Rockset（支援 ChatGPT 搜尋與插件的 C++ 數據基礎設施）時發現，這種傳統的分析方式在面對複雜問題時會失效。
這次的挑戰在於系統出現了極其詭異的崩潰現象：函數會跳轉到錯誤的記憶體位址，或者堆疊指標（Stack Pointer）在執行過程中突然偏移了 8 個位元組。團隊嘗試了各種假設，但每次分析單一案例時，都會發現證據相互矛盾，導致問題陷入僵局。
轉機來自於一種被稱為流行病學除錯法（Epidemiological Debugging）的思維轉向。團隊意識到，與其在單一病例中尋找答案，不如將所有崩潰視為一種群體現象。他們利用 ChatGPT 撰寫腳本，自動化地分析過去一年中所有生產環境的 Core Dump，提取暫存器狀態並對崩潰類型進行標記（例如：回傳至空指標、堆疊對齊錯誤等）。
透過這種對全量數據的統計分析，團隊發現原本以為是同一個 Bug 的現象，實際上是由兩個完全無關的 Bug 同時發生所造成的。
第一類問題是硬體故障。分析顯示，所有堆疊對齊錯誤的崩潰都集中在 Azure 的某個特定區域，且僅發生在特定的物理主機上。經追蹤發現，該主機的 CPU 存在隱性缺陷，會在不觸發任何硬體警報的情況下，靜默地計算出錯誤結果。將該主機移除後，這一類崩潰完全消失。
第二類問題則是真正的軟體漏洞，也就是隱藏在 GNU libunwind 中的 18 年老 Bug。libunwind 是一個用於堆疊回溯（Stack Unwinding）的函式庫，主要解決在 C++ 發生異常（Exception）時，如何安全地清理堆疊並跳轉到處理程序的問題。
這個漏洞發生在 _Ux86_64_setcontext 函數中。在執行過程中，該函數會更新堆疊指標 %rsp，使其指向新的堆疊框架，然後才讀取指令指標 %rip 以決定跳轉位置。問題在於，一旦 %rsp 被更新，原本存放指令指標的結構體就不再受內核紅區（Red Zone，一段受保護的堆疊空間）的保護。
如果在此極短的時間窗口內（約 100 皮秒）正好收到一個信號（Signal），內核會將信號框架直接覆蓋在該結構體之上，導致指令指標被損壞，最終使程式跳轉到空指標或隨機位址。
在一般應用中，這種競爭條件（Race Condition）幾乎不可能觸發。但 Rockset 為了實現輕量級的查詢計費，使用了 timer_create 每隔幾毫秒就發送一次 SIGUSR2 信號。這種極高頻率的信號觸發，將一個理論上的機率問題轉化為實際的生產環境崩潰。
OpenAI 最終將修復方案提交至 GNU libunwind 官方，透過重新排列指令順序，確保先讀取 %rip 再更新 %rsp，徹底消除了這個時間窗口。
這次經驗給所有工程師的啟示是：當你面對一個看似矛盾、無法用單一假設解釋的 Bug 時，請警惕你是否將多個不同的問題混為一談。深入分析單一案例雖然重要，但在面對大規模分佈式系統時，建立高品質的標記數據集並進行群體分析，往往能比單純的邏輯推理更快地揭示問題的本質。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。