unstable fingerprints, generics_of #87860
Assignees
Labels
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
ijackson
added
C-bug
|
@ijackson: Thanks for the detailed report! Before you ran the failing |
|
Before you ran the failing cargo build command, do you know what
commit you had checked out?
I think you mean "the last time I ran cargo before the failing
command". I'm afraid I don't know what the state was then. It
probably wasn't a formal commit - it was probably a dirty working
tree. I only committed the failing tree for the purposes of the bug
report.
But, I have magit wip mode enabled. That makes a private wip commit
every time I save. So perhaps my reflog will be illuminating.
...
Hrm. Well I tried a number of things but no luck with a repro.
I have what I believe to be a git commit for every time I saved a file
in my working tree. But no doubt I didn't always run the compiler
after each save.
I semi-manually wrote this script:
sh -xc 'for x in 736e21a9a48214511f6078e36f57f12929709af9 3adbe0ade82dfbdfab5c44233dbbcf6e5768d1e4 5ee3f180add3a636c048aeeb323c2d66bc66a341 3adbe0ade82dfbdfab5c44233dbbcf6e5768d1e4 ea553cfafd811f59755fc5ea2576980f818ca9fd be767a4682e2294211749bded50b6e8e001d4fe9 62932099b285055121b61d85e023e821dd81f8c7 0d814a7ef4345ae488ef8b61676fede4a867d7c3 af1f12c339e241d2ffd64f768d8c8e7e90871eca af7cf96e4af83b483a300491f3cddc032431c164 ff07ec217de7ead5f497b05fa1026aaf630978bf; do git reset --hard; git checkout $x; nailing-cargo -u build; done'
That is just a relevant-seeming range of entries from
git reflog wip/wtree/refs/heads/main
which is the wip reflog saved by magit.
I also tried a different approach to the git commit mining:
../t; for x in HEAD wip/{wtree,index}/refs/heads/main; do git-log -g --pretty=format:'%gD %ct %s %H' --date=unix $x |perl -pe 's/^\S+\{(\d+)\}/$1/' >>../t; done; git-log --pretty=format:'%ct %ct %s %H' --date=unix main >>../t
sort <../t | perl -ne 'next if $_ > 1628420294; next if $_ < 1628387327; print' >../u
perl -pe 's/^.* // or die' <../u >../v
sh -xc 'for x in `cat ../v`; do git reset --hard; git checkout $x; nailing-cargo -u build; done'
That produced this commit list:
6b9f8911b8d4b9f1c64693bda43fee13e40685e1
6b9f8911b8d4b9f1c64693bda43fee13e40685e1
a2117ea7988c6479b52293ffb1b3a54853515908
a2117ea7988c6479b52293ffb1b3a54853515908
e8773af22ca301aa8fff2827fc2b4c0562a4d281
e8773af22ca301aa8fff2827fc2b4c0562a4d281
09af57203e021dc02f5042b8978aa3a88e5f01b5
09af57203e021dc02f5042b8978aa3a88e5f01b5
91e901daf19c32a5f38169b48a56b595260579d1
91e901daf19c32a5f38169b48a56b595260579d1
91e901daf19c32a5f38169b48a56b595260579d1
032b7692a0d9e28d8363d6e19d0a355c2c4c2d3c
032b7692a0d9e28d8363d6e19d0a355c2c4c2d3c
ed8719c83003c42d00e143debda90a80df9ca5f2
ed8719c83003c42d00e143debda90a80df9ca5f2
f0519ed9231467266d9511e7d49e2d9cec699b4b
6a6e7b9a97fd92be75708e840b8ab62d252b27e8
736e21a9a48214511f6078e36f57f12929709af9
6c73d4db835cb6039ffc0cb4c5ecb7cf8c392eef
3e0bf641336cc2e0716ef87ba5b70cedf8c86125
2b184beba5b52140ce222fe476b4a75b5a876063
a873bc832b76cb79d36173c73ba085e5b05eb7b2
a873bc832b76cb79d36173c73ba085e5b05eb7b2
ea553cfafd811f59755fc5ea2576980f818ca9fd
5ee3f180add3a636c048aeeb323c2d66bc66a341
3adbe0ade82dfbdfab5c44233dbbcf6e5768d1e4
3adbe0ade82dfbdfab5c44233dbbcf6e5768d1e4
be767a4682e2294211749bded50b6e8e001d4fe9
c9dac7b38ce6f931888863cde0b080554bb24edd
fc837dcbcd386f4ddc7db5f057d1159b0ecbc882
62932099b285055121b61d85e023e821dd81f8c7
36e851a05f326e20ec0193d8162dd95e1a1d23a6
65f2b7c13549c50d5a95876302e72a03474ef1c5
0d814a7ef4345ae488ef8b61676fede4a867d7c3
0d814a7ef4345ae488ef8b61676fede4a867d7c3
0d814a7ef4345ae488ef8b61676fede4a867d7c3
af7cf96e4af83b483a300491f3cddc032431c164
af1f12c339e241d2ffd64f768d8c8e7e90871eca
95028d5befd1039cc4f3e0f3b923810bdd2d08fd
9f33ac915a4d71bd1b38fa4db7616e20111182c1
ff07ec217de7ead5f497b05fa1026aaf630978bf
ff07ec217de7ead5f497b05fa1026aaf630978bf
I think most of these are irrelevant. Anyway, that also failed to
reproduce the ICE with the shell rune looping over -v.
A possibly-relevant thing is that I normally run cargo build --locked.
In my repros above I had to run without --locked because some of these
commits update dependencies.
I think I have run out of sensible things to try but maybe you can
look at these commits and have a better go.
If you git fetch https://salsa.debian.org/iwj/hippotat the branch
ice.fingerprints.2021-08-08.reflogs-octopus contains a ref which has
all of the above as ancestors, so you should be able to see them all.
(The branch itself is not useful in other respects; I just made it
with a bunch of git-merge -s ours.)
FYI here is the manual for the magit wip mode:
https://magit.vc/manual/magit.html#Wip-Modes
I think it's unlikely that I made changes outside of Emacs.
Sorry not to be more useful....
Ian.
…--
Ian Jackson ***@***.***> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
|
|
I'm at a loss as to how this could have happened. There's not much data stored in I wonder if the incremental compilation data or crate metadata could have been corrupted on-disk. As far as I know, we don't have any protections against this. |
|
I've opened #87896 to detect corruption of crate metadata via a SHA-256 hash. |
|
Aaron Hill writes ("Re: [rust-lang/rust] unstable fingerprints, generics_of (#87860)"):
I wonder if the incremental compilation data or crate metadata could
have been corrupted on-disk. As far as I know, we don't have any
protections against this.
I'm pretty sure my laptop doesn't have disk corruption trouble
although if I'm fair rustc is one of the bigger stress tests of it.
But it is possible that the files were being written at the same time
as rustc was running. Ie, I might have saved a file in my eitor,
while a cargo invocation was ongoing. Could that produce this kind of
effect ?
Ian.
…--
Ian Jackson ***@***.***> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
|
|
@ijackson: Is it possible that you could have compiled the crate multiple times from different working directories (e.g. running |
|
Triage: Thank you for reporting ijackson. Without a way for others to reproduce the ICE, not much can be done at this point. though. Closing. Feel free to reopen if a way to reproduce is found. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi. I got one of these unstable fingerprint ICEs, with a nightly compiler from a few weeks ago. I'm not sure if this is a useful report; #84970 didn't really say whether it would be, nor precisely what to put in it. I assume there is no point trying a repro with a recent nightly.
I have preserved a copy of my
target/directory in case it will be useful. It's 2.9GB so do let me know when I can delete it :-).Code
https://salsa.debian.org/iwj/hippotat/-/tree/ice.fingerprints.2021-08-08
With the following compile rune:
(This is an out-of-tree build.)
Meta
rustc --version --verbose:Error output
Full output including backtrace
The text was updated successfully, but these errors were encountered: