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

191–200 of 216 posts

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

#191

Post by smukherjee19 »

csense wrote: post #105
smukherjee19 wrote: post #52

Earlier quoted context omitted.

I tried reading and gave up at the "Headline"... Quoting from the bug analysis: >Headline. The crash is real and reproducible. With musl instrumentation we pin the in-process mechanism precisely: a thread's own store to a freshly- faulted anonymous page becomes invisible to that same thread's reload ~10 instructions later, because the page's backing is replaced mid-function. A pagemap read at the instant of the fault…

This is technical writing for kernel developers who already know how memory management works. If you want to understand it better, you should study up on the x86 MMU and the kernel memory management subsystem. I'm not a kernel expert but I found it pretty understandable, so I'll try to explain it. MMU: The memory management unit, part of the CPU designed to allow an OS kernel to flexibly control how memory addresses…

OP here. Thank you so much for taking the time to write it!

This is so much easier to understand, and I also learnt a few things along the way, like the zero page mechanism, munmap having to notify the MMU about the invalid TLB and more.

Really appreciate it!

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

#192

Post by dataflow »

inigyou wrote: post #178
dataflow wrote: post #169

Earlier quoted context omitted.

FYI, Windows's approach is better in some respects, like letting you avoid syscall overhead in some cases.

Notably, Linux has this too, but it's a special mechanism (vDSO) while on Windows it's just a normal function call with no difference from any other function.

Or in other words, they agreed the Windows approach was better, and tried to retrofit it (;

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

#193

Post by nyc_pizzadev »

Interesting related article: https://www.theregister.com/ai-and-ml/2026/07/29/closed-mode...

Looks like the AI models either refused to work or produced obvious garbage. "GLM-5.2 is what finished the job for me, re-auditing K3's work and putting together an airtight case."

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

#194

Post by RideOnTime22 »

gruntled-worker wrote: post #179
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!

Until ~2000, "cellphone user in public" equated with "smug asshole." We're at that icky rejection stage with AI. Two years ago, that writeup would have been viewed as a generous gift of time to the community. Now we can't be bothered to read through it because we know where it came from, and that it's just worth $0.06 in tokens. Another reason (I think) is because we know what it portends. In a few years, digging man…

It's less "can't be bothered to read through it because we know where it came from" and more "can't be bothered to read through it because of how word-salad it is"

Unless heavily prompted the written output is always so dense that you can barely understand it.

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

#195

Post by gertop »

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

He's been banned multiple times actually (and from Reddit as well!) but he comes back with other names in the form of shevy->

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

#196

Post by mbac32768 »

cyberax wrote: post #149
sligor wrote: post #7

So, why the bug triggers only with muslc and not other libc ?

Probably because musl's allocator exposes single newly faulted pages directly to the app. Other allocators tend to pre-allocate multiple pages at a time, so that the race window is narrower.

Shouldn't tons of applications linked against musl be crashing all over the Internet if it can express this kernel bug?

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

#197

Post by cyberax »

mbac32768 wrote: post #196
cyberax wrote: post #149

Earlier quoted context omitted.

Probably because musl's allocator exposes single newly faulted pages directly to the app. Other allocators tend to pre-allocate multiple pages at a time, so that the race window is narrower.

Shouldn't tons of applications linked against musl be crashing all over the Internet if it can express this kernel bug?

Not necessarily. Another key here is that the allocation is triggered from the libc, while the main app uses another allocator.

These kinds of issues with VM are notoriously tricky to replicate. And the main debugging method is "staring intently at the code".

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

#199

Post by benmmurphy »

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!

Looking at the function the addr value should always equal end but also it looks like on x86 this value is discarded in pte_free_tlb so maybe this is not the problem or I’m looking at a different version.

https://github.com/torvalds/linux/blob/master/mm/memory.c#L1...

Assuming addr is a virtual address it probably makes sense that pte_free_tlb does not need it.

https://github.com/torvalds/linux/blob/master/arch/x86/mm/pg...

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

#200

Post by NetMageSCW »

orphea wrote: post #43
rfgplk wrote: post #22

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

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.

Post reply on HN