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
rustc panic! after refactoring a const variable using find #124469
Comments
Is the code available so we can try to reproduce the issue? |
I confirm I can reliably trigger the crash by building the project, using the command above to change the var name, and building again. The repository is currently in private, and I expect to open it in the coming weeks. If you like, I can try to reproduce on a dummy project. |
If you are able to, yes it'd be helpful, otherwise we won't be able to do much to investigate this. |
This looks like another situation where we fail to load a compiler output file because the file has been truncated, so the footer is invalid. Wise of whoever made the footer tag so distinctive, I can easily search for the tag in the issue tracker and it looks like we have 7 issues like this open and 4 were closed with a comment that makes it clear that the cause of the crash was never debugged or understood. |
Ah this is on 1.76. I'm inclined to not trust ICE reports about truncated files before 1.77, because before then I/O errors aren't reported as fatal, permitting later compilations to read output from a crashed compiler: #119510 Of course it's very possible that this issue is reporting a new and real bug, but this issue is based on a compiler with known-broken error reporting. |
@frochet After an ICE, how much free disk space is available? |
In your initial report you said
But also you can cause the compiler to crash in a reproducible way. What are you doing to reproduce the crash? And what filesystem is your target directory on? |
I can reproduce by changing the var name again e.g., doing these 4 steps is reproducible:
The filesystem is ext4. |
Does the issue reproduce if you don't modify the target dir and its internal files? |
No, the steps above while pruning the target directory too does not lead to a crash. I used the following:
Note that I forgot a step in the above description, where I restore the initial variable name (edited) |
Add a footer in FileEncoder and check for it in MemDecoder We have a few reports of ICEs due to decoding failures, where the fault does not lie with the compiler. The goal of this PR is to add some very lightweight and on-by-default validation to the compiler's outputs. If validation fails, we emit a fatal error for rmeta files in general that mentions the path that didn't load, and for incremental compilation artifacts we emit a verbose warning that tries to explain the situation and treat the artifacts as outdated. The validation currently implemented here is very crude, and yet I think we have 11 ICE reports currently open (you can find them by searching issues for `1002111927320821928687967599834759150` which this simple validation would have detected. The structure of the code changes here should permit the addition of further validation code, such as a checksum, if it is merited. I would like to have code to detect corruption such as reported in rust-lang#124719, but I'm not yet sure how to do that efficiently, and this PR is already a good size. The ICE reports I have in mind that this PR would have smoothed over are: rust-lang#124469 rust-lang#123352 rust-lang#123376 [^1] rust-lang#99763 rust-lang#93900. --- [^1]: This one might be a compiler bug, but even if it is I think the workflow described is pushing the envelope of what we can support
I believe I've triggered the following rustc panic after trying to refactor a pub const variable recursively from the root directory of the code:
find . \( -type d -name .git -prune \) -o -type f -print0 | xargs -0 sed -i 's/MY_VAR_NAME/MY_NEW_VAR_NAME/g'
cargo clean resolved it.
rustc --version --verbose
:Error output
The text was updated successfully, but these errors were encountered: