RipGrep musl binaries occasionally segfault during very-large searches

8/1/2026 at 5:05:50 PM

Heh, from the kernel patch: 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 which I indeed thought "that's an awful lot written to have been written by a human."

Looks like that thread is from...today!

by ndesaulniers

8/2/2026 at 4:52:33 AM

Looking at the function the addr value should always equal end but also it looks like on x86 this value is discarded in pte_free_tlb so maybe this is not the problem or I’m looking at a different version.

https://github.com/torvalds/linux/blob/master/mm/memory.c#L1...

Assuming addr is a virtual address it probably makes sense that pte_free_tlb does not need it.

https://github.com/torvalds/linux/blob/master/arch/x86/mm/pg...

by benmmurphy

8/1/2026 at 9:37:41 PM

That 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?

by vintagedave

8/1/2026 at 10:02:05 PM

Assuming 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

That said the AI was sort of directionality right... it identified roughly the right code.

by gpm

8/1/2026 at 8:24:04 PM

Thanks for the fun read.

by vaughands

8/1/2026 at 10:33:32 PM

Until ~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.

by gruntled-worker

8/2/2026 at 2:02:56 AM

If we know ‘where it came from’ in the sense that the author couldn’t even bother writing anything themselves, why should other people bother reading this deluge of nonsensical strung together words?

by doubletwoyou

8/2/2026 at 2:18:19 AM

That's my point, we won't bother reading it. We'll let agents read it. People will eventually stop getting ticked off at this stuff.

One exception: if the model is poor or on 'low' and that leads to a crappy report. That's the equivalent of shipping performance-critical code built with -O0 in the compiler analogy.

by gruntled-worker

8/2/2026 at 6:57:57 AM

This is a crappy report, that's what is being discussed

by krageon

8/2/2026 at 7:32:24 AM

Is there any indication that it was a mini/fast/older model, or on a low effort level? My read of the reactions above is "ugh AI", not "ugh AI on the cheap". Not a single poster mentioned model or effort choice. It seems more like the usual irritation at "AI slop".

If you just mean that the result was technically incorrect or off, that's probably true, but it doesn't affect my argument.

by gruntled-worker

8/2/2026 at 6:51:14 PM

At work I am sitting on a small pile of incomplete/wrong/missing-the-point bug reports right now, all generated by Opus 5 on High effort. Even under good conditions, LLMs are still wrong quite a lot, and confidently so. I can see why you think instant dismissal of LLM generated work is shallow, but I think it's at least as shortsighted to assume that when it creates poor quality work it must be an old/cheap model, bad settings, bad prompting, etc.

by monitron

8/2/2026 at 8:13:47 PM

I'm not arguing that it's great. I'm arguing that the future of human work in this area will be limited to dealing with the cases when it isn't great, i.e. the pile on your desk. Choosing the best model and highest effort is the due diligence required to minimize the size of that pile.

by gruntled-worker

8/2/2026 at 3:00:40 AM

It's less "can't be bothered to read through it because we know where it came from" and more "can't be bothered to read through it because of how word-salad it is"

Unless heavily prompted the written output is always so dense that you can barely understand it.

by RideOnTime22

8/1/2026 at 2:09:48 PM

I 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.

by Orphis

8/1/2026 at 2:34:02 PM

> I get why people don't bother replacing the default allocator from musl all the time (it's there, convenient).

ripgrep actually sets jemalloc as global allocator when built for 64b musl: https://github.com/BurntSushi/ripgrep/blob/435f59fc4b43af3ab...

by masklinn

8/1/2026 at 2:57:25 PM

That's good! But I wonder why it wasn't then enabled for that configuration or why the override wasn't "global" enough and the default allocator was still partly used.

by Orphis

8/1/2026 at 3:43:04 PM

Rust doesn't get to override musl internals. Ripgrep uses opendir, a POSIX library feature implemented in musl to look at er, directories. The stack trace suggests we blew up when Rust's std::sys::fs::unix::readdir internal detail called opendir, and it in turn allocated.

On Linux it would be possible for ripgrep to talk directly to the kernel via documented system calls without libc, but that wouldn't work on any other popular OS.

by tialaramex

8/1/2026 at 6:49:51 PM

> Rust doesn't get to override musl internals.

Is malloc not a weak symbol in musl? I would expect it to be overridable like it is with glibc. Or does ripgrep only override Rust's global allocator?

by VorpalWay

8/1/2026 at 7:34:06 PM

> Or does ripgrep only override Rust's global allocator?

That one, as you can see in the code linked above, it only does rust-level overriding as that was where musl's allocator was found to impact ripgrep (https://github.com/BurntSushi/ripgrep/commit/03bf37ff4a29361...)

by masklinn

8/1/2026 at 9:50:19 PM

Last time I checked (a while ago), it wasn't. You needed to compile musl and exclude a few files from the archive to then provide your own allocator.

Depending on the toolchain, I'm assuming you could use some tricks or hacks to make it work better, but the tooling I used (Bazel) did that automatically and I haven't bothered to look at the internals yet .

by Orphis

8/1/2026 at 5:52:20 PM

I assume it already doesn't work on Windows. At some point you have to define your compatibility boundary. And high performance often coincides with mediocre compatibility.

by inigyou

8/1/2026 at 6:04:17 PM

A good example is go. On linux you can use a from scratch image fairly easily because it only uses syscalls. But for windows or mac the moving target wasn't maintainable so they link against shared objects. Linus enforcing the don't break userspace rule is what made that possible. That definitely has tradeoffs. At some point relibc or something similar will allow the same (stably) for rust. But using posix as that compatibility boundary gets you a much larger set of OS and only occasionally has a performance penalty. Often, a posix api tuned to the kernel is more performant. Musl is an exception precisely because it makes an openbsd-esque trade of performance for simple small attack surface.

by galangalalgol

8/1/2026 at 6:15:21 PM

The Linux kernel defines syscalls as its stable ABI (note: there are also non-kernel ABIs on Linux, such as Wayland) while Windows defines the DLL calls as its stable ABI.

One isn't better than the other. Linux's approach allows binaries to be fully statically linked, which is a more predictable environment for binaries, but Windows's approach composes better, as every process loads DLLs and this allows for things like graphics drivers and COM to work more reliably. As things stand on Linux you can't use the GPU in a portable statically linked app, because the kernel doesn't define the semantics of dynamic linking.

by inigyou

8/1/2026 at 11:35:08 PM

TBF the GPU thing makes a fair amount of sense if you dig into it. It arguably falls entirely outside the kernel's domain of responsibility.

However given how fundamental GPU acceleration is (as well as various other pieces of dedicated hardware in various scenarios) it would be nice if the kernel defined some basic portable semantics for linking with important drivers. These could exist independently of libc and the rest of userspace purely as an optional fallback.

... or we could all just include a glibc compatible dlopen routine in our statically linked binaries instead of worrying about pedantic hypotheticals.

by fc417fc802

8/2/2026 at 9:05:02 AM

Yeah we could all just use glibc. You see the problem with that though right?

by inigyou

