RipGrep musl binaries occasionally segfault during very-large searches Ripgrep 15.2.0, a command-line search tool, occasionally segfaults during very-large searches when built for x86_64-unknown-linux-musl, according to a GitHub issue filed by user dfranke. The crash occurs in a calloc call from opendir, triggering an integrity assertion in MUSL's mallocng, and can be reproduced by searching a tree of roughly 20GiB across 1.8M files on a 24-core system. The issue affects the official musl binary and the version bundled with OpenAI Codex. - - Notifications /login?return to=%2FBurntSushi%2Fripgrep You must be signed in to change notification settings - Fork 2.7k /login?return to=%2FBurntSushi%2Fripgrep x86 64-unknown-linux-musl binaries occasionally segfault during very-large searches 3494 Description Please tick this box to confirm you have reviewed the above. - I have a different issue. What version of ripgrep are you using? ripgrep 15.2.0 rev e89fff8 https://github.com/BurntSushi/ripgrep/commit/e89fff89ac9af12e8d4ce9d5fd07beb408ca730f features:+pcre2 simd compile :+SSE2,-SSSE3,-AVX2 simd runtime :+SSE2,+SSSE3,+AVX2 PCRE2 10.45 is available JIT is available How did you install ripgrep? I originally encountered this bug in the rg bundled with OpenAI Codex. That binary is byte-for-byte identical with the one in https://github.com/BurntSushi/ripgrep/releases/download/15.2.0/ripgrep-15.2.0-x86 64-unknown-linux-musl.tar.gz https://github.com/BurntSushi/ripgrep/releases/download/15.2.0/ripgrep-15.2.0-x86 64-unknown-linux-musl.tar.gz and I've reproduced the bug from that independently of any Codex dependency. For the analysis below, I built rg-15.2 with debug symbols included by way of CROSS CONTAINER ENGINE=podman CARGO PROFILE RELEASE DEBUG=true ~/.cargo/bin/cross build --release --target x86 64-unknown-linux-musl . What operating system are you using ripgrep on? OpenSUSE Tumbleweed Linux x86 64 Describe your bug. Ripgrep built for x86 64-unknown-linux-musl occasionally crashes with a SIGSEGV when searching very-large trees at a high degree of concurrency. The crashing line is an integrity assertion regarding heap metadata inside MUSL's mallocng, in a calloc call made from opendir . The complete backtrace is below. What are the steps to reproduce the behavior? Having a sufficiently large search tree seems to be essential for reproduction. Run the attached generate repro tree.py https://github.com/user-attachments/files/30390612/generate repro tree.py . This is an LLM-written program which produces a tree full of random files which mimic the statistics of the repo in which I originally encountered the bug. It will produce a tree containing roughly 20GiB of data across 1.8M files. Then from the root of that tree, run rg in a loop, searching for some arbitrary literal string that isn't present in the tree: while true; do rg tnoheueunotshisnthukoethnsueothnsiuothonesuioseuinth; done . On my 24-core system, having enough free RAM for the search tree to fit in the kernel's block cache, it typically takes about a minute for the SIGSEGV to appear. What is the actual behavior? I get a coredump with the following backtrace: 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 stack< mut libc::unix::DIR at library/std/src/sys/helpers/small c string.rs:48 6 std::sys::helpers::small c string::run with cstr< mut libc::unix::DIR at 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 at library/std/src/sys/helpers/small c string.rs:18 8 std::sys::fs::unix::readdir at library/std/src/sys/fs/unix.rs:2081 9 std::sys::fs::read dir at library/std/src/sys/fs/mod.rs:68 10 0x00007f71f8206b5c in std::fs::read dir<&std::path::Path path=... at /home/dfranke/.rustup/toolchains/stable-x86 64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/fs.rs:3265 11 ignore::walk::Work::read dir self=0x7f71f5bfeb20 at crates/ignore/src/walk.rs:1551 12 ignore::walk::Worker::run one self=0x7f71f5bfef08, work=... at crates/ignore/src/walk.rs:1749 13 ignore::walk::Worker::run self=... at crates/ignore/src/walk.rs:1697 14 0x00007f71f821c866 in ignore::walk::{impl 15}::visit::{closure 0}::{closure 1}::{closure 0} at crates/ignore/src/walk.rs:1463 15 std::sys::backtrace:: rust begin short backtrace