Issue Report: Intermittent SIGSEGV in RipGrep musl Binaries during Massive Searches

An issue has been documented regarding the x86_64-unknown-linux-musl build of ripgrep, which exhibits occasional segmentation faults when performing extremely large-scale searches.

Reported by dfoxfranke

---

🛠️ Environment & Build Specifications

The crash was observed using the following software configuration:

Installation Context

The bug was first spotted in a version of rg bundled with OpenAI Codex (see image below). However, it was confirmed that this binary is byte-for-byte identical to the official release: ripgrep-15.2.0-x86_64-unknown-linux-musl.tar.gz.

This is a Codex-specific bug. $\rightarrow$ This is a general musl binary bug.

To facilitate analysis, a custom debug build was created using the following command: CROSS_CONTAINER_ENGINE=podman CARGO_PROFILE_RELEASE_DEBUG=true ~/.cargo/bin/cross build --release --target x86_64-unknown-linux-musl

---

🔍 The Problem

The application crashes with a SIGSEGV when traversing very large directory trees under high concurrency. The failure occurs during an integrity check of the heap metadata within the mallocng allocator (part of musl), specifically during a calloc operation triggered by opendir.

Reproduction Requirements

To trigger the crash, a massive search tree is necessary. The reporter used an LLM-generated dataset with the following properties:

• Total Data Size: $\approx 20 \text{ GiB}$
• File Count: $\approx 1.8 \times 10^6$ files

Steps to Reproduce

• Generate a directory tree mimicking the target repository statistics.
• Ensure the system has enough RAM to keep the tree in the kernel's block cache.
• Execute the following loop on a high-core system (e.g., 24 cores):

while true; do 
    rg tnoheueunotshisnthukoethnsueothnsiuothonesuioseuinth; 
done

(Note: The search string is a random literal designed to not exist in the tree.)

On the tested hardware, the SIGSEGV typically manifests within one minute.

---

📉 Technical Analysis

The crash flow can be visualized as a descent from the high-level Rust directory walker down to the low-level C memory allocator:

Coredump Backtrace

The following stack trace highlights the failure point in meta.h:

#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 ...
#16 0x00007f71f8224596 in std::thread::lifecycle::spawn_unchecked...
#17 core::panic::unwind_safe::{impl#23}::call_once ...
#18 std::panicking::catch_unwind::do_call ... (data= error reading variable: Cannot access memory at address 0x0 )
#19 std::panicking::catch_unwind ...