RipGrep musl binaries occasionally segfault during very-large searches
Points and comments are a snapshot, not live.
RipGrep's musl binary segfaults during large searches, likely due to a Linux kernel race condition.
RipGrep 15.2.0 compiled for x86_64-unknown-linux-musl crashes with SIGSEGV when searching large directory trees at high concurrency. The crash occurs in musl's mallocng during a calloc call from opendir. The reporter reproduced it on a 24-core OpenSUSE Tumbleweed system with a ~20 GiB tree of 1.8 million files. A core dump and analysis suggest a race condition in Linux 7.0.12 between per-VMA-lock anonymous-fault fast path and concurrent munmap's TLB shootdown. The analysis blames musl's use of zero-page as backing for newly-faulted anonymous pages.
What commenters are saying
Many commenters criticize the AI-generated bug analysis as verbose, incoherent, or untrustworthy. Some find it detailed and well-organized. Several note the crash only reproduced on one physical machine (a Threadripper CPU), suggesting possible hardware fault rather than kernel bug. One commenter argues the kernel code change identified is likely correct but exercises hardware differently. Another suggests the issue may be a paging-structure-cache flush bug, referencing a similar LKML thread. Attempts to reproduce the crash on other hardware (e.g., Ryzen 7 5800X) failed after 10 minutes. The thread splits between those valuing the reproduction case and those dismissing the AI analysis as confidently wrong slop.