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

211–216 of 216 posts

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

#211

Post by fc417fc802 »

NetMageSCW wrote: post #200
orphea wrote: post #43

Earlier quoted context omitted.

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

So just spend a few years learning to be a kernel developer so they can report a kernel bug that is crashing their user program? That is so open source it’s not even funny.

No, just omit the rambling in favor of a "sorry I lack the expertise to really dig into this, here's a reproducer and I'm here if you have any questions I'm able to help with".

Your bizarre overly literal take is so peak HN that it ... okay I admit it's still funny to me.

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

#212

Post by gruntled-worker »

monitron wrote: post #209
gruntled-worker wrote: post #202

Earlier quoted context omitted.

Is there any indication that it was a mini/fast/older model, or on a low effort level? My read of the reactions above is "ugh AI", not "ugh AI on the cheap". Not a single poster mentioned model or effort choice. It seems more like the usual irritation at "AI slop". If you just mean that the result was technically incorrect or off, that's probably true, but it doesn't affect my argument.

At work I am sitting on a small pile of incomplete/wrong/missing-the-point bug reports right now, all generated by Opus 5 on High effort. Even under good conditions, LLMs are still wrong quite a lot, and confidently so. I can see why you think instant dismissal of LLM generated work is shallow, but I think it's at least as shortsighted to assume that when it creates poor quality work it must be an old/cheap model, ba…

I'm not arguing that it's great. I'm arguing that the future of human work in this area will be limited to dealing with the cases when it isn't great, i.e. the pile on your desk. Choosing the best model and highest effort is the due diligence required to minimize the size of that pile.

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

#213

Post by saghm »

vlovich123 wrote: post #180
saghm wrote: post #151

Earlier quoted context omitted.

> Rust wouldn't have helped, because this is a logic bug in the kernel, that creates a memory bug in userspace. Unless I'm misunderstanding, the bug is kernel code accessing out-of-bounds memory in an array. That would 100% not segfault in normal Rust code. > The relevant kernel code would probably be marked "unsafe" with or without the bug. I mean, sure, if you remove the safety rails that prevent you from running o…

The kernel bug I believe hasn’t been root caused quite yet although the LLM does seem to have potentially found an unrelated problem.

Interesting, I hadn't heard that! That does sound like it's just as premature to claim Rust wouldn't have prevented it as it is to claim it would have, which I think stands as valid criticism of the comment I originally responded to.

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

#214

Post by vlovich123 »

saghm wrote: post #213
vlovich123 wrote: post #180

Earlier quoted context omitted.

The kernel bug I believe hasn’t been root caused quite yet although the LLM does seem to have potentially found an unrelated problem.

Interesting, I hadn't heard that! That does sound like it's just as premature to claim Rust wouldn't have prevented it as it is to claim it would have, which I think stands as valid criticism of the comment I originally responded to.

It’s not. If you look at the analysis, the bug is present only in one version of the kernel everything else the same. It’s the kernel.

Also here’s a kernel developer confirming they think it’s the kernel: https://news.ycombinator.com/item?id=49134550

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

#215

Post by hamburglar »

Ar-Curunir wrote: post #163
hamburglar wrote: post #150

Earlier quoted context omitted.

I would suggest you revisit this in a day or two and reevaluate whether your knee-jerk blaming of rust was appropriate here, then ask yourself what biases led you to do that.

Shevy is a long time troll. Should have been banned a while back

I guess that makes introspection unlikely.

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

#216

Post by tonfa »

ndesaulniers wrote: post #116

Heh, from the kernel patch: https://lore.kernel.org/all/CALCETrXbj__SFQMzPZhES5y6-sh4np-... > I saw a fun bug report in ripgrep and a studious but pretty bad AI-generated analysis Referring to https://github.com/dfoxfranke/ripgrep-3494-analysis which I indeed thought "that's an awful lot written to have been written by a human." Looks like that thread is from...today!

Patch was applied yesterday by Linus: https://lore.kernel.org/all/20260804003708.49830-1-luto@kern...
Post reply on HN