[flagged]
RipGrep musl binaries occasionally segfault during very-large searches
21–30 of 216 posts
Re: RipGrep musl binaries occasionally segfault during very-large searches
#22Earlier quoted context omitted.
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 cl…
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.
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.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#23Earlier quoted context omitted.
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.
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.
Then where’s the lie in “soulless AI slop”?
Re: RipGrep musl binaries occasionally segfault during very-large searches
#24The analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis .
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 ha…
The explanation is obviously written by an AI agent.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#25Earlier quoted context omitted.
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.
PoC||GTFO, if it reproduces, it's valuable
They have a PoC, we're arguing about the LLM-generated slop explanation of the PoC.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#26Earlier quoted context omitted.
soulless unreadable AI slop
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.
energy might be the wrong metric, plenty of energy was wasted spinning up that LLM.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#27[dead]
Re: RipGrep musl binaries occasionally segfault during very-large searches
#28Earlier quoted context omitted.
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.
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.
> 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.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#29The analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis .
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 ha…
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)
Re: RipGrep musl binaries occasionally segfault during very-large searches
#30The analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis .
The overflow would still overflow; the use-after-free would still use after free; a musl mask race would still race.