`lto=true` vs `lto=false` changes program behaviour

[C0D3-M4513R]

Code

I tried this code:

https://github.com/C0D3-M4513R/maven-repo/commits/189fae50cff0ca7f55beae135b5b274010435a54

I expected to see this happen:

When requesting https://reposilite.c0d3m4513r.com/Ketting/org/kettingpowered/server/forge/1.20.1-47.4.2-0.4.18/forge-1.20.1-47.4.2-0.4.18-universal.jar.sha512 it returns a 404 status code.

Instead, this happened:
The path actually returns a 500 status code.
When setting it up locally, I also tested turning off lto (because I wanted to test faster) and found that the 500 status code only appears with lto on.
With lto off the status changes to a 404

Setting it up locally:

Setting up the project locally with a copy of the files also makes this issue appear.
I also tested this locally with the minimal set of files to reproduce this.

You need to create two files in the workdir of the executed binary:
.Ketting.json with the following content:

{
  "stores_remote_upstream": true,
  "upstreams": []
}

.env with the following content:

ROCKET_ADDRESS=127.0.0.1
ROCKET_PORT=8005

RUST_LOG=info

The url shared above becomes this locally (with the shared .env file): http://127.0.0.1:8005/Ketting/org/kettingpowered/server/forge/1.20.1-47.4.2-0.4.18/forge-1.20.1-47.4.2-0.4.18-universal.jar.sha512

Version it worked on

It most recently worked on:

rustc 1.87.0 (17067e9ac 2025-05-09)
binary: rustc
commit-hash: 17067e9ac6d7ecb70e50f92c1944e545188d2359
commit-date: 2025-05-09
host: x86_64-unknown-linux-gnu
release: 1.87.0
LLVM version: 20.1.1

Edit: Also tested this to work correctly with lto on 1.88.0:

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

Version with regression

rustc --version --verbose:

rustc 1.89.0-beta.3 (b5e10d8c0 2025-07-02)
binary: rustc
commit-hash: b5e10d8c000a153cae6a14d70372dc4b39439a3f
commit-date: 2025-07-02
host: x86_64-unknown-linux-gnu
release: 1.89.0-beta.3
LLVM version: 20.1.7

No compiler crash occurred, thus no back-trace is available

@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged

[workingjubilee]

@C0D3-M4513R A couple of questions:

• Does this also regress on beta with lto = "thin"?
• Does this also regress on nightly?

[C0D3-M4513R]

Does this also regress on beta with lto = "thin"?

Yes

Does this also regress on nightly?

using:

rustc +nightly --version --verbose
rustc 1.90.0-nightly (5adb489a8 2025-07-05)
binary: rustc
commit-hash: 5adb489a8034f7b56b29f3b28af0813c866f679c
commit-date: 2025-07-05
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.7

and lto = "thin": Does Regress
and lto = true: Does Regress

[C0D3-M4513R]

Also of note: The status code is not consistently 500. It is occasionally 500 (with the percentage varying of how much it is returning 500).

[C0D3-M4513R]

Oh. I just re-tested this on stable.
I found the issue in my usage of HashSet here:
https://github.com/C0D3-M4513R/maven-repo/blob/d9698dfd94e12e7be875ab9f06058f098d3a83ec/src/get.rs#L75

Replacing .next() with a .min() call fixes the inconsistent status-codes (which does make sense).
C0D3-M4513R/maven-repo@00b319d

Sorry for wasting your time.

[hanna-kruppe]

I gotta say, I’d be really surprised if hash table iteration order was affected by LTO. Did you just get unlucky and only observed the unexpected behavior while trying LTO and never without it?

[C0D3-M4513R]

Did you just get unlucky and only observed the unexpected behavior while trying LTO and never without it?

Yep. Only when I tested with nightly I began requesting enough times to both see 404 and 500's. When I tested with beta initially I got "consistently" unlucky with 500's.

Also not helping was that each request I initially requested also requested the favicon.ico, which 404's (and does so consistently, because it's a different code path). So in the Firefox network tab each manual request was separated by 1 request to the favicon.