Ripgrep 15.2.0 musl 二進位檔在進行大型搜尋時發生分段錯誤 (Segfault)

Ripgrep musl 二進位檔遭遇 SIGSEGV 當機

針對 x86_64-unknown-linux-musl 目標編譯的 Ripgrep 15.2.0 二進位檔，在進行高併發的大型搜尋時，偶爾會發生 SIGSEGV (segmentation fault) 當機。當機發生在由 opendir 發起的 calloc 調用期間，具體觸發了 musl 的 mallocng 配置器中關於堆積 (heap) 中繼資料的完整性斷言失敗。

技術根本原因與回溯 (Backtrace)

當 ripgrep 遍歷非常大的目錄樹時——特別是包含數百萬個檔案的目錄樹（例如，在 20GiB 的數據中包含 180 萬個檔案）——就會觸發當機。該錯誤表現為 mallocng/meta.h 中的 get_meta() 發生當機，這表明堆積中繼資料已損壞或不一致。

導致當機的執行路徑如下：

  1. ignore::walk::Worker::run 發起目錄遍歷。
  2. 調用 std::fs::read_dir 以列出目錄內容。
  3. 這導致對 C 標準函式庫函數 opendir 的調用。
  4. opendir 調用 calloc 為目錄流分配記憶體。
  5. mallocng (musl 的配置器) 偵測到堆積中繼資料中的完整性違規，並觸發分段錯誤。

重現步驟要求

重現此錯誤需要涉及規模與併發度的特定條件：

  • 目標二進位檔： 為 x86_64-unknown-linux-musl 編譯的二進位檔（例如，官方 15.2.0 版本發行二進位檔）。
  • 規模： 具有大量檔案的目錄樹。使用了一個重現腳本 (generate_repro_tree.py) 來建立一個包含約 180 萬個檔案和 20GiB 數據的目錄樹。
  • 併發度： 高 CPU 核心數（例如，24 核）以及高併發層級。
  • 環境： 此問題在 OpenSUSE Tumbleweed Linux x86_64 上觀察到。

社群洞察與分析

圍繞此問題的討論強調了根本原因不僅限於 ripgrep 本身，而是指向 musl libc 與 Linux 核心之間的更深層互動。

核心層級的錯誤 (Kernel-Level Bug)

證據顯示，此問題實際上是核心層級錯誤的表現。社群成員引用了一個核心補丁 (kernel patch) 以及一份詳細分析，將當機與核心層級的記憶體管理有關，而非 ripgrep Rust 代碼中的邏輯錯誤。

配置器效能與競爭 (Allocator Performance and Contention)

部分使用者注意到，了 musl 中的 mallocng 在高併發多執行緒環境下處理競爭 (contention) 的能力較弱。一位貢獻者建議，將預設的 musl 配置器替換為效能更佳的替代方案（如 mimalloc）可以顯著減少競爭，並可能避免高效率應用程式中的這類失敗：

"mallocng 在處理多執行緒期間的競爭時表現不佳... 切換到 mimalloc 使效能提升了 20 倍... 這本來就不應該以這種方式顯現出來。"

檔案系統影響

從營運角度來看，在龐大的叢集檔案系統上執行高併發搜尋，可能會對檔案系統的中繼資料機制造成損害。一位使用者警告說，這種小規模 I/O 的模式會對中繼資料伺服器產生極大的壓力，甚至可能導致高頻寬檔案系統癱瘓。

Sources