Top
Best
New

Posted by throwaway2037 9 hours ago

RipGrep musl binaries occasionally segfault during very-large searches(github.com)
223 points | 151 commentspage 2
wild_pointer 9 hours ago|
wow, everything is broken lol
villgax 8 hours ago||
No wonder search in codex is so a$$
Ar-Curunir 2 hours ago||
What does one have to do with the other?
ramon156 7 hours ago||
Codex uses musl?
derdi 6 hours ago|||
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... [...]"
asdflkt34z 6 hours ago|||
[dead]
shevy-java 7 hours ago|
This is a bit sad. Here we have an example of rust and musl struggling whereas C/C++ and glibc does not. That's an oversimplification, but we also had not long ago the rewrite of ... I believe it was coreutils, in rust (or was it utillinux ... but I think it was coreutils), also have issues. Rust needs to toughen up here when it really wants to replace all of C in the linux ecosystem. Alternatively it could admit failure, then people can say that C will be - and remain - the forever king.
amluto 7 hours ago||
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.

jibal 7 hours ago|||
Thank you for writing virtually all of the intelligent competent comments on this page.
hamburglar 3 hours ago|||
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.
Ar-Curunir 2 hours ago||
Shevy is a long time troll. Should have been banned a while back
gpm 7 hours ago|||
In addition to this likely not being a bug in the code you're pointing at, but the kernel (written in C). musl is literally C code, and that most rust users compile against glibc just like most C users do.
saghm 6 hours ago|||
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.

inigyou 3 hours ago||
Rust wouldn't have helped, because this is a logic bug in the kernel, that creates a memory bug in userspace. The relevant kernel code would probably be marked "unsafe" with or without the bug.
saghm 3 hours ago||
> 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 off the side of the cliff, then you will in practice likely ending up running off the cliff. If you have to explicitly do that though, it still makes it a lot more obvious that this is a risk than if you refuse to have safety rails anyway for any purpose.

vlovich123 7 hours ago|||
A kernel bug and you’re criticizing Rust. Weird take
SkiFire13 4 hours ago||
As they wrote, it's "a bit sad" indeed because they cannot blame Rust for this.
raincole 6 hours ago||
For starters, musl is a C library, not a Rust library.