8/2/2026 at 2:45:42 PM

That isn't at all what I said. I'm pointing out that in reality there aren't 20 competing libc implementations each with a unique dynamic linking scheme used by the userspace of 20 corresponding linux distributions. Instead we have ... glibc. So if the kernel actually specified a common portable linking scheme to fall back on as a means to interface with critical drivers it would presumably adopt the glibc way of doing things for that purpose.

Also I did not say "just use glibc" but rather suggested to just include a secondary glibc compatible dlopen routine. Exactly as you would have to do if the kernel bothered to specify.

by fc417fc802

8/2/2026 at 2:50:41 PM

If the kernel wanted to force you to use glibc it would do so. We could get rid of the stupid hardcoded paths in PT_INTERP for example.

by inigyou

8/2/2026 at 2:57:41 PM

Right. Obviously. What I'm pointing out is that if the kernel decided to include dynamically linking to certain drivers within its scope (which it does not wish to do at present as you rightly point out) then it would need to specify a scheme for doing so. At which point glibc is all but a foregone conclusion.

So just pretend they did that and include a second dlopen routine and get on with life because at that point you're compatible with ~all major linux distros.

Far more pressing is a blessed filesystem path for where to find the things.

by fc417fc802

8/1/2026 at 8:44:41 PM

FYI, Windows's approach is better in some respects, like letting you avoid syscall overhead in some cases.

by dataflow

8/1/2026 at 10:14:48 PM

Notably, Linux has this too, but it's a special mechanism (vDSO) while on Windows it's just a normal function call with no difference from any other function.

by inigyou

8/2/2026 at 2:48:38 AM

Or in other words, they agreed the Windows approach was better, and tried to retrofit it (;

by dataflow

8/1/2026 at 8:27:56 PM

You can call into the kernel just fine in Windows. The fact you use a function call wrapper instead of a raw syscall is not really relevant.

Most Windows NT kernel functions take a buffer to use rather than allocating their own memory. Even many Win32 functions don't allocate (although there you have to be much more careful).

by ChrisSD

8/1/2026 at 3:34:27 PM

If you look at the sigsegv stack, the allocation comes from opendir which is in musl libc as well. The allocation override mechanism used in Rust doesn’t replace the allocator process-wide; it merely replaces the allocator Rust code talks to.

It does seem like ripgrep should probably avoid using opendir from libc if it allocates using an allocator with a global lock though.

by zeuxcg

8/1/2026 at 2:28:41 PM

It’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.

by vlovich123

8/1/2026 at 7:02:26 PM

It's maybe a kernel bug.

by karel-3d

8/1/2026 at 2:54:22 PM

Sure, 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.

by Orphis

8/1/2026 at 5:53:29 PM

Ah, no, the problem is that the bug exists.

Another, separate, problem, noticed by people investigating this problem, is that ripgrep on musl uses a serializing allocator in the hot path.

by inigyou

8/1/2026 at 3:19:13 PM

it'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.

by tripflag

8/1/2026 at 3:34:54 PM

I imagine there is no free lunch in the allocator space, but a series of trade-offs. Pick your poison on implementation which is going to be sub-optimal for some subset of use cases.

Without a hugely compelling reason to switch, going with the default is reasonable.

by 3eb7988a1663

8/1/2026 at 3:34:19 PM

ripgrep 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?

by Orphis

8/1/2026 at 4:16:08 PM

For context, the Python workload was a general-purpose fileserver with file indexing and image thumbnailing, largely IO-bound. Switching from mallocng to mimalloc resulted in a slight speedup (150% of baseline), but over twice the memory usage, going from 250 to 670 MiB, primarily for thumbnailing. Some pathological cases (libvips calling imagemagick to decode heif) was a 10x multiplier.

There was multithreading, and yes, mallocng visibly became a bottleneck beyond 5 threads. However already at 3 threads there was diminishing returns for both allocators, so this was not an issue in this case.

The speed gain was hardly noticeable in practice since the program was already plenty fast, but the additional memory usage was a very real inconvenience.

by tripflag

8/1/2026 at 4:55:37 PM

Is that memory increase seen in peak usage or average/idle usage?

For file servers, I could be willing to give up 350 MB of memory temporarily for large-scale indexing and thumbnailing operations if it doesn't happen often and makes the file serving/browsing more responsive.

by danudey

8/1/2026 at 5:39:06 PM

On the other hand, plenty of NAS/file server systems are going to have paltry CPU and memory. Running slower with a more modest memory foot print might be the only way to keep the system stable.

by 3eb7988a1663

8/1/2026 at 5:36:17 PM

libvips shouldn't be calling imagemagick for heif decode, it has a nice one built in. Unless you were using a very old libvips!

I've found jemalloc works best for long running libvips processes, fwiw.

by jcupitt

8/1/2026 at 3:17:31 PM

The way most programs achieve being fast is by re-using allocations. You don't need a fast allocator if you don't allocate. Nothing of what ripgrep does inherently requires frequent allocations.

by mort96

8/1/2026 at 5:51:16 PM

The ISO C definition of opendir() requires an allocation in practice because it returns a DIR* and it's bad practice for the library to arbitrarily limit how many of those an application has at a time.

Maybe a C library could preallocate several DIRs and only use the heap when those are exhausted, but this ripgrep use case (lots of threads running in parallel on a large tree) would still be likely to trigger that.

by entrope

8/1/2026 at 7:59:49 PM

There is no ISO C definition of opendir(), that's a POSIX thing.

But yeah, those DIR objects which opendir() returns a pointer to are probably some kind of heap allocated. But we're talking about a system call involving the filesystem here. The time taken by the allocator is gonna be dwarfed by the time spent in the syscall even with the slowest allocator.

Ripgrep reads through every byte of most files and matches it against a regex. That is the tight inner loop where you want to avoid allocations.

Not that you even need to call the C functions. I don't think ripgrep would gain anything from it, but the syscall to read directory contents just needs a file descriptor.

by mort96

8/1/2026 at 9:04:00 PM

I think ripgrep does avoid allocations in that innermost loop. That's why this report says all the crashes are associated with opendir() and its memory allocation: the opendir() call is outside of ripgrep's innermost loop but still runs often enough to trigger the race condition.

by entrope

8/1/2026 at 9:18:27 PM

And that's why musl's allocator's performance isn't a huge concern for ripgrep

by mort96

8/1/2026 at 9:45:29 PM

That's to be properly measured. Assuming that the allocator will not cause issues there is to be proven.

The application I recently improved by changing the allocator had a similar profile (a C++ include scanner) and thread parallel I/O functions had terrible performance originally with mallocng. Adding threads almost had negative value because of the contention.

by Orphis

8/1/2026 at 6:55:45 PM

There is a real tradeoff:

- The musl allocator is only slow with multi-threading.

- Almost all other allocators have trouble reclaiming memory when using multi-threading. This often results in multiples more RSS than single threaded or musl's allocator.

Agree with you on mimalloc. It can even be configured to be aggressive in memory reclaim at the cost of performance.

by searealist

8/1/2026 at 8:46:37 PM

We use musl+mimalloc by default for our entire production operating systems: https://stagex.tools

by lrvick

8/2/2026 at 12:26:54 AM

Interesting. Not sure if you are aware, but your toolchain looks nearly identical to another linux distribution.. You might have luck looking for patches there if you ever need them.

https://chimera-linux.org/about/#alternative-userland

by NewJazz

8/2/2026 at 10:29:49 AM

While we are building for a dramatically different threat model, we use quite a few of their llvm patches and are very thankful for their work, and alpine making llvm/musl a viable option for us.

by lrvick

8/2/2026 at 12:56:53 AM

this use of musl's mallocng actually lead to the discovery of a kernel bug, thanks to its hardening. without it, this might have gone unnoticed for months, silently corrupting memory in the meantime.

by potus_kushner

8/1/2026 at 12:44:20 PM

The analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis.

by hyperpape

8/1/2026 at 2:20:01 PM

I tried reading and gave up at the "Headline"...

Quoting from the bug analysis:

>Headline. The crash is real and reproducible. With musl instrumentation we pin the in-process mechanism precisely: a thread's own store to a freshly- faulted anonymous page becomes invisible to that same thread's reload ~10 instructions later, because the page's backing is replaced mid-function. A pagemap read at the instant of the fault shows the backing is the kernel's zero page. A captured core dump confirms the crash site with matched virtual addresses. The mechanism localizes to the interaction between the per-VMA-lock anonymous-fault fast path and a concurrent munmap's TLB shootdown. A source-level review of Linux 7.0.12 identifies a specific race in that interaction, and a git comparison across v6.19/v7.0/v7.1/mainline identifies the v7.0-introduced change on the munmap-teardown side that widens it.

"a thread's own store to a freshly- faulted anonymous page becomes invisible to that same thread's reload ~10 instructions later, because the page's backing is replaced mid-function." -> ??? What's a "backing" of a page? Freshly-faulted? Fresh fries? "~10 instructions later"?

"A pagemap read at the instant of the fault shows the backing is the kernel's zero page." -> Backing?

"The mechanism localizes to the interaction between the per-VMA-lock anonymous-fault fast path and a concurrent munmap's TLB shootdown." -> How can a mechanism "localize"?

And more.

This is... words strung together. Nothing more. I wonder how people read and make sense of this.

In case people have forgotten what real technical writing looks like, here's a sample (I am not the author): https://yifan.lu/2019/01/11/the-first-f00d-exploit/

by smukherjee19

8/1/2026 at 2:44:06 PM

I'm becoming increasingly allergic to the performative writing of LLMs.

The worst part is how compulsive LLMs are at writing like this. Like the system prompt instructs it to "reason" and like a college Sophomore it pontificates and quotes Nietzsche to fein intelligence and orginal thought.

by cerved

8/1/2026 at 3:05:04 PM

I love LLMs for technical stuff, but their writing style is horrendous. I also think it's bad form to waste fellow humans' time with walls of generated text.

I understand that it's probably a hard technical problem to get models to conform to a style without sacrificing performance in other areas. But I really wish AI companies would spend more effort getting them to write in a neutral, concise way and not like a middle manager on 80mg of Adderall.

by fasterik

8/1/2026 at 3:09:02 PM

> But I really wish AI companies would spend more effort getting them to write in a neutral, concise way

I wonder if this would make it harder or easier to detect whether the underlying meaning of the writing is bullshit.

by Retr0id

8/1/2026 at 3:12:07 PM

Definitely easier. It's the same for humans. You can tell that someone has little of substance say when they cloak everything in big words and elaborate metaphors.

by fasterik

8/1/2026 at 5:59:03 PM

Good old sesquipedalian loquaciousness.

by inigyou

8/1/2026 at 5:54:38 PM

This is a pretty clear analysis if you are a kernel developer.

> a thread's own store to a freshly- faulted anonymous page becomes invisible to that same thread's reload ~10 instructions later, because the page's backing is replaced mid-function

A result of a machine instruction to store something in RAM got erased, when the same thread attempted to load it ~10 machine instructions later. The reason is that the physical RAM page backing that particular virutal page got replaced while the thread was running.

The fault happens in the fast path for anonymous (i.e. not backed by files on disk) pages, in the granular per-VMA (virtual memory area) locks.

> "A pagemap read at the instant of the fault shows the backing is the kernel's zero page." -> Backing?

Yes, it's typical kernel terminology. "A backing page" or a "backing file".

> This is... words strung together. Nothing more. I wonder how people read and make sense of this.

There's nothing wrong with this description. It's just written for kernel developers. It needs to be expanded and explained for people who are not.

by cyberax

8/1/2026 at 3:00:45 PM

"backing" is a Virtual-Memory related term. With virtual memory, you can have memory areas (called "pages") that are not really there but only present in the metadata (the "book-keeping", so to say). The first time, someone actually tries to access this page, that access is interrupted ("faulted") and the kernel gets a say in what should be done to that piece of memory (i.e. load it from disk somewhere, reserve actual physical memory and fill it with zeroes, or crash the process).

The "backing" refers to the physical memory that might or might not be present for every "virtual" piece of memory that your program has allocated.

"Freshly faulted" means that a page of (virtual) memory has just received a "backing" by the process above and is, thus, very fresh in physical memory (even though the virtual memory might have been allocated much earlier)

"~10 instructions later" refers to the assembly- (machine-) code, which, contrary to a high-level language like C, usually has long(ish) sequences of rather simple "instructions". 10 instructions is a rather short interval in assembly code.

As for the "localize", the term used is actually "localizes to" which I read as "turns out to be located in" (probably just a bad English translation by the original author)

While this whole summary reads a bit weird, I don't think it is necessarily the result of an LLM, it's probably just that someone who is rather inexperienced at writing up technical summaries did it.

by dark-star

8/1/2026 at 6:08:53 PM

I understand all the words in it and follow the argument, but it's still bullshit in the technical sense of being written by someone who wants to sound authoritative but doesn't ultimately care if they are right or wrong.

The write-up should have been about five paragraphs: (1) "The script at https://... generates a tree with X million files taking 20 GB total. Running ripgrep 1.2.34, compiled with musl, on my Threadripper 9876 as 'rg ...' crashes about a fourth of the time. With glibc, it does not crash." (2) "This appears to be a bug introduced by commit abcdef1234 in some_vm_call() that allows a race between [...] such that user space can see a corrupt whatever." (3) "The sequence of operations that causes this is: (show two or more kernel threads with lines interleaved to explain the bug)". (4) and (5) as needed to elaborate on those three core points.

But the actual post is long on (fluent) speculation and short on reference to actual code. That's a large part of why it's offensive slop.

by entrope

8/1/2026 at 3:43:01 PM

So the theory is that the page is faulted in, then somehow evicted within 10 instructions, then re-faulted in somewhere else, resulting in writes not making it to the page? That would need a context switch and another page fault to happen in short succession. But the context switch to evict the page back out would have necessitated pending writes to have finished. Nothing actually makes sense with that explanation.

by yuliyp

8/1/2026 at 5:40:08 PM

The way I read it was that it wrote to a page and then did a read on that page within 10 instructions and that was not enough time for the memory system to have gone through the process of creating the page backed with real memory and that the timing bug widened in Linux 7.0 such that more things like this exposed the bug. Or there was flapping in the TLB for some reason, or the locking wasn’t correct, or whatever else that the kernel devs will figure out was the cause.

I’m guessing it wrote to a page and read back zero page as the memory was in the mist of being allocated.

by sroussey

8/1/2026 at 6:38:52 PM

But the write should have triggered a page fault immediately in that case, and should have been blocked on the page being actually allocated before resuming.

by yuliyp

8/2/2026 at 12:20:44 AM

yes, i went back and re-read the report. an immediate read 1 instruction later works, but 10 does not. the page marked dirty but pointing to the zero page. some context flapping i assume

by sroussey

8/1/2026 at 5:13:10 PM

Sounded like a race condition causing a correct new mapping in the TLB to be cleared away by mistake, reverting back to the zero page mapping it was before.

by MBCook

8/1/2026 at 6:00:26 PM

Except incorrectly flushing the TLB would merely be a performance bug.

by inigyou

8/1/2026 at 4:03:25 PM

Thanks for the explanation. I should have looked up each term a bit more.

So "backing" is the underlying physical memory the page maps to.

So if I were to make sense of that piece of slop, is this what it would be?

"In one thread, a page fault happens during a store operation. The physical memory address is the proper address, which is immediately (around 10 assembly instructions later) replaced by the 0x00000000 memory address by another thread due to race condition, resulting in a crash when the original thread tries to read that page again."

by smukherjee19

8/1/2026 at 5:18:08 PM

The first thread is the user program, the other thread is the kernel doing things on another core.

Reading from the zero page is legal, that doesn’t cause it to crash. The crash is because of a logic “bug” in the program where the zero it reads back causes some other issue in the program.

I say “bug” because it’s clearly impossible without the kernel messing up. It just stored a non-zero value there.

by MBCook

8/1/2026 at 6:10:14 PM

Nope. It's more complicated. The store operation does not need to trigger the fault, it can happen for other reasons.

What happens here is a bug in munmap() that happens in another thread. It corrupts the TLB, for a brief instant replacing the correct page.

So that the virtual memory page that the crashed thread tried to read its RAM, it gets replaced by the special zero-filled physical page. The kernel uses this zero page as an optimization when it needs to create a region of data filled with zeroes, so it can just map one physical page over the entire range.

It's a really low-level bug that just requires a lot of specialized knowledge just to explain. A better write-up is certainly possible but needs to have a lot of explanations to make it understandable.

by cyberax

8/2/2026 at 12:35:00 AM

The biggest problem I find with AI writing is that it overemphasizes everything - making absolutely everything it does sound incredibly important and critical. This is very, very exhausting for humans to read, and I would not be surprised if this lack of emphasis differentiation hurts AIs in the long run too -- emphasis being a useful signal for determining what is more important or novel.

Actual technical writers know what to emphasize and what not to, based on the expected audience; good ones will gently add hints to expand that audience without compromising technical accuracy or content.

by nneonneo

8/1/2026 at 4:09:10 PM

This is technical writing for kernel developers who already know how memory management works. If you want to understand it better, you should study up on the x86 MMU and the kernel memory management subsystem. I'm not a kernel expert but I found it pretty understandable, so I'll try to explain it.

MMU: The memory management unit, part of the CPU designed to allow an OS kernel to flexibly control how memory addresses used by a program map to physical RAM.

Page: A 4k region of memory addresses.

Anonymous: The page is just regular old memory used by a single process for general purposes, it's not part of e.g. a memory-mapped file.

Backing: The memory corresponding to a page. The kernel can direct the MMU to map any page to any part of RAM, or delete the mapping entirely.

Zero page: The kernel keeps a single 4 KB page filled with zeros (the "zero page").

Page fault: An error that occurs when you try to write a page that's not present, or write to a read-only page. Some page faults are normal and expected by the kernel, they support features like swapping, memory-mapped files, etc. Such "expected" page faults are invisible to your program. (On the other hand, an unexpected page fault occurs when your program just straight-up accesses an address it's not supposed to, which will end your program with a SIGSEGV signal -- an all-too-familiar experience for a C programmer.)

