Live data from Hacker News

RipGrep musl binaries occasionally segfault during very-large searches

github.com

31–40 of 216 posts

Re: RipGrep musl binaries occasionally segfault during very-large searches

#31
post #4

Earlier quoted context omitted.

soulless unreadable AI slop

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

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

Re: RipGrep musl binaries occasionally segfault during very-large searches

#32
post #4

Earlier quoted context omitted.

soulless unreadable AI slop

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

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.

Re: RipGrep musl binaries occasionally segfault during very-large searches

#34
post #4

Earlier quoted context omitted.

soulless unreadable AI slop

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

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

Re: RipGrep musl binaries occasionally segfault during very-large searches

#36
post #29
post #19

Earlier 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…

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

Re: RipGrep musl binaries occasionally segfault during very-large searches

#38
post #5

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

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.

Re: RipGrep musl binaries occasionally segfault during very-large searches

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

Post reply on HN