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

161–170 of 216 posts

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

#161

Post by entrope »

cyberax wrote: post #146
entrope wrote: post #133

Earlier quoted context omitted.

> It’s the kernel. Nothing a user space library can do should ever be able to call this. I don't follow. An application might see this kind of crash if it has a bug causing it to access a page while another thread is mapping or unmapping that page. That would be a bug in mallocng, musl or ripgrep. Or, as someone else mentioned, it could be bug in the processor's virtual memory logic that has the same effect. Why do y…

It got traced to a race condition in munmap() in the kernel. The inefficient musl allocator simply triggers it more easily.

It got arm-waved to a race condition in munmap(). Claude (or a distill of Claude) didn't identify a race, it just convinced itself that was the cause.

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

#163

Post by Ar-Curunir »

hamburglar wrote: post #150
shevy-java wrote: post #39

[flagged]

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

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

#164

Post by masklinn »

VorpalWay wrote: post #155
tialaramex wrote: post #100

Earlier quoted context omitted.

Rust doesn't get to override musl internals. Ripgrep uses opendir, a POSIX library feature implemented in musl to look at er, directories. The stack trace suggests we blew up when Rust's std::sys::fs::unix::readdir internal detail called opendir, and it in turn allocated. On Linux it would be possible for ripgrep to talk directly to the kernel via documented system calls without libc, but that wouldn't work on any ot…

> Rust doesn't get to override musl internals. Is malloc not a weak symbol in musl? I would expect it to be overridable like it is with glibc. Or does ripgrep only override Rust's global allocator?

> Or does ripgrep only override Rust's global allocator?

That one, as you can see in the code linked above, it only does rust-level overriding as that was where musl's allocator was found to impact ripgrep (https://github.com/BurntSushi/ripgrep/commit/03bf37ff4a29361...)

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

#165

Post by mort96 »

entrope wrote: post #125
mort96 wrote: post #91

Earlier quoted context omitted.

The way most programs achieve being fast is by re-using allocations. You don't need a fast allocator if you don't allocate. Nothing of what ripgrep does inherently requires frequent allocations.

The ISO C definition of opendir() requires an allocation in practice because it returns a DIR* and it's bad practice for the library to arbitrarily limit how many of those an application has at a time. Maybe a C library could preallocate several DIRs and only use the heap when those are exhausted, but this ripgrep use case (lots of threads running in parallel on a large tree) would still be likely to trigger that.

There is no ISO C definition of opendir(), that's a POSIX thing.

But yeah, those DIR objects which opendir() returns a pointer to are probably some kind of heap allocated. But we're talking about a system call involving the filesystem here. The time taken by the allocator is gonna be dwarfed by the time spent in the syscall even with the slowest allocator.

Ripgrep reads through every byte of most files and matches it against a regex. That is the tight inner loop where you want to avoid allocations.

Not that you even need to call the C functions. I don't think ripgrep would gain anything from it, but the syscall to read directory contents just needs a file descriptor.

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

#166

Post by agumonkey »

PunchyHamster wrote: post #134
agumonkey wrote: post #10

Earlier quoted context omitted.

> It doesn't make sense for the reader to spend more energy than the writer spent on creating it. Great way to summarize cultural "economics" Couldn't put the words on this pattern but sometimes all I care about is that someone cared about.

I usually go for "If I wanted LLM answer I'd ask LLM instead of reading your answer/article/content"

But it goes beyond this. The whole 2020s era is about cheap ways to do anything and be able to stream it to billions of people. Yet I feel no density in the work because there was no energy spent on it.

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

#167

Post by vaughands »

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!

Thanks for the fun read.

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

#168

Post by ChrisSD »

inigyou wrote: post #126
tialaramex wrote: post #100

Earlier quoted context omitted.

Rust doesn't get to override musl internals. Ripgrep uses opendir, a POSIX library feature implemented in musl to look at er, directories. The stack trace suggests we blew up when Rust's std::sys::fs::unix::readdir internal detail called opendir, and it in turn allocated. On Linux it would be possible for ripgrep to talk directly to the kernel via documented system calls without libc, but that wouldn't work on any ot…

I assume it already doesn't work on Windows. At some point you have to define your compatibility boundary. And high performance often coincides with mediocre compatibility.

You can call into the kernel just fine in Windows. The fact you use a function call wrapper instead of a raw syscall is not really relevant.

Most Windows NT kernel functions take a buffer to use rather than allocating their own memory. Even many Win32 functions don't allocate (although there you have to be much more careful).

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

#169

Post by dataflow »

galangalalgol wrote: post #138
inigyou wrote: post #126

Earlier quoted context omitted.

I assume it already doesn't work on Windows. At some point you have to define your compatibility boundary. And high performance often coincides with mediocre compatibility.

A good example is go. On linux you can use a from scratch image fairly easily because it only uses syscalls. But for windows or mac the moving target wasn't maintainable so they link against shared objects. Linus enforcing the don't break userspace rule is what made that possible. That definitely has tradeoffs. At some point relibc or something similar will allow the same (stably) for rust. But using posix as that co…

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

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

#170

Post by lrvick »

Orphis wrote: post #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…

We use musl+mimalloc by default for our entire production operating systems: https://stagex.tools
Post reply on HN