When you allocate say 4 MB of memory, the kernel simply sets it to 1k read-only copies of the 4 KB zero page. Then when your program tries to write to a page, it faults. The kernel handles this expected fault by assigning that page an individualized memory region. If a program allocates a lot of memory, it's only assigned memory for what it actually uses, when it first uses it. This is an optimization: Every program that allocates more memory than it needs is wasteful, but the kernel can recover that waste by not backing the allocation with memory -- the program has to prove each page is needed by writing to it.

Store to a freshly-faulted anonymous page: The program stored data to its own memory, which caused an expected page fault.

> becomes invisible to that same thread's reload ~10 instructions later

The thread fairly quickly tried to read the data from the same place in memory it had just written to. It doesn't get the same data back. This is a major problem that causes the program to malfunction and crash.

> A pagemap read at the instant of the fault shows the backing is the kernel's zero page

The expected fault occurred because the program tried to write to an address that was mapped to the zero page, probably because it's the first write to freshly allocated memory. (This rules out other reasons it might be faulted, e.g. the page had been swapped to disk.)

> concurrent munmap's TLB shootdown

The page table is big and slow so the CPU caches parts of it in an area called the TLB (translation lookaside buffer). munmap is a kernel function that removes the backing for an address region. Since munmap changes the mapping, it has to inform the MMU the relevant part of the TLB is no longer valid.

> per-VMA-lock anonymous-fault fast path

This is what the kernel does when the program first writes to a zero page. Saying it's the "fast path" implies there's some (slow) special case handling in the kernel code, but the bug doesn't trigger any of the special cases, we're in the most common case, which the kernel code tries to handle as quickly as possible because it has measurable impact on performance. I would guess per-VMA-lock has to do with how the kernel synchronizes this code (a "lock" is a basic synchronization primitive, you should be familiar with it if you do any kind of multithreaded programming).

> The mechanism localizes to the interaction between the per-VMA-lock anonymous-fault fast path and a concurrent munmap's TLB shootdown. A source-level review of Linux 7.0.12 identifies a specific race in that interaction

The mechanism: What's actually happening to cause the program not to be able to load data it just stored in memory.

Localizes: The cause of a problem like this is a needle in a haystack -- it could be caused by the program, the kernel or the hardware. The analysis has narrowed down the haystack to a specific part of the kernel code.

Race in that interaction: Two parts of the kernel code, (1) The kernel code for munmap and (2) the kernel code to handle a program's first write to the read-only zero page for a fresh allocation. These two parts work fine individually but the problem occurs when they both try to change the page tables / TLB at exactly the same time. This is quite a small, specific haystack compared to "somewhere in the program, kernel or hardware" we started with.

by csense

8/1/2026 at 5:11:50 PM

