"called Result::unwrap() on an Err value: Utf8Error { valid_up_to: 2 }" ICE in stable
#33778
Comments
|
@netvl Try doing a |
|
@Diggsey Can (probably) confirm. I got this same error when switching from nightly-msvc to stable-gnu after aborting a build. |
|
Same here. I'm not sure what caused it, but I was switching around between nightly and stable before. Works in nightly, fails in stable. Once it started happening, it was happening every time. Running |
steveklabnik
added
the
I-ICE
|
I got the same error running It's probably unrelated but just before it panicked I set up the new error format with I have a file in extern crate my_crate;
#[test]
...And the panic did not occur when I commented out When I changed the code and it compiled with nightly I was able to compile with stable again. |
|
cc @rust-lang/compiler This seems to be getting lots of hits, is something that's fixed on nightly? Perhaps something that can be backported to beta? |
alexcrichton
added
I-nominated
T-compiler
|
@alexcrichton I'm not sure what's causing this -- you think it's a rustc bug? |
|
@nikomatsakis yes: This may be fixed on both nightly and beta, as the only transition I can get to break is nightly to stable. I basically just want to confirm that we know what happened here and that it is indeed fixed and future-proofed. |
|
@alexcrichton hmm maybe I'm just being dense but I at least don't know what caused this and/or if it is fixed. =) |
|
I suspect the problem is due to the fact that I changed the crate hash from being a string to being a u64. It seems to me to be sort of a cargo bug -- like, why are we seeing stale metadata from a different version of the compiler? But I don't quite know how this system interacts. @alexcrichton let's chat. :) |
|
triage: P-high |
|
The stale metadata may be sticking around because Cargo doesn't clean out old libraries, and when the compiler is specifically looking for the If it's the case that this is the crate hash, there's probably nothing we can do about this other than issuing a point release, and it doesn't seem worth it to do that... |
|
Could rustc make sure to only use panic-free code up until the point where it's read the metadata version, and give a helpful error message instead of ICEing? |
|
@alexcrichton I could go back to putting a string in metadata instead of just writing a u64, I guess |
|
I'll have to go poke at the code |
|
@alexcrichton hmm for some reason I'm not seeing that failure you suggested locally... |
|
This can also be reproduced using rustup. $ rustup run nightly -- cargo build
# Suceeds
$ rustup run stable -- cargo build
# ICE |
|
Same error, on stable only. A |
|
I'm hitting this also but a cargo clean doesn't fix it. |
brson
added
the
regression-from-stable-to-nightly
|
@rust-lang/lang Can somebody be assigned to this one? It's P-high. |
|
arguably this is perhaps not a regression... @arielb1 says the problem is caused by new versions of the compiler generating metadata that old versions of rustc cannot handle. (We are supposed to have a metadata guard but the issue arises before the metadata guard fires.) |
|
Issues here:
|
|
simplest thing may be to just go back to writing a string instead of a u64, if someone knows the precise place that @nikomatsakis was referring to in his comment above. |
previously, only .so files included a metadata encoding version, *outside* of the zlib compressed area. This adds an encoding version inside the metadata itself, in both .so and .rlib files. Fixes rust-lang#33778.
previously, only .so files included a metadata encoding version, *outside* of the zlib compressed area. This adds an encoding version inside the metadata itself, in both .so and .rlib files. Fixes rust-lang#33778.
Make the metadata lock more robust Fixes #33778 and friends. I also needed to add a metadata encoding version to rlibs, as they did not have it before. To keep it backwards-compatible, I added 4 zeroes to the start of the metadata, which are treated as an empty length field by older rustcs. r? @alexcrichton
I suddenly got the following error when compiling my crate:
Here are the crate sources: immeta.zip
Apparently there is no such error on travis, so I think this may be caused by some weird interaction of rustc with rustup, but I don't know for sure.
rustc version:
cargo version:
rustup version:
The text was updated successfully, but these errors were encountered: