7 ms·
RipGrep musl binaries occasionally segfault during very-large searches
- shevy-java 2mo ago[flagged]
- amluto 2mo agoThis bug is almost certainly not a bug in ripgrep or Rust or musl or any user code at all. Maybe one could complain that musl is using an inferior allocator that is freeing then immediately reallocating the same address. edit: silly observation: the general Rust practice of using immutable bindings by default and not leaking shadowing bindings out of blocks would have made the bug I think I found less likely.
- deleted 2mo ago[deleted]
- jibal 2mo agoThank you for writing virtually all of the intelligent competent comments on this page.
- gpm 2mo agoIn addition to this likely not being a bug in the code you're pointing at, but the kernel (written in C). musl is literally C code, and that most rust users compile against glibc just like most C users do.
- vlovich123 2mo agoA kernel bug and you’re criticizing Rust. Weird take
- saghm 2mo agoThe bug is in the C code that Rust is interacting with. If anything, you seem to be making an argument in favor of replacing even more of the C code with Rust so that this doesn't happen. What you seem to think is a defense of C is accidentally just providing ammunition to the "rewrite it in Rust" crusade that I'm guessing you're very much not a fan of. There are very solid arguments against rewriting everything in Rust, and you're arguably doing more harm than good by making a counterproductive one.
- inigyou 2mo agoRust wouldn't have helped, because this is a logic bug in the kernel, that creates a memory bug in userspace. The relevant kernel code would probably be marked "unsafe" with or without the bug.
- saghm 2mo ago> Rust wouldn't have helped, because this is a logic bug in the kernel, that creates a memory bug in userspace. Unless I'm misunderstanding, the bug is kernel code accessing out-of-bounds memory in an array. That would 100% not segfault in normal Rust code. > The relevant kernel code would probably be marked "unsafe" with or without the bug. I mean, sure, if you remove the safety rails that prevent you from running off the side of the cliff, then you will in practice likely ending up running off the cliff. If you have to explicitly do that though, it still makes it a lot more obvious that this is a risk than if you refuse to have safety rails anyway for any purpose.
- vlovich123 2mo agoThe kernel bug I believe hasn’t been root caused quite yet although the LLM does seem to have potentially found an unrelated problem.
- saghm 2mo agoInteresting, I hadn't heard that! That does sound like it's just as premature to claim Rust wouldn't have prevented it as it is to claim it would have, which I think stands as valid criticism of the comment I originally responded to.
- raincole 2mo agoFor starters, musl is a C library, not a Rust library.
- hamburglar 2mo agoI would suggest you revisit this in a day or two and reevaluate whether your knee-jerk blaming of rust was appropriate here, then ask yourself what biases led you to do that.
- Ar-Curunir 2mo agoShevy is a long time troll. Should have been banned a while back
- gertop 2mo agoHe's been banned multiple times actually (and from Reddit as well!) but he comes back with other names in the form of shevy-<language>>
- hamburglar 2mo agoI guess that makes introspection unlikely.
- wild_pointer 2mo agowow, everything is broken lol
- hyperpape 2mo agoThe analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis https://github.com/dfoxfranke/ripgrep-3494-analysis.
- yawndex 2mo agosoulless unreadable AI slop
- hoppp 2mo agoI can read it but not sure if worth spending energy on it. It doesn't make sense for the reader to spend more energy than the writer spent on creating it.
- wild_pointer 2mo agoPoC||GTFO, if it reproduces, it's valuable
- deleted 2mo ago[deleted]
- fr2029 2mo ago[dead]
- smallerize 2mo agoThen post whatever notes were fed into the AI instead. The verbosity and self-congratulating add negative value.
- im3w1l 2mo agoWhat will you do when the prompt was "Figure out the bug and write a report for me". Not saying it was in this particular case, but I think at least in other cases, it will be.
- sligor 2mo agoSo, why the bug triggers only with muslc and not other libc ?
- inigyou 2mo agoCoincidence. It also only triggers on one machine.
- cyberax 2mo agoProbably because musl's allocator exposes single newly faulted pages directly to the app. Other allocators tend to pre-allocate multiple pages at a time, so that the race window is narrower.
- mbac32768 2mo agoShouldn't tons of applications linked against musl be crashing all over the Internet if it can express this kernel bug?
- cyberax 2mo agoNot necessarily. Another key here is that the allocation is triggered from the libc, while the main app uses another allocator. These kinds of issues with VM are notoriously tricky to replicate. And the main debugging method is "staring intently at the code".
- walk12111 2mo agoI would normally suspect musl's thread stack size. Is the kernel bug confirmed?
- rainmaking 2mo ago[flagged]
- sr0b0t 2mo ago[dead]
- villgax 2mo agoNo wonder search in codex is so a$$
- ramon156 2mo agoCodex uses musl?
- derdi 2mo agoCodex bundles a ripgrep binary that is linked against musl. This is noted in the bug report: "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 https://github.com/BurntSushi/ripgrep/releases/download/15.2... [...]"
- Ar-Curunir 2mo agoWhat does one have to do with the other?
- villgax 2mo agoActually read the post before ignoramusing here
- Orphis 2mo agoI get why people don't bother replacing the default allocator from musl all the time (it's there, convenient). But in an application whose purpose is to be FAST, I find it weird they haven't bothered replacing it with another more performant one. mallocng is bad at dealing with contention during multithreading. I've had applications that usually were I/O bound suddenly become "malloc" bound when building with musl in multithreaded scenarios (and only just 8 threads). Switching to mimalloc improved performance by 20x, very close to what glibc offers by default, and just a bit under a glibc + mimalloc configuration. I get that there's a real issue there and it's interesting (to some) to address it, but it should have never surfaced this way in the first place.
- vlovich123 2mo agoIt’s a kernel bug. While I agree libc allocators suck for no good reason, it seems like this work of equally likely hit other application code including mimalloc and glibc.
- Orphis 2mo agoSure, but the problem isn't that the bug exists, is that it has surfaced in a performance application using musl and exerting code paths in a slow allocator. mallocng should not be used at all.
- tripflag 2mo agoit's a tradeoff; mallocng does have benefits as well -- for example it uses less than half the amount of RAM compared to mimalloc and glibc for certain Python workloads. While yes it is a bit slower, I prefer mallocng in many cases.
- Orphis 2mo agoripgrep is there to be FAST. Trading any speed to improve memory efficiency over a longer period of time for a process with a short life-time doesn't make sense in this case. It's also a development tool. If your development machine is having RAM issues because it's doing a grep, you have bigger problems to solve. As for other workloads that might use less RAM with mallocng compared to other performant ones, I'm curious to know about the magnitudes we're talking about. From 10MB to 20MB or from 100MB to 2GB? How was the speed of the program? Was there any multithreading involved?
- deleted 2mo ago[deleted]
- asdflkt34z 2mo ago[dead]
- asdflkt34z 2mo ago[dead]
- asdflkt34z 2mo ago[dead]
- dosman33 2mo agoAnyone running ripgrep on a an HPC cluster against a large cluster filesystem needs to stop and redesign their workflow. This generates high amounts of small I/O which is the Achilles heel of any large cluster filesystem. You are exporting your workload onto the metadata mechanisms of the filesystem rather keeping it within the higher bandwidth capable memory subsystem on your cluster. It doesn't take but a couple users running these types of jobs simultaneously to bring a high-bandwidth filesystem to its knees. Just stop it already.
- btown 2mo agoSimilarly, I've often wondered if this is the root cause of why GitHub has become fragile of late. All of a sudden you have operations on billions of tiny files that are amplified by AI usage. And object graphs are so fragmented by nature that it's hard to e.g. prefetch a page into memory and ensure that common git operations mainly touch that page's set of objects. And if https://isolveproblems.substack.com/p/how-microsoft-vaporized-a-trillion https://isolveproblems.substack.com/p/how-microsoft-vaporize... is to be believed even in the slightest, any unoptimized paths in Azure's filesystem abstractions could cause usage spikes to have massive splash radius.
- gsu2 2mo ago> All of a sudden you have operations on billions of tiny files that are amplified by AI usage. And object graphs are so fragmented by nature that it's hard to e.g. prefetch a page into memory and ensure that common git operations mainly touch that page's set of objects. In theory, that's what git's packfiles are for: loose objects get packed together into a file, and if the file is well-arranged then objects that tend to get read together will also end up getting paged-in together (see also: https://www.kernel.org/pub/software/scm/git/docs/technical/pack-heuristics.html https://www.kernel.org/pub/software/scm/git/docs/technical/p...). GitHub in particular has spent a lot of time and effort on packing things well (e.g. https://github.blog/open-source/git/scaling-monorepo-maintenance/ https://github.blog/open-source/git/scaling-monorepo-mainten...), so I doubt that the "billions of tiny files" problem is at the root of their recent instability.
- 2mo ago
- ndesaulniers 2mo agoHeh, from the kernel patch: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-ZHY5T_=4QY5+Fn8BM4A@mail.gmail.com/ https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-... > I saw a fun bug report in ripgrep and a studious but pretty bad AI-generated analysis Referring to https://github.com/dfoxfranke/ripgrep-3494-analysis https://github.com/dfoxfranke/ripgrep-3494-analysis which I indeed thought "that's an awful lot written to have been written by a human." Looks like that thread is from...today!
- vaughands 2mo agoThanks for the fun read.
- vintagedave 2mo agoThat was a tough read, but in all the verbiage I do not see it identifying the same code or area as the real genuine human on lore.kernel. For those who can understand Claude better than me: did it anywhere actually identify the issue?
- gpm 2mo agoAssuming Andy (the mailing list post) is right, no it didn't. I know this because he said so here in this comment section: https://news.ycombinator.com/item?id=49134550 https://news.ycombinator.com/item?id=49134550 That said the AI was sort of directionality right... it identified roughly the right code.
- gruntled-worker 2mo agoUntil ~2000, "cellphone user in public" equated with "smug asshole." We're at that icky rejection stage with AI. Two years ago, that writeup would have been viewed as a generous gift of time to the community. Now we can't be bothered to read through it because we know where it came from, and that it's just worth $0.06 in tokens. Another reason (I think) is because we know what it portends. In a few years, digging manually through bugs will probably be a last resort. We'll go from sneering to yawning at the reports, as another AI agent reads them and verifies the fix. Just like we ignore compiler-generated assembly code and people on their cellphones.
- nyc_pizzadev 2mo agoInteresting related article: https://www.theregister.com/ai-and-ml/2026/07/29/closed-models-refuse-to-help-researcher-swat-linux-bug/5280647 https://www.theregister.com/ai-and-ml/2026/07/29/closed-mode... Looks like the AI models either refused to work or produced obvious garbage. "GLM-5.2 is what finished the job for me, re-auditing K3's work and putting together an airtight case."