Excellent explanation.

I’ve been reading the LWN kernel page for >20 years so I’ve picked up almost all the jargon and could understand it pretty decently.

You’re dead on in saying it was written for that specific audience, not anyone more “normal”.

by MBCook

8/1/2026 at 7:02:41 PM

I understood the jargon just fine. The writing is still terrible and way too verbose.

by kelnos

8/1/2026 at 6:31:18 PM

Thank you for taking the time to write that out. I found it incredibly helpful, just wanted to let you know I appreciated it!

by freedomben

8/2/2026 at 2:27:05 AM

OP here. Thank you so much for taking the time to write it!

This is so much easier to understand, and I also learnt a few things along the way, like the zero page mechanism, munmap having to notify the MMU about the invalid TLB and more.

Really appreciate it!

by smukherjee19

8/1/2026 at 2:26:21 PM

Agreed, the article you linked is a great example of clear, understandable, detailed technical writing.

by newsoftheday

8/1/2026 at 2:26:18 PM

fwiw "backing" is standard jargon in this context, and "freshly faulted" is phrasing you'll see in Linux source comments. The writeup as a whole is indeed slop, though.

by Retr0id

8/1/2026 at 4:01:34 PM

I don't care if the cat is black or white, so long as it catches mice.

Translation: if this nails-on-chalkboard LLM spew identifies a kernel bug, which is then patched, its aesthetic qualities do not interest me in the slightest.

by samatman

8/1/2026 at 4:08:31 PM

Unfortunately, the kernel bug would need to be understood to be patched, and the developed patch itself would need to be reviewed before being accepted, which seems... very hard, to put it mildly, using the nails-on-chalkboard LLM spew report.

by smukherjee19

8/1/2026 at 6:55:55 PM

Yes, the word 'if' was in that sentence.

The only people who have a need to judge the quality of the report (not aesthetically, I mean) are those few who know enough about the subsystems of the kernel it implicates to do something about it.

My point: does it lead to a bugfix? Good. No? Bad.

Do you have an answer to that question? I believe it's a bit early, no?

by samatman

8/1/2026 at 6:01:14 PM

At least it is a report. It says hey, there's a bug vaguely like this in this general area. Not too dissimilar from the average user report.

by inigyou

8/1/2026 at 4:13:11 PM

[dead]

by Retr0id

8/1/2026 at 1:41:01 PM

    The overflow would still overflow; the use-after-free would still use after free; a musl mask race would still race.

Hilarious. Apart from the computer poetry, the conclusion seems to be “it’s something in Linux 7.0 + musl 1.2.5”, although the only reproduction is still on the same physical Threadripper CPU and only sometimes when heavily exercised, so it hasn’t really ruled out a hardware issue.

by fwlr

8/1/2026 at 3:04:19 PM

The computer seems to have identified source code to blame though? Unless of course it hallucinated which there’s always a non zero chance of

by internetter

8/1/2026 at 5:19:16 PM

It’s the kernel. Nothing a user space library can do should ever be able to call this.

Just happens to be that the musl code is able to hit this and other code isn’t for some reason.

by MBCook

8/1/2026 at 5:59:36 PM

> It’s the kernel. Nothing a user space library can do should ever be able to call this.

I don't follow. An application might see this kind of crash if it has a bug causing it to access a page while another thread is mapping or unmapping that page. That would be a bug in mallocng, musl or ripgrep. Or, as someone else mentioned, it could be bug in the processor's virtual memory logic that has the same effect. Why do you say it can only be a kernel bug?

by entrope

8/1/2026 at 6:12:20 PM

It got traced to a race condition in munmap() in the kernel. The inefficient musl allocator simply triggers it more easily.

by cyberax

8/1/2026 at 7:14:15 PM

It got arm-waved to a race condition in munmap(). Claude (or a distill of Claude) didn't identify a race, it just convinced itself that was the cause.

by entrope

8/1/2026 at 9:15:25 PM

Andy Lutomirski seems to think that it is a bug: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-...

I looked at the explanation, and it seems to be at very least plausible. The kernel version bisection also lines up. We'll see if the proposed patch fixes this.

by cyberax

8/1/2026 at 6:01:44 PM

User code calls kernel code all the time - just not by its address.

by inigyou

8/1/2026 at 4:23:06 PM

I mean, we are deep into reading tea leaves at this point, but what it seems to have identified is the source file that changed such that this issue can now occur. My gut instinct is that the changed code is still valid and correct, but it exercises the hardware in a different or a more intense way.

by fwlr

8/1/2026 at 2:03:31 PM

Reading an AI-generated bug report is awful.

by p0nce

8/1/2026 at 2:11:47 PM

Stopped after

> Headline. The crash is real and reproducible.

by oxidant

8/1/2026 at 2:23:09 PM

I really hated that kind of language, feels like speaking to a motivator

anyway it's slop, can sense it even before i started reading

by BetterThanSober

8/1/2026 at 2:49:41 PM

The worst thing is that I know there's something interesting in there but I'm too arsed to take the time and decode what data the author must have used to generate that text.

by bentcorner

8/1/2026 at 3:09:35 PM

Exactly, it would be so much better if they shared the prompts instead of the output, at least then we'd be able to make some sense of what they were thinking about.

by 27183

8/1/2026 at 3:56:59 PM

Unfortunately the prompt may have been something like "investigate this bug and file an issue when you think you understand what's going on". The "better just to share the prompt" heuristic falls down when the actual underlying intellectual work was also done by the machine.

(Feel free to pretend that I used some phrase other than "intellectual work" if you dislike seeing it used to describe something done by AI.)

by gjm11

8/1/2026 at 4:44:25 PM

Yeah in that case just closing it and moving on would be better IMO. A sufficiently large fraction of the time the issues with vibeslopped code and/or analysis are bad enough once you start digging into it that it's not worth spending time on. My heuristic would be to simply ignore contributions derived from lazy prompts. I don't think there are very many healthy babies in that bath water.

So having the prompt available would be useful even in the degenerate case.

by 27183

8/1/2026 at 6:04:27 PM

How so? We can give the same starting point to the same AI and ask it to investigate too.

by inigyou

8/1/2026 at 3:13:22 PM

Get your own AI to give you the tldr :/

by momocowcow

8/1/2026 at 3:42:42 PM

How does that help anything?

by Banditoz

8/1/2026 at 6:04:52 PM

Makes the stock market go up

by inigyou

8/1/2026 at 3:38:58 PM

Maybe it's not going to get any better. LLMs were trained to do two things:

