要注意！RipGrepのmuslバイナリで大規模検索時にセグフォが発生する件

RipGrepのmuslバイナリを使用して非常に大規模な検索を実行する際、稀にセグメンテーションフォールト（セグフォ）が発生する問題が報告されています。

カーネルバグの解析については、こっちのリンクを貼るのが良さそうだね: https://github.com/dfoxfranke/ripgrep-3494-analysis

で、なんでこのバグは他のlibcじゃなくてmuslだけで発生するわけ？

普通ならmuslのスレッドスタックサイズを疑うところだけど、そのカーネルバグって確定なの？

muslのデフォルトアロケータをそのまま使い続ける人が多いのは分かるよ（手軽だしね）。でも、「高速であること」が目的のアプリケーションなら、もっと高性能なものに置き換えていないのが不思議でならない。

mallocngはマルチスレッド環境での競合に弱いんだよね。普段はI/Oバウンドなアプリでも、muslでマルチスレッド（たった8スレッドでも）にしてビルドすると、急に「malloc」バウンドになったことがあったよ。mimallocに変えたらパフォーマンスが20倍も改善して、glibcのデフォルトとほぼ同じ、glibc + mimallocの構成より少し劣る程度までになった。

確かに根本的な問題があるのは面白いし、解決しようとするのは分かるけど、そもそもこんな形で問題が表面化するような事態にはなってほしくなかったな。

HPCクラスタ上の巨大なクラスターファイルシステムでripgrepを動かそうとしてる人は、一旦立ち止まってワークフローを見直したほうがいい。そういうやり方だと大量の小さなI/Oが発生して、それが巨大なクラスターファイルシステムにとっての弱点になるんだよ。高い帯域幅を持つメモリサブシステムで処理を完結させるんじゃなくて、ファイルシステムのメタデータ機構に負荷を押し付けてる状態だからね。こういうジョブを数人が同時に実行するだけで、高帯域なファイルシステムでもすぐパンクするよ。もうやめておいたほうがいい。

へえ、カーネルパッチによるとさ: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-ZHY5T_=4QY5+Fn8BM4A@mail.gmail.com/

ripgrepの面白いバグ報告と、熱心だけどかなり出来の悪いAI生成の解析を見かけた

これって https://github.com/dfoxfranke/ripgrep-3494-analysis のことだよね。私も確かに「人間が書いたにしては、ずいぶんと分量が多いな」って思ってたんだ。

そのスレッドって、今日のものみたいだね！