Heap corruption crashes ripgrep's musl builds under heavy concurrent searches

A bug report against ripgrep 15.2.0 documents intermittent SIGSEGV crashes in the statically-linked x86_64-unknown-linux-musl build when scanning very large directory trees at high thread counts. The fault surfaces as an integrity check tripping inside musl’s mallocng allocator — specifically a calloc issued by opendir during ripgrep’s parallel directory walk — which points to heap-metadata corruption rather than a plain logic error. Because the assertion only fires under memory pressure and concurrency, it is the kind of nondeterministic failure that is hard to pin on either the allocator or the caller.

Reproduction is demanding: the reporter generated a synthetic tree of roughly 20GiB across 1.8 million files, then ran ripgrep in a tight loop searching for a string guaranteed to be absent. On a 24-core machine with the tree cached in RAM, a crash typically appears within a minute. The reporter built a debug-symbol version to capture a full backtrace and supplied both the core dump and the exact binary, giving maintainers a concrete starting point for triage.

The wrinkle with the widest reach is distribution. The affected executable is byte-for-byte identical to the binary OpenAI ships inside its Codex tooling, meaning any crash in the upstream musl build propagates directly to downstream products that bundle it unchanged. The reporter confirmed the failure independently of Codex, isolating it to the release artifact itself — a reminder that redistributing prebuilt binaries inherits their latent allocator and concurrency bugs wholesale.