- Mimic human language (and logic, since that's part of what we express with language). This includes code written by humans.

- Write code to solve problems. The figure of merit here is solving the problem, not reproducing anything human.

I'm not an expert on LLMs, but it's not obvious that the human reasoning they are fitting in the first case is going to be anything like the problem solving required in the second case. It was trained to get itself out of a problem, not to do it in a way that a human would relate to.

And we're already running out of human data to train on, while synthetic data has no limit. Bug reports in the future might amount to "fix this because then I'll get a cookie".

by dguest

8/1/2026 at 5:59:18 PM

A lot of it is that AI can talk with different "voice" but that requires giving it cues, and that costs money and expands context, so people that don't know, don't, and those that do have no incentive to

by PunchyHamster

8/1/2026 at 1:08:34 PM

Nice sleuthing, nonsense explanation. An extra TLB flush is never an error. (The CPU is free to flush whenever it feels like doing so.) The error seems to be that somehow a zero-page PTE was present when it shouldn’t have been.

This sounds to me like either (a) a complex race involving a CPU migration at an awkward time or (b) a bug in the zap path transiently exposing wrong PTEs.

Also, I don’t think the zero page has pfn zero.

If I had to throw a dart, I would guess that direct page table zapping is allowing a CPU to read through a higher-level-paging-structure cached entry to a table that has been freed and reused. Yuck. I’ve debugged one of these before.

by amluto

8/1/2026 at 1:40:55 PM

The part that doesn't make sense to me is that trying to read through a zeroed PTE should be an immediate segfault, not something that reads back zeroes (regardless of whether the zero page is pfn 0 (it isn't)).

I think the broad strokes are that, due to bad locking in the kernel, mmap() returns a VA that a concurrent munmap() is still in the middle of unmapping. The specifics beyond that seem murky/speculative/inconsistent.

Alternatively, it could be a hardware bug, since afaict it's only been repro'd on one hardware config. (I know there are a bunch of ARM cores with erratas around TLB invalidation)

by Retr0id

8/1/2026 at 2:02:55 PM

After more digging, I bet it's a paging-structure-cache flush bug. I've debugged these before, and they're nasty, hardware dependent, hard-to-reproduce issues. Looks like the code that the AI flagged might actually be wrong, but not for the reason that the AI thought.

https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-...

by amluto

8/1/2026 at 2:11:45 PM

> Alternatively, it could be a hardware bug, since afaict it's only been repro'd on one hardware config. (I know there are a bunch of ARM cores with erratas around TLB invalidation)

Which raises the question of whether any HN readers have successfully reproduced this?

I've just tried (using his file generation script and the official rg binary he links) on a Ryzen 7 5800X / 7.1.5-arch1-2 with sufficient free ram as the github issue suggests, and still no segfaults after 10 minutes.

by gpm

8/1/2026 at 2:33:46 PM

I have never, in my entire personal history of kernel development, successfully reproduced a paging structure cache bug. I have stared at these sorts of bugs and puzzled them out.

With this particular issue, if my theory is right, it will depend on all manner of microarchitectural issues, possibly address spare randomization, context switch and migration timing, random speculative accesses that pull things into cache, etc. Yuck.

by amluto

8/2/2026 at 12:11:46 AM

Bugs due to cache state are absurd. In the classical sense of the word.

When Bruce Dawson investigated a bug in the Xbox 360 cpu, the offending instructions didn't even need to "execute" in order to crash the system.

[0] https://randomascii.wordpress.com/2018/01/07/finding-a-cpu-d...

by dwattttt

8/1/2026 at 1:20:33 PM

The explanation is obviously written by an AI agent.

by inigyou

8/1/2026 at 7:00:10 PM

Not really. It's typical rambling LLM slop-analysis. It may be a correct analysis (I couldn't stomach reading it in detail), but it's a pain in the ass to read. A human doing the same analysis would have written something 1/5th the length.

by kelnos

8/1/2026 at 12:45:28 PM

soulless unreadable AI slop

by yawndex

8/1/2026 at 12:47:10 PM

I 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.

by hoppp

8/1/2026 at 12:57:56 PM

> It doesn't make sense for the reader to spend more energy than the writer spent on creating it.

Great way to summarize cultural "economics"

Couldn't put the words on this pattern but sometimes all I care about is that someone cared about.

by agumonkey

8/1/2026 at 6:00:10 PM

I usually go for "If I wanted LLM answer I'd ask LLM instead of reading your answer/article/content"

by PunchyHamster

8/1/2026 at 8:22:04 PM

But it goes beyond this. The whole 2020s era is about cheap ways to do anything and be able to stream it to billions of people. Yet I feel no density in the work because there was no energy spent on it.

by agumonkey

8/2/2026 at 7:16:01 PM

It's proof of work applied to social interactions. The father back in history you go the rarer I imagine the root problem was.

There's a similar conundrum with gifts. When everyone is able to order approximately anything from anywhere in the world via the internet exchanging gifts begins to feel like a bizarre ritual meant only to transfer money to businesses.

by fc417fc802

8/1/2026 at 1:22:57 PM

energy might be the wrong metric, plenty of energy was wasted spinning up that LLM.

by serf

8/1/2026 at 2:10:12 PM

Yeah but the thing is that someone tries to waste time of humans.

This is why I hate "interacting" with bots, scripts or AI/LLMs. It just wastes my time, again and again and again. Oddly enough not all humans understand that. About two months ago, a german developer involved with ffmpeg, spam-slopped their mailing list with AI (it was an AI proposal for some change to ffmpeg in the future). He still does not understand why that is a problem.

by shevy-java

8/1/2026 at 6:07:36 PM

I think it was GZDoom where the absentee project owner suddenly came back, pushed a bunch of nonsense AI comments, so the entire actual development community just forked it again and left him to play in his sandbox? Now it's UZDoom.

Something similar happened with PolyMC to PrismLauncher but that wasn't about AI, it was an absentee owner who came back and deleted everything he said was woke.

by inigyou

8/1/2026 at 12:49:47 PM

PoC||GTFO, if it reproduces, it's valuable

by wild_pointer

8/1/2026 at 2:03:56 PM

In the history of Linux that I'm aware of (and I've been nose-deep in this stuff on and off for quite a while), these issues are almost never debugged because they're reproduced -- they're debugged because someone who actually understands the messy interactions of the code and hardware in question thinks about them.

A reproducer might not actually be useful because there is basically no way short of fancy hardware tracing to figure out what the reproducer is doing.

by amluto

8/1/2026 at 12:58:24 PM

Then post whatever notes were fed into the AI instead. The verbosity and self-congratulating add negative value.

by smallerize

8/1/2026 at 1:01:32 PM

What 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.

by im3w1l

8/1/2026 at 3:27:37 PM

> What will you do when the prompt was "Figure out the bug and write a report for me".

The rational choice would be to cut your losses and stop reading at that point. Once you realize zero effort went into the prompt, there's no longer any reason to read the output. The age old truism still applies: garbage in, garbage out.

If you think it's worthwhile, close the issue with a comment: "please rework this and show your work next time". Otherwise just close it without commenting and move on.

by 27183

8/1/2026 at 4:15:26 PM

"it will be"

Trying to figure out what to do based on possible future scenarios has a place, but not here when we are talking about a concrete present problem.

by krupan

8/1/2026 at 6:08:21 PM

Prompt an AI to figure out the bug and write a report, of course. If that is actually useful.

by inigyou

8/1/2026 at 2:32:02 PM

