{"slug": "ripgrep-musl-binaries-occasionally-segfault-during-very-large-searches", "title": "RipGrep musl binaries occasionally segfault during very-large searches", "summary": "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.", "body_md": "-\n-\n[Notifications](/login?return_to=%2FBurntSushi%2Fripgrep)You must be signed in to change notification settings -\n[Fork 2.7k](/login?return_to=%2FBurntSushi%2Fripgrep)\n\n# x86_64-unknown-linux-musl binaries occasionally segfault during very-large searches #3494\n\n## Description\n\n### Please tick this box to confirm you have reviewed the above.\n\n- I have a different issue.\n\n### What version of ripgrep are you using?\n\nripgrep 15.2.0 (rev [ e89fff8](https://github.com/BurntSushi/ripgrep/commit/e89fff89ac9af12e8d4ce9d5fd07beb408ca730f))\n\nfeatures:+pcre2\n\nsimd(compile):+SSE2,-SSSE3,-AVX2\n\nsimd(runtime):+SSE2,+SSSE3,+AVX2\n\nPCRE2 10.45 is available (JIT is available)\n\n### How did you install ripgrep?\n\nI originally encountered this bug in the `rg`\n\nbundled 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`\n\n.\n\n### What operating system are you using ripgrep on?\n\nOpenSUSE Tumbleweed Linux x86_64\n\n### Describe your bug.\n\nRipgrep 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`\n\ncall made from `opendir`\n\n. The complete backtrace is below.\n\n### What are the steps to reproduce the behavior?\n\nHaving 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.\n\nThen from the root of that tree, run `rg`\n\nin a loop, searching for some arbitrary literal string that isn't present in the tree: `while true; do rg tnoheueunotshisnthukoethnsueothnsiuothonesuioseuinth; done`\n\n. 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.\n\n### What is the actual behavior?\n\nI get a coredump with the following backtrace:\n\n```\n#0 get_meta () at ../src_musl/src/malloc/mallocng/meta.h:141\n#1 __malloc_allzerop () at ../src_musl/src/malloc/mallocng/malloc.c:384\n#2 0x00007f71f8381b2d in calloc () at ../src_musl/src/malloc/calloc.c:41\n#3 0x00007f71f83810f4 in opendir () at ../src_musl/src/dirent/opendir.c:15\n#4 0x00007f71f835c133 in std::sys::fs::unix::readdir::{closure#0} () at library/std/src/sys/fs/unix.rs:2081\n#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\n#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\n#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\n#8 std::sys::fs::unix::readdir () at library/std/src/sys/fs/unix.rs:2081\n#9 std::sys::fs::read_dir () at library/std/src/sys/fs/mod.rs:68\n#10 0x00007f71f8206b5c in std::fs::read_dir<&std::path::Path> (path=...)\n at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/fs.rs:3265\n#11 ignore::walk::Work::read_dir (self=0x7f71f5bfeb20) at crates/ignore/src/walk.rs:1551\n#12 ignore::walk::Worker::run_one (self=0x7f71f5bfef08, work=...) at crates/ignore/src/walk.rs:1749\n#13 ignore::walk::Worker::run (self=...) at crates/ignore/src/walk.rs:1697\n#14 0x00007f71f821c866 in ignore::walk::{impl#15}::visit::{closure#0}::{closure#1}::{closure#0} () at crates/ignore/src/walk.rs:1463\n#15 std::sys::backtrace::__rust_begin_short_backtrace (f=...)\n at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/backtrace.rs:166\n#16 0x00007f71f8224596 in std::thread::lifecycle::spawn_unchecked::{closure#1}::{closure#0}\n () at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/lifecycle.rs:70\n#17 core::panic::unwind_safe::{impl#23}::call_once<(), std::thread::lifecycle::spawn_unchecked::{closure#1}::{closure_env#0}> (self=...)\n at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/panic/unwind_safe.rs:275\n#18 std::panicking::catch_unwind::do_call>, ()> (data=)\n at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:581\n#19 std::panicking::catch_unwind<(), core::panic::unwind_safe::AssertUnwindSafe>> (f=...)\n at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panicking.rs:544\n#20 std::panic::catch_unwind>, ()> (f=...)\n at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/panic.rs:359\n#21 std::thread::lifecycle::spawn_unchecked::{closure#1} ()\n at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/lifecycle.rs:68\n#22 core::ops::function::FnOnce::call_once, ()> () at /home/dfranke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:250\n#23 0x00007f71f8361fcf in alloc::boxed::{impl#31}::call_once<(), (dyn core::ops::function::FnOnce<(), Output=()> + core::marker::Send), alloc::alloc::Global> ()\n at library/alloc/src/boxed.rs:2275\n#24 std::sys::thread::unix::{impl#2}::new::thread_start () at library/std/src/sys/thread/unix.rs:118\n#25 0x00007f71f8388788 in start () at ../src_musl/src/thread/pthread_create.c:207\n#26 0x00007f71f8389e6c in __clone () at ../src_musl/src/thread/x86_64/clone.s:22\n```\n\nHere is the [core dump](https://github.com/user-attachments/files/30390841/core.gz) and the [corresponding rg binary](https://github.com/user-attachments/files/30390840/rg.gz) which produced it.\n\n### What is the expected behavior?\n\nNot a segfault.", "url": "https://wpnews.pro/news/ripgrep-musl-binaries-occasionally-segfault-during-very-large-searches", "canonical_source": "https://github.com/BurntSushi/ripgrep/issues/3494", "published_at": "2026-08-01 12:34:25+00:00", "updated_at": "2026-08-01 12:52:24.200684+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["ripgrep", "OpenAI Codex", "MUSL", "dfranke"], "alternates": {"html": "https://wpnews.pro/news/ripgrep-musl-binaries-occasionally-segfault-during-very-large-searches", "markdown": "https://wpnews.pro/news/ripgrep-musl-binaries-occasionally-segfault-during-very-large-searches.md", "text": "https://wpnews.pro/news/ripgrep-musl-binaries-occasionally-segfault-during-very-large-searches.txt", "jsonld": "https://wpnews.pro/news/ripgrep-musl-binaries-occasionally-segfault-during-very-large-searches.jsonld"}}