Live data from Hacker News

RipGrep musl binaries occasionally segfault during very-large searches

github.com

81–90 of 216 posts

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

#81
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…

[deleted]

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

#84
post #79

Earlier quoted context omitted.

I love LLMs for technical stuff, but their writing style is horrendous. I also think it's bad form to waste fellow humans' time with walls of generated text. I understand that it's probably a hard technical problem to get models to conform to a style without sacrificing performance in other areas. But I really wish AI companies would spend more effort getting them to write in a neutral, concise way and not like a mid…

> But I really wish AI companies would spend more effort getting them to write in a neutral, concise way I wonder if this would make it harder or easier to detect whether the underlying meaning of the writing is bullshit.

Definitely easier. It's the same for humans. You can tell that someone has little of substance say when they cloak everything in big words and elaborate metaphors.

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

#86

[flagged]

The bug is in the C code that Rust is interacting with. If anything, you seem to be making an argument in favor of replacing even more of the C code with Rust so that this doesn't happen.

What you seem to think is a defense of C is accidentally just providing ammunition to the "rewrite it in Rust" crusade that I'm guessing you're very much not a fan of. There are very solid arguments against rewriting everything in Rust, and you're arguably doing more harm than good by making a counterproductive one.

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

#87

Earlier quoted context omitted.

I really hated that kind of language, feels like speaking to a motivator anyway it's slop, can sense it even before i started reading

The worst thing is that I know there's something interesting in there but I'm too arsed to take the time and decode what data the author must have used to generate that text.

Get your own AI to give you the tldr :/

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

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

The other part is that almost no one would have the energy to spend hours instrumenting and rebuilding musl, reading the kernel mm code, and thinking hard about how they might interact. Claude is probably not right about the root cause here and is probably bsing, I agree. But it's collected enough raw data to point some expert humans at the right interaction. I'd take this bs bug report and start asking Claude some q…

> The other part is that almost no one would have the energy to spend hours instrumenting and rebuilding musl, reading the kernel mm code, and thinking hard about how they might interact.

Maybe because it isn’t needed. That’s the reason we have experts and professionals, because it’s more economical to use them than for everyone to start from scratch. It’s easier to go to a mechanic shops to fix my engine block than to try to do it myself. I’ve heard that a lot of shops charge more if you said an amateur try to fix things first.

It’s a lot of stuff, but that’s not how you experiment for an hypothesis.

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

#90
post #35

No wonder search in codex is so a$$

Codex uses musl?

Codex bundles a ripgrep binary that is linked against musl. This is noted in the bug report: "I originally encountered this bug in the rg bundled with OpenAI Codex. That binary is byte-for-byte identical with the one in https://github.com/BurntSushi/ripgrep/releases/download/15.2... [...]"
Post reply on HN