Article URL: https://github.com/BurntSushi/ripgrep/issues/3494 Comments URL: https://news.ycombinator.com/item?id=49133889 Points: 131 # Comments: 81

features:+pcre2 simd(compile):+SSE2,-SSSE3,-AVX2 simd(runtime):+SSE2,+SSSE3,+AVX2 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 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. 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. Having a sufficiently large search tree seems to be essential for reproduction. Run the attached 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.