RipGrep 在 musl 二进制文件中偶发崩溃
RipGrep musl binaries occasionally segfault during very-large searches
在使用 RipGrep 的 x86_64-unknown-linux-musl 二进制文件进行大规模搜索时，我遇到了偶发的段错误（SIGSEGV）崩溃问题。该问题在 OpenSUSE Tumbleweed 系统上复现，特别是在高并发搜索包含约 1.8M 个文件、总计 20GiB 数据的目录树时。崩溃发生在 MUSL 的 mallocng 内存管理器的完整性断言中，具体是在 opendir 调用 calloc 时触发的。通过构建带有调试符号的 RipGrep 版本并运行特定脚本生成的测试数据，我成功复现了该问题并获取了完整的回溯堆栈。这揭示了在极端负载下，RipGrep 与 MUSL 标准库交互时存在的潜在内存安全隐患。
RipGrep 为 x86_64-unknown-linux-musl 构建的二进制文件在高并发搜索超大目录树时，偶尔会因 MUSL 的 mallocng 堆元数据完整性断言失败而触发段错误。
HN 评论区
21- ndesaulniers
哈哈，来自内核补丁：https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-...
> 我在 ripgrep 里看到了一个有趣的 bug 报告，以及一份认真但非常糟糕的 AI 生成分析
指的是 https://github.com/dfoxfranke/ripgrep-3494-analysis，我当时确实觉得“这写得太多了，不像是人写的”。
看来那个帖子是……今天发的！
- Orphis
我理解为什么人们不总是去替换 musl 的默认分配器（它就在手边，很方便）。但对于一个以“快”为核心目标的应用来说，我觉得很奇怪他们竟然没费心换成一个性能更好的分配器。
mallocng 在处理多线程竞争时表现很差。我遇到过一些通常受 I/O 限制的应用，在多线程场景下用 musl 构建时突然变成了“malloc 瓶颈”（而且仅仅只有 8 个线程）。切换到 mimalloc 后性能提升了 20 倍，非常接近 glibc 默认的表现，只是略低于 glibc + mimalloc 的组合。
我明白这里确实有个真问题，而且对某些人来说解决它很有趣，但它本不该以这种方式暴露出来。
- dosman33
任何在 HPC 集群上针对大型集群文件系统运行 ripgrep 的人，都应该停下来重新设计他们的工作流。这会生成大量的小 I/O，而这是任何大型集群文件系统的阿喀琉斯之踵。你实际上是将工作负载转嫁给了文件系统的元数据机制，而不是将其保留在集群内更高带宽的内存子系统中。只要同时有几个用户运行这类任务，就足以让高带宽文件系统崩溃。别再这么干了。
- hyperpape
链接到内核 bug 的分析可能更好：https://github.com/dfoxfranke/ripgrep-3494-analysis。
- sligor
那么，为什么这个 bug 只在 muslc 上触发，而在其他 libc 上不触发呢？
- walk12111
我通常会怀疑是 musl 的线程栈大小问题。内核 bug 确认了吗？
- wild_pointer
哇，一切都坏了 lol
- villgax
难怪 codex 里的搜索功能那么烂