开发者生态
morning
RipGrep musl 二进制文件在非常大的搜索期间偶尔会出现段错误
2026-08-02
1 阅读
约9分钟阅读
throwaway2037
字号:
请勾选此框以确认您已查看上述内容。您使用什么版本的 ripgrep? ripgrep 15.2.0 (rev e89fff8 ) 功能:+pcre2 simd(compile):+SSE2,-SSSE3,-AVX2 simd(runtime):+SSE2,+SSSE3,+AVX2 PCRE2 10.45 可用(JIT 可用) 您如何安装 ripgrep?我最初在 OpenAI Codex 捆绑的 rg 中遇到了这个错误。该二进制文件与 https://github.com/BurntSushi/ripgrep/releases/download/15.2.0/ripgrep-15.2.0-x86_64-unknown-linux-musl.tar.gz 中的二进制文件逐字节相同,并且我已经独立于任何 Codex 依赖项重现了该错误。为了下面的分析,我构建了 rg-15.2,其中包含通过 CROSS_CONTAINER_ENGINE=podman CARGO_PROFILE_RELEASE_DEBUG=true ~/.cargo/bin/cross build --release --target x86_64-unknown-linux-musl 的调试符号。您在什么操作系统上使用 ripgrep? OpenSUSE Tumbleweed Linux x86_64 描述您的错误。当以高并发度搜索非常大的树时,为 x86_64-unknown-linux-musl 构建的 Ripgrep 有时会因 SIGSEGV 崩溃。崩溃的行是关于 MUSL 的 mallocng 内堆元数据的完整性断言,在 opendir 进行的 calloc 调用中。完整的回溯如下。重现该行为的步骤是什么?拥有足够大的搜索树似乎对于繁殖至关重要。运行附加的generate_repro_tree.py。这是一个由 LLM 编写的程序,它会生成一个充满随机文件的树,这些文件模仿了我最初遇到该错误的存储库的统计数据。它将生成一棵树,其中包含 180 万个文件中大约 20GiB 的数据。然后从该树的根开始,循环运行 rg,搜索树中不存在的任意文字字符串: while true; do rg tnoheueunotshisnthukethnsueethnsiuothonesuioseuinth;完毕 。在我的 24 核系统上,有足够的可用 RAM 供搜索树放入内核的块缓存中,SIGSEGV 通常需要大约一分钟的时间才会出现。实际行为是什么?我得到一个带有以下回溯的核心转储: #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 在 opendir () 处 ../src_musl/src/dirent/opendir.c:15 #4 0x00007f71f835c133 在 std::sys::fs::unix::readdir::{closure#0} () 在库/std/src/sys/fs/unix.rs:2081 #5 std::sys::helpers::small_c_string::run_with_cstr_stack<*mut libc::unix::DIR> () 在库/std/src/sys/helpers/small_c_string.rs:48 #6 std::sys::helpers::small_c_string::run_with_cstr<*mut libc::unix::DIR> () 位于 library/std/src/sys/helpers/small_c_string.rs:28 #7 std::sys::helpers::small_c_string::run_path_with_cstr<*mut libc::unix::DIR> () 位于库/std/src/sys/helpers/small_c_string.rs:18 #8 std::sys::fs::unix::readdir () 在库/std/src/sys/fs/unix.rs:2081 #9 std::sys::fs::read_dir () 在库/std/src/sys/fs/mod.rs:68 #10 0x00007f71f8206b5c 在 std::fs::read_dir<&std::path::Path> (path=...) 位于 /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/fs.rs:3265 #11忽略::walk::Work::read_dir (self=0x7f71f5bfeb20) 在 crates/ignore/src/walk.rs:1551 #12 忽略::walk::Worker::run_one (self=0x7f71f5bfef08, work=...) 在 crates/ignore/src/walk.rs:1749 #13 忽略::walk::Worker::run (self=...) 在 crates/ignore/src/walk.rs:1697 #14 0x00007f71f821c866 在ignore::walk::{impl#15}::visit::{closure#0}::{closure#1}::{closure#0} () 在 crates/ignore/src/walk.rs:1463 #15 std::sys::backtrace::__rust_begin_short_backtrace (f=...) at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:166 #16 0x00007f71f8224596 在std::thread::lifecycle::spawn_unchecked::{closure#1}::{closure#0} () at /home/dfranke/.rustup/
这篇文章对您有帮助吗?
订阅66必读
每日精选科技资讯,直达你的邮箱