
2026/08/01 21:34
Ripgrep の Musl バイナリが超大規模検索中に稀にシグナルセグメンテーションフォルトする
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Ripgrep バージョン 15.2.0 は、OpenSUSE Tumbleweed 上で MUSL C ライブラリを使用して巨大なファイルツリーを処理する際、最近 SIGSEGV エラーによってクラッシュしました。クラッシュは、高コンカレンシーワークロードの取り扱い中にディレクトリ操作のためのメモリアロケーション時に発生します。分析の結果、根本原因は
mallocng 関数内の整合性アサーション failure であり、opendir 内の calloc コールによって引き起こされました。この問題は、標準的な x86_64 システム上で約 20 GB のデータをほぼ 200 万件のファイルを処理した後に現れます。したがって、この特定のワークフローを試みるユーザーは、アプリケーションが失敗し、動作開始から約 1 分後にコアダンプファイルが発生すると予想されます。この不安定性は、MUSL libc に依存する環境で大規模なファイルインデックス化のために ripgrep を使用する開発者に対して即座の信頼性リスクを生じさせます。問題は、根本的なバグが修正されるか、ライブラリへの依存関係が更新されるまで継続します。それまでの間、これらの特定の構成内での極めて大きなディレクトリ構造における高コンカレンシー検索は信頼できず、突然の失敗に陥りやすく、重要なメタデータ操作を事実上機能停止させてしまいます。
注意:提供されたサマリーはクラッシュについて技術的に正確ですが、バイナリの起源(OpenAI Codex)、分析に使用された特定のビルドフラグ、そして正確な再実行手順については文脈を含んでいません。
本文
ripgrep における MUSL mallocng ヒープ整合性チェックによる SIGSEGV バグ報告
環境情報
以下のシステム構成とソフトウェアバージョンにて、問題が発生しました。
- ripgrep バージョン: 15.2.0 (コミット
)e89fff8 - 追加機能: PCRE2 (+pcre2)
- SIMD サポート:
- コンパイル時:SSE2 (+), SSSE3 (-), AVX2 (-)
- 実行時:SSE2 (+), SSSE3 (+), AVX2 (+)
- PCRE2 バージョン: 10.45 (JIT 有効)
- OS: OpenSUSE Tumbleweed Linux x86_64
インストール方法と再現経緯
本バグは、OpenAI Codex にバンドルされた「rg」にて最初に遭遇しました。該当バイナリは、BurntSushi/ripgrep リリースページ のものとバイト単位の同一性を確認しています。
依存関係なしに独立してバグを再現可能であり、以下のコマンドを使用してデバッグシンボル付きの
rg-15.2 を再構築し分析を行いました:
CROSS_CONTAINER_ENGINE=podman CARGO_PROFILE_RELEASE_DEBUG=true ~/.cargo/bin/cross build --release --target x86_64-unknown-linux-musl
バグの詳細説明
x86_64-unknown-linux-musl 向け ripgrep は、大きなツリーを高並列度で検索する際に稀にクラッシュします。原因は以下です:
- 根本原因: MUSL の
モジュール内のヒープメタデータに関する整合性断言の失敗mallocng - 症状:
(セグメンテーション・フォルト)SIGSEGV - 発生箇所:
から呼び出されたopendir
呼び出しにおいて、上記の整合性チェックが破綻するcalloc
再現手順
大規模な検索ツリーを用意することが必須条件です。
1. ツリー生成
LLM で作成されたスクリプト
generate_repro_tree.py を実行して、約 20GiB の巨大なツリー(総ファイル数 1.8M)を生成します:
python3 generate_repro_tree.py
2. クラッシュ誘発
生成したツリーのルートディレクトリから存在しない文字列を指定し、
rg をループ実行します:
while true; do rg tnoheueunotshisnthukoethnsueothnsiuothonesuioseuinth; done
- 環境: 24 コアシステム (RAM を十分確保)
- 発生頻度: 約 1 分後 に
が出現SIGSEGV
バックトレース (coredump)
クラッシュ時のスタック情報です:
#0 get_meta () at ../src_musl/src/malloc/mallocng/meta.h:141 #1 __malloc_allzerop () at ../src_musl/src/malloc/mallocng/malloc.c:384 #2 0x00007f71f8381b2d in calloc () at ../src_musl/src/malloc/calloc.c:41 #3 0x00007f71f83810f4 in opendir () at ../src_musl/src/dirent/opendir.c:15 #4 0x00007f71f835c133 in std::sys::fs::unix::readdir::{closure#0} (...) at library/std/src/sys/fs/unix.rs:2081 #5 std::sys::helpers::small_c_string::run_with_cstr<...> (...) at library/std/src/sys/helpers/small_c_string.rs:48 #6-#19 (Rust の内部パニック処理関連) at library/std/src/panicking.rs:xxx #20 std::panic::catch_unwind<..., ()> (...) at library/std/src/panic.rs:359 #21-#26 (スレッド開始処理)
補足: 実際の core dump ファイルも添付されています。
期待される動作
- 正常な動作: セグメンテーション・フォルト (
) にならないことSIGSEGV