It didn't figure out the bug: the report is largely nonsense. It merely did a bad impression of having figured out the bug, by stringing together several observations into something superficially resembling a narrative. Providing those observations without the gibberish framing might be useful.

by wizzwizz4

8/1/2026 at 3:07:49 PM

The parent's point still stands. In many cases it will have figured out the bug. In many cases it will have produced a small, clean, deterministic reproducer.

In my daily work I see these cases. It does help that the bugs that are filed contain a test case and some analysis by the agent.

It would not help to get ten identical bug reports all saying "I asked my agent to find a bug by prompting it with "find a bug and produce a test case". It found a nasty bug and a really nice reproducer. I'm not including its output here. Good luck!"

by derdi

8/1/2026 at 1:04:02 PM

That I agree with (not instead, in addition)

by wild_pointer

8/1/2026 at 1:21:11 PM

They have a PoC, we're arguing about the LLM-generated slop explanation of the PoC.

by inigyou

8/1/2026 at 2:54:20 PM

Is it actually reproducible though and do I want to chase and reproduce something that had no human touch? Do you?

by BetterThanSober

8/1/2026 at 4:57:42 PM

If it's an actual bug, I hope the Linux devs will. It impacted a human, and it's a bug regardless of human or non-human touch. Of course, looking at a bug is a matter of priority, always has been.

by wild_pointer

8/1/2026 at 12:56:04 PM

Why is it unreadable? I actually find LLM bug reports/breakdowns to be far more detailed and concise that classical human written ones. If you read the linked repo it clearly goes it depth where the bug was found, how to reproduce it (and in depth). Most disclosures that are human written don't do this at all, they barely even tell you _how_ to reproduce the bug. Just look at the "3.3 The self-store tear", the LLM clearly describes exactly what went wrong, so you can verify it by hand.

by rfgplk

8/1/2026 at 2:45:52 PM

I'm reasonably confident that the author has a reproduction case on their hands. That's easy to directly verify. I'm way less confident in that long and rambling analysis. As fwlr observes, it's not clear that this has been reproduced off the original machine: https://news.ycombinator.com/item?id=49134357

If it is the case that the original machine has an intermittent hardware fault, that analysis is exactly what I'd expect of an current AI. Voluminous and confidently wrong. Also interesting that the AI itself doesn't note this... having been biased by the conversation to consider kernel bugs, in the "cross-machine data" [1] it blames the kernel and doesn't appear to consider alternate explanations.

It doesn't get mentioned much around here but one major issue with AIs today is that they fall into tunnel vision very easily and often need some help getting out of it. There's a structural reason for tunnel vision built into their context limits, and there's also situations like this, where if you bias them in a certain direction they can get monomaniacally stuck on it. You can also see it where they do things like try to do something on your system like view a certain file, then if for some reason they fail due to permission issues, if you don't stop them they'll go absolutely insane trying different ways to access the file, rather than just stopping and saying "Hey, I need help". Even if you prompt them directly to do that, it only helps, it doesn't fix the issue. I suspect the RHLF training they get to be better coding agents reinforces this behavior because in the coding quality tests they're rewarded for one-shotting all the various benchmarks, where that "bull in a china shop" approach works better than giving up. But I'd actually like them to give up a bit more often. I've had the same problem with some particularly go-getting junior devs, too... I appreciate the ambition and I look forward to harnessing it in other situations but I'd rather you didn't spend five hours to create a terrible work around to something I could have gotten you in two minutes. For the junior dev, it's OK, they take the feedback and adjust... the AIs never adjust.

[1]: https://github.com/dfoxfranke/ripgrep-3494-analysis#6-cross-...

by jerf

8/1/2026 at 3:06:40 PM

That reminds me of one ticket I had to handle. It was generated by an agent from a customer report and the different hypotheses were wrong. Also a huge wall of text.

The issue was alongside the API boundary (timezone shenanigans) but the agent invented a lot of reasons with reasonable looking arguments because of the tunnel vision that there should be something wrong inside the project.

by skydhash

8/1/2026 at 4:10:55 PM

Not enough people are going to see this comment. It's so true!

by krupan

8/1/2026 at 1:09:28 PM

Because any writing needs a core intent they need to convey, which you can summarize down to according to the audience and why it should be important to them. Kinda like the same idea of elevator pitches, “explain like I’m five” and tactical reports when there’s a time constraints.

You got none of that here. It’s just realms of text.

by skydhash

8/1/2026 at 1:15:20 PM

Maybe the person writing the report isn't an expert in this domain or doesn't have the time to commit to it? From my point of view as long as the information is accurate and reproducible, it's valuable.

by rfgplk

8/1/2026 at 2:11:39 PM

> Maybe the person writing the report isn't an expert in this domain or doesn't have the time to commit to it?

Then maybe that person should not do it? At least until they find the time?

by orphea

8/2/2026 at 6:39:38 AM

So just spend a few years learning to be a kernel developer so they can report a kernel bug that is crashing their user program?

That is so open source it’s not even funny.

by NetMageSCW

8/2/2026 at 7:24:39 PM

No, just omit the rambling in favor of a "sorry I lack the expertise to really dig into this, here's a reproducer and I'm here if you have any questions I'm able to help with".

Your bizarre overly literal take is so peak HN that it ... okay I admit it's still funny to me.

by fc417fc802

8/1/2026 at 2:19:56 PM

[dead]

by fr2029

8/1/2026 at 2:54:11 PM

The other part is that almost no one would have the energy to spend hours instrumenting and rebuilding musl, reading the kernel mm code, and thinking hard about how they might interact.

Claude is probably not right about the root cause here and is probably bsing, I agree. But it's collected enough raw data to point some expert humans at the right interaction. I'd take this bs bug report and start asking Claude some questions that would guide it to a more plausible actual answer, but that requires a little more experience in kernel development.

by neerajsi

8/1/2026 at 3:15:10 PM

> The other part is that almost no one would have the energy to spend hours instrumenting and rebuilding musl, reading the kernel mm code, and thinking hard about how they might interact.

Maybe because it isn’t needed. That’s the reason we have experts and professionals, because it’s more economical to use them than for everyone to start from scratch. It’s easier to go to a mechanic shops to fix my engine block than to try to do it myself. I’ve heard that a lot of shops charge more if you said an amateur try to fix things first.

It’s a lot of stuff, but that’s not how you experiment for an hypothesis.

by skydhash

8/1/2026 at 5:43:07 PM

I've been a systems dev for a long time and have debugged many such tricky issues before. Even on teams of experts, this type of issue would take someone really capable weeks to track down, especially because the repro environment is hard to obtain. And the opportunity cost of doing this type of work for a rare bug is high, since you may never get to an answer and have burned a lot of time. So in practice I solved most of this type of issue early in my career before I had a family and before I had higher level work to do.

The ai doesn't have the same incentives as a human. It can also be applied to the repro where it exists.

Your mechanic analogy is a bit inapt. Sure they're experts and can replace your engine much better than you can. But tracking down a non obvious system level bug like this one is much less repeatable and much harder because the problem has already been filtered through a lot of reviews and testing. As a system becomes mature, the bugs become harder and harder individually to track down.

