Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RipGrep musl binaries occasionally segfault during very-large searches

github.com

Post reply on HN
Print view View original

41–50 of 216 posts

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

#41

Post by shevy-java »

serf wrote: post #26
hoppp wrote: 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.

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

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.

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

#42

Post by amluto »

shevy-java wrote: post #39

[flagged]

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.

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

#43

Post by orphea »

rfgplk wrote: post #22
skydhash wrote: post #20

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

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

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

#44

Post by gpm »

Retr0id wrote: post #29
amluto wrote: 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…

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

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

#45

Post by oxidant »

p0nce wrote: post #37
hyperpape wrote: post #3

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

Reading an AI-generated bug report is awful.

Stopped after

> Headline. The crash is real and reproducible.

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

#47

Post by [deleted] »

amluto wrote: post #42
shevy-java wrote: post #39

[flagged]

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.

[deleted]

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

#49

Post by [deleted] »

gpm wrote: post #44
Retr0id wrote: post #29

Earlier quoted context omitted.

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…

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

[deleted]
Post reply on HN