-
Notifications
You must be signed in to change notification settings - Fork 13k
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
ICE on stable due to messed up target/ directory #124179
Comments
This is the truncated dep graph crash that I've been hunting. We get this particular ICE because the last few bytes of a dep graph file are supposed to be the length of a Vec and so if the file is truncated arbitrary bytes get reinterpreted as a length and when multiplied by the size of the element type, we get overflow. I'm assigning myself to keep track of such issues. What filesystem are you using? |
Btrfs |
@saethlin Maybe add a magic value at the end of the dep graph file and if that value is not present when decoding consider the incr comp session corrupt and ignore it? If the magic value is 16 random bytes, it is very unlikely that they will occur anywhere other than at the end, as such it would catch a truncated file with extremely high certainty. |
Yes that was suggested to me before. |
Such a check can detect this scenario but it cannot distinguish been a bug in the compiler and a problem with the environment. The fact that we weren't papering over such invalid files is what allowed me to fix multiple bugs that were in the compiler for over a year and were reported numerous times. I am not interested in just detecting invalid files and papering over the situation. |
Got a similar ICE - my computer frozen while cargo was building the project and upon rebooting and retrying got this. stacktrace
|
As far as I can tell, the ICE reported in this issue is caused by another process damaging rustc's build artifacts or by a buggy filesystem. That other process could be anything from an IDE running the compiler at the same time as a manual build to a find-and-replace that accidentally edits files in the target directory. #124686 contains a mitigation for this situation; the compiler now has a crude way to detect and ignore damaged incremental compilation files. You will still get a warning about the damaged file, but the build should proceed normally. That change shipped in Rust 1.80 which released today, so I am closing this issue and a few others which as far as I can tell all have the same root cause. You shouldn't see this ICE anymore, but please file a new issue if you see something like it on 1.80 or later. |
Code
I've had this once before on a different project. Something causes
target/
to get messed up (not me messing in target, rust does it on its own) and we get an ICE. It's almost impossible to reproduce. I'm just working in a large project and this specific target directory is messed up.cargo clean; cargo build
fixes it. However, I still wanted to report it. I made a backup of my specific target directory for those interested. An immediate close is also fine. I guess one clue might be that it happened after I rancargo fix
for the first time in a while? But that seems to be unrelated.(not including any rust code because I cannot minimize my example. It's just my specific target )
Meta
rustc --version --verbose
:Error output
I'm sorry I cannot give you more to go on except the target folder maybe? Let me know if that'd be useful to you. (zipped: 268M)
The text was updated successfully, but these errors were encountered: