Open cheako opened 4 years ago
I think this is the same situation as the other bug of yours I just analysed, where you've run rustup concurrently with either itself or with a cache-restore operation.
I'm not sure what a cache restore is. It should be noted that one bug report is about gitlab CI and this report is about a server ssh session and shell, vastly different scenarios and it would be surprising if they had something in common(although not impossible).
There is not another instance of rustup! There isn't any fancy caching going on as in the gitlab CI situation.
srv_websuite@olympus:~/src/websuite$ ps ax|grep rustup
5155 pts/0 S+ 0:00 grep rustup
srv_websuite@olympus:~/src/websuite$ rustup target add wasm32-wasi
info: downloading component 'rust-std' for 'wasm32-wasi'
info: installing component 'rust-std' for 'wasm32-wasi'
11.4 MiB / 11.4 MiB (100 %) 7.8 MiB/s in 1s ETA: 0s
info: rolling back changes
error: could not create link from '/home/srv_websuite/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/components' to '/home/srv_websuite/.rustup/tmp/vz5otjmh02m9vdk1_file'
error: caused by: File exists (os error 17)
Is this still occurring? I'm wondering if it was a bad component tarball.
I managed to find a code path that behaved in an ill mannered way. I don't think it's fine to say it's fixed if the solution is to ensure that the code is never run.
The code was run by the rustup binary. Is there some virtual machine where rustup runs code provided by the component tarball?
We haven't determined what happened yet, so I'm not claiming it is or is not fixed.
There is no virtual machine, though you could consider untarring a form of VM if you squint just right.
In terms of ill manner, rustup preserved it's pre and post conditions as far as I can tell from the information given: although it failed to install the requested component, it did not corrupt already installed components or toolchains.
Thus my question about whether we have a bad component tarball. Do you happen to know what nightly build you had installed?
@kinnison might have more insight here.
Don't know, Feb 4th 9AM CST? There is a lot of information in the trace, but I can't locate a version. There are hex encoded numbers, might they mean something?
Problem
Hmm, I've spoken English all my life but don't you think this is a high bar? It excludes those like me who have autism.
strace -f -e trace=file rustup target add wasm32-wasi
Notice the O_CREAT flag, this creates a file. This precludes the symlink from returning anything other than EEXIST(-1).
Steps
I doubt there are any steps, you'll likely have to find all the spot in the code where temporary symlinks are created for "components". I'm sure there are only a handful.
Possible Solution(s) This is likely a function that's rarely called that likely works perfectly on Windows.
Notes