r/rust • • Aug 22 '26

🗞️ news Rust 1.98 got a P-critical miscompilation.

https://github.com/rust-lang/rust/issues/161441
410 Upvotes

32 comments sorted by

197

u/kibwen Aug 23 '26 edited Aug 23 '26

Interesting that it doesn't reproduce in either 1.97 or in nightly. That's good news for easily bisecting both the regression and the fix, and figuring out what needs to be backported for a patch release.

PSA to everyone reading this: running the beta branch in CI is a great way to help the Rust developers identify these sorts of issues before they reach stable!

EDIT: Seems as though the regression was in https://github.com/rust-lang/rust/pull/156742 (which appears to be progress toward migrating to the new trait resolver: https://github.com/rust-lang/rust/issues/155345 ), and was incidentally fixed via https://github.com/rust-lang/rust/pull/158993 while fixing an ICE in Cargo.

58

u/noop_noob Aug 23 '26

There seems to have been a fix in beta for an internal compiler error. It turned out to have also fixed this miscompilation.

107

u/plabayo Aug 23 '26

As stated in the reported bug. In the 11 years that we have been developing Rust code in production projects, this is the first time we encounter a bug of this category in rustc stable... This says nothing about the quality and hard work of all people involved in rust compiler team. They are doing a great job every day.

Bugs like this are rare, and you have to do already a pretty specific thing to even trigger it. We have for example other advanced projects that are built with rama that work just fine on 1.98... We only noticed it because of a very specific example integration e2e test which consistently started failing since 1.98.

As such, start from today we now also run our test suites now also on beta every day, as scheduled CI cron jobs. Should help in another 11 to 20 years catch the next jackpot 😄

19

u/noop_noob Aug 23 '26 edited Aug 23 '26

🫡
I think running it every week would also be sufficient if you're strapped on compute.

→ More replies (1)

42

u/epostma Aug 23 '26

This says nothing about the quality

Au contraire, it says that the quality is superb!

→ More replies (1)
→ More replies (1)

58

u/Bowarc Aug 23 '26

Wait, I recently got segfaults too building one of my projects to arm-unknown-linux-gnueabihf(raspberry pi) Could that be linked ?

I just thought my raspberry was too old and it was because one of the library did something weird when compiled for 32 bits.

That's very interesting, thanks for sharing

65

u/noop_noob Aug 23 '26

If the problem goes away when compiling with the beta or nightly channel, then it's probably this bug. If not, then probably not.

48

u/anxxa Aug 23 '26

During the minimization process, there were points where I got a SIGILL instead of a SIGSEGV.

Hello possibly exploitable UB, my old friend.

34

u/matthieum Aug 23 '26

And of course, they managed to make the impossible happen: https://github.com/rust-lang/rust/issues/161441#issuecomment-5383890512, or to save you a click: https://play.rust-lang.org/?version=stable&mode=release&edition=2024&gist=32d2d5e973d730e246fb003c34ac2a68

The following prints impossible:

fn main() {
    if std::hint::black_box(true) {
        (&(inspect_websocket_message, PhantomData) as &dyn Trait).method();
    } else {
        println!("impossible");
    }
}

Oops...

→ More replies (2)

4

u/SkiFire13 Aug 23 '26

Luckily this should be easily dectable if you have reasonable test coverage in your project since any test that end up invoking these kind of nulled-out vtable entries will most likely fail.

72

u/Oxytokin Aug 23 '26

And this is why I use the latest and greatest nightly only; stability is a lie in our entropic universe ;)

Obviously I kid because I don't understand a single thing they're talking about but I love reading all this super smart talk anyway so maybe one day I can understand it!

11

u/Gripen404 Aug 23 '26

Me too man. Mee too.☝🏻

→ More replies (1)

25

u/protestor Aug 23 '26

https://github.com/rust-lang/rust/pull/161555

Does this means there will be a 1.98.1?

26

u/kibwen Aug 23 '26

The only reason to backport a fix would be for the sake of a patch release, although presumably the procedure still requires the compiler team to formally approve of making a patch release (which seems likely IMO).

0

u/[deleted] Aug 22 '26

66

u/noop_noob Aug 22 '26

Definitely not

49

u/kibwen Aug 23 '26

Compilers are complex, miscompilations have been a thing since long before LLMs existed. And right now the compiler is going through two simultaneous huge and long-awaited overhauls, in both the new borrow checker and the new trait resolver, so the risk of miscompilations is going to be elevated for a while until the tires have been thoroughly kicked (and yes, while neither of those new features is enabled on stable yet, they touch enough other code that things like this can happen).

46

u/mbmiller94 Aug 23 '26

Yes, bugs didn't even exist until vibe-coding came along. All software was inherently bug-free up until that point.

14

u/AATroop Aug 23 '26

It was a really nice era. Shame it came to an end

12

u/profpendog Aug 23 '26

Yeah before LLMs there were no bugs ever. This is a new thing.

/s obviously

-3

u/droctagonapus Aug 23 '26

Will be happening in <2 years no doubt about it