-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
LTO coordinator panics by unwrapping Option::None #130678
Comments
FYI this will cause almost none of the incremental compilation code in the compiler to do anything interesting; random edits that are then reverted would tickle a lot more. It would also be slower. It looks to me like you somehow ended up with an LLVM module (codegen unit) whose name is not UTF-8. That is wild. #130680 will improve the ICE message. If you're willing to apply that patch locally, I'd love to see what the module name you're coming up with is. |
Thanks for the hint regarding my methodology. Im building the 1.81 release with your commit cherry-picked on top now according to these instruction. I have never built rust from source before, Am I correct in assuming that I can run Or will that detect that its not the same compiler anymore and try to build everything anew, losing the broken state? |
I don't know anything about I'm also not sure I'd bother trying to make compiler not rebuild its artifacts. If you're fuzzing, eventually you should run into the same bad state again. Or you can show me how to run your fuzzer, and I'll run it overnight or on a cloud VM for a while. |
As suspected, the compiler didn't like the state and rebuilt everything. The reported error no longer occurs, but I'm trying to reproduce it now. All of my fuzzing "tooling" and binary crate I was building (with commit hash) is in the issue description above if you want to run it yourself. Since I'd guess its a timing issue, i.e. the compilation process being interrupted at some critical stage that isn't protected well enough, I'm not sure how well this will be reproducible on my machine (8845HS CPU) or even in a cloud VM. I'll also let this run over night, so we'll see. Edit: still nothing after eight hours. The first time it appeared after about three. |
…youxu Call module_name_to_str instead of just unwrapping This makes the ICE message in rust-lang#130678 more clear. It looks like not calling this function was just an oversight in rust-lang#76859, but clearly not a major one because it's taken us 4 years to notice.
Call module_name_to_str instead of just unwrapping This makes the ICE message in rust-lang#130678 more clear. It looks like not calling this function was just an oversight in rust-lang#76859, but clearly not a major one because it's taken us 4 years to notice. try-job: i686-msvc
Still nothing, been running this on two machines since my last post. I did try to build a compiler that thinks its the same version as the 1.81.0 release and reuse the tainted artifacts. Building from a clean state works with this compiler, it seems like it doesn't like mixing the standard libraries from different(ly named) toolchains, even though they should be identical. The commit hash the compiler version is tagged with is identical to the 1.81 release after I removed your cherry picked commit and just applied the change to the worktree. |
Call module_name_to_str instead of just unwrapping This makes the ICE message in rust-lang#130678 more clear. It looks like not calling this function was just an oversight in rust-lang#76859, but clearly not a major one because it's taken us 4 years to notice. try-job: i686-msvc
Call module_name_to_str instead of just unwrapping This makes the ICE message in rust-lang/rust#130678 more clear. It looks like not calling this function was just an oversight in rust-lang/rust#76859, but clearly not a major one because it's taken us 4 years to notice. try-job: i686-msvc
Call module_name_to_str instead of just unwrapping This makes the ICE message in rust-lang/rust#130678 more clear. It looks like not calling this function was just an oversight in rust-lang/rust#76859, but clearly not a major one because it's taken us 4 years to notice. try-job: i686-msvc
Code
Discovered this error while fuzzing for #81280
I used
cargo watch -- cargo build --profile incremental
for building this binary crate, whiletouch
-ing random files at random intervals to trigger rebuilds.Fish script:
Meta
rustc --version --verbose
:Error output
Backtrace
The text was updated successfully, but these errors were encountered: