-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Possible miscompile introduced in nightly 2024-05-04 #124861
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Yes. |
I looked through the glium commit history for relevant-looking changes, and I found glium/glium@ebdc18e. I've confirmed that the commit before that produces the faulty behavior, but with that commit everything behaves normally. @avl I wouldn't mind you double-checking my findings if you're willing, but I'm closing this because I'm reasonably confident in my own work. To double-check, set something like this: glium = { git = "https://github.com/glium/glium", rev = "ebdc18e" } Good find @digama0 :) |
Great analysis! That makes 100% sense. I agree this issue should be closed. I'll find time to verify this fixes the full application shortly, and I'll get back to you in the unlikely event this does not resolve the problem. Edit: Have now confirmed that problem is 100% solved by applying the solution found by @digama0 . |
Code
I tried this code:
Cargo.toml:
I expected to see this happen: The program should print 'Success', and not any opengl-errors.
Instead, this happened:
glium fails while creating the texture array. Program output is:
Version it worked on
This worked in rust nightly 2024-05-03, and is broken on 2024-05-04. It also works in 1.78 stable.
Most recent version it works on is befabbc .
Version with regression
Using cargo-bisect-rustc, the regressed commit is identified as d2d24e3 .
rustc --version --verbose
:Backtrace
Further information
The problem was initially discovered in a large 3D-application which was observed to not render textures if compiled with a rust 'nightly' compiler from 2024-05-04 or later. The application worked apart from this.
The problem goes away if the [profile.dev.package.*]-section is omitted from Cargo.toml. I.e, it seems the problem is triggered by having release-compiled crates in the same binary as debug-compiled.
The problem also goes away if glium is upgraded to the latest version. I have not been able to determine if this just somehow hides the problem, or if it outright fixes it. Porting the repro case to newer glium is easy, but porting the actual faulting application would be more work.
It may well be that some UB in glium is triggering the problem. But I thought I'd write this issue anyway, if this is an actual obscure compiler bug, it would be a shame if it hit stable and caused problems.
Are the changes in d2d24e3 such that they would be likely to uncover UB?
Repro-repo: https://github.com/avl/glium-repro
@rustbot modify labels: +regression-from-stable-to-nightly -regression-untriaged
The text was updated successfully, but these errors were encountered: