Earlier quoted context omitted.
soulless unreadable AI slop
I had the opposite reaction. Clear, detailed, well-organized. Pretty close to the ideal writeup.
RipGrep musl binaries occasionally segfault during very-large searches
31–40 of 216 posts
Re: RipGrep musl binaries occasionally segfault during very-large searches
#32Earlier quoted context omitted.
soulless unreadable AI slop
I had the opposite reaction. Clear, detailed, well-organized. Pretty close to the ideal writeup.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#33Re: RipGrep musl binaries occasionally segfault during very-large searches
#34Re: RipGrep musl binaries occasionally segfault during very-large searches
#35Re: RipGrep musl binaries occasionally segfault during very-large searches
#36Earlier quoted context omitted.
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/incon…
https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-...
Re: RipGrep musl binaries occasionally segfault during very-large searches
#37The analysis of the kernel bug may be a better thing to link to: https://github.com/dfoxfranke/ripgrep-3494-analysis .
Re: RipGrep musl binaries occasionally segfault during very-large searches
#38Earlier 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
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.
Re: RipGrep musl binaries occasionally segfault during very-large searches
#39Re: RipGrep musl binaries occasionally segfault during very-large searches
#40mallocng 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.