by neerajsi

8/1/2026 at 6:23:56 PM

> Even on teams of experts, this type of issue would take someone really capable weeks to track down, especially because the repro environment is hard to obtain.

> As a system becomes mature, the bugs become harder and harder individually to track down.

What I'm talking about is that experts knows the system mechanism more than amateurs, so any hypothesis and experimental setup will be more focused and thus more economical than any amateurish one. And there's the matter of knowledge not present in some docs or other forms, such as past experiences.

Even with LLM tooling, we've seen the rises of harnesses and helper tools instead of relying on generation for everything. Who would you trust to build such harness, a domain experts or some random guy off the street?

by skydhash

8/1/2026 at 1:26:39 PM

> From my point of view as long as the information is accurate

That's the trillion-dollar catch, isn't it. LLMs love to write 30 paragraphs about some plausibly-correct-sounding explanation that is just as likely to be completely fucking wrong as it is accurate. The bug might be real, but that doesn't mean this analysis is accurate, and trying to figure out where the LLM went off the rails can be a nightmare. If you can actually understand the bug, it doesn't take 30 paragraphs to explain it. I would throw this bug report into my junk bin if I were on the receiving end of it, and I say that as someone who will spend days troubleshooting any issue a user will help me diagnose even if it only happens on their machine.

by applfanboysbgon

8/1/2026 at 2:24:11 PM

I'd rather read walls of AI slop than soulful meatbag bickering. Just because you might have a soul and intent doesn't mean you do anything useful with it. All I see is the intentful invention of more reasons to fight over arbitrary crap.

by epixu

8/1/2026 at 3:00:40 PM

[dead]

by lp196

8/1/2026 at 1:19:02 PM

Then where’s the lie in “soulless AI slop”?

by mi_lk

8/1/2026 at 12:58:33 PM

[dead]

by walk12111

8/1/2026 at 12:59:00 PM

I had the opposite reaction. Clear, detailed, well-organized. Pretty close to the ideal writeup.

by anorwell

8/1/2026 at 1:49:01 PM

Could you explain it in your own words? (I tried myself, and quickly discovered that it is incoherent)

by Retr0id

8/1/2026 at 2:42:45 PM

Perhaps you are talking about the ripgrep issue itself, which is fine. The others are talking about the linked analysis, which is not.

by munch117

8/1/2026 at 2:12:31 PM

Hi Claude! :wave:

by orphea

8/1/2026 at 1:56:04 PM

What? it is mostly literal nonsense. Moreover the last paragraph where they say it only reproduced on one machine just does not justify the pseudo-deep analysis in the whole document.

by porridgeraisin

8/1/2026 at 2:23:37 PM

[dead]

by fr2029

8/1/2026 at 2:00:48 PM

Really? It's chock full of poorly written and irrelevant chain-of-thought rambling.

by IshKebab

8/1/2026 at 4:43:51 PM

Anyone 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.

by dosman33

8/1/2026 at 11:04:02 PM

This isn't an HPC cluster. It's just btrfs on my workstation.

by dfranke

8/1/2026 at 4:59:11 PM

Similarly, 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-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.

by btown

8/1/2026 at 5:58:36 PM

> 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/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-mainten...), so I doubt that the "billions of tiny files" problem is at the root of their recent instability.

by gsu2

8/2/2026 at 2:48:40 AM

Interesting related article: 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."

by nyc_pizzadev

8/1/2026 at 12:52:03 PM

So, why the bug triggers only with muslc and not other libc ?

by sligor

8/1/2026 at 6:18:12 PM

Probably 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.

by cyberax

8/2/2026 at 3:33:33 AM

Shouldn't tons of applications linked against musl be crashing all over the Internet if it can express this kernel bug?

by mbac32768

8/2/2026 at 3:42:50 AM

Not 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".

by cyberax

8/1/2026 at 6:11:01 PM

Coincidence. It also only triggers on one machine.

by inigyou

8/1/2026 at 12:56:50 PM

I would normally suspect musl's thread stack size. Is the kernel bug confirmed?

by walk12111

8/1/2026 at 1:24:31 PM

[dead]

by sr0b0t

8/1/2026 at 3:12:32 PM

[dead]

by asdflkt34z

8/1/2026 at 3:11:44 PM

[dead]

by asdflkt34z

8/1/2026 at 3:11:07 PM

[dead]

by asdflkt34z

8/1/2026 at 1:12:42 PM

[flagged]

by rainmaking

8/1/2026 at 2:08:44 PM

[flagged]

by shevy-java

8/1/2026 at 2:11:06 PM

This 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.

by amluto

8/1/2026 at 2:27:23 PM

Thank you for writing virtually all of the intelligent competent comments on this page.

by jibal

8/1/2026 at 6:22:41 PM

I 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.

by hamburglar

8/1/2026 at 7:18:07 PM

Shevy is a long time troll. Should have been banned a while back

by Ar-Curunir

8/3/2026 at 3:36:52 AM

I guess that makes introspection unlikely.

by hamburglar

8/2/2026 at 3:19:30 AM

He's been banned multiple times actually (and from Reddit as well!) but he comes back with other names in the form of shevy-<language>>

by gertop

8/1/2026 at 3:13:10 PM

The 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.

by saghm

8/1/2026 at 6:12:37 PM

Rust 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.

by inigyou

8/1/2026 at 6:22:45 PM

> 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.

by saghm

8/1/2026 at 10:59:57 PM

The kernel bug I believe hasn’t been root caused quite yet although the LLM does seem to have potentially found an unrelated problem.

by vlovich123

8/2/2026 at 9:24:26 PM

Interesting, 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.

by saghm

8/2/2026 at 9:25:48 PM

It’s not. If you look at the analysis, the bug is present only in one version of the kernel everything else the same. It’s the kernel.

Also here’s a kernel developer confirming they think it’s the kernel: https://news.ycombinator.com/item?id=49134550

by vlovich123

8/1/2026 at 2:13:37 PM

In 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.

by gpm

8/1/2026 at 2:29:39 PM

A kernel bug and you’re criticizing Rust. Weird take

by vlovich123

8/1/2026 at 5:58:28 PM

As they wrote, it's "a bit sad" indeed because they cannot blame Rust for this.

by SkiFire13

8/2/2026 at 11:47:19 AM

They're a long-time anti-Rust zealot. This is the sort of nonsense they've been coming out with for years.

by Measter

8/1/2026 at 3:15:00 PM

For starters, musl is a C library, not a Rust library.

by raincole

8/1/2026 at 12:43:08 PM

wow, everything is broken lol

by wild_pointer

8/1/2026 at 2:02:37 PM

No wonder search in codex is so a$$

by villgax

8/1/2026 at 7:17:17 PM

What does one have to do with the other?

by Ar-Curunir

8/2/2026 at 4:28:47 AM

Actually read the post before ignoramusing here

by villgax

8/1/2026 at 3:03:59 PM

Codex uses musl?

by ramon156

8/1/2026 at 3:16:21 PM

Codex 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... [...]"

by derdi