Earlier 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
[deleted]
RipGrep musl binaries occasionally segfault during very-large searches
11–20 of 216 posts
Re: RipGrep musl binaries occasionally segfault during very-large searches
#12Earlier 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
Then post whatever notes were fed into the AI instead. The verbosity and self-congratulating add negative value.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#13Earlier quoted context omitted.
soulless unreadable AI slop
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…
[dead]
Re: RipGrep musl binaries occasionally segfault during very-large searches
#14The analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis .
[deleted]
Re: RipGrep musl binaries occasionally segfault during very-large searches
#15Re: RipGrep musl binaries occasionally segfault during very-large searches
#16Earlier quoted context omitted.
PoC||GTFO, if it reproduces, it's valuable
Then post whatever notes were fed into the AI instead. The verbosity and self-congratulating add negative value.
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.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#17Re: RipGrep musl binaries occasionally segfault during very-large searches
#18Re: RipGrep musl binaries occasionally segfault during very-large searches
#19The 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 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.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#20Earlier quoted context omitted.
soulless unreadable AI slop
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.