-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Cargo gets lost in the root of a Linux filesystem #9528
Comments
@ehuss it seems strange to me that cargo looks at all files in the first place - I can look into adding --emit=dep-info to rustdoc if that would help. |
I prototyped an iterative version, but I don't feel comfortable about its complexity. 😞 |
Be resilient to most IO error and filesystem loop while walking dirs Let `PathSource::walk` be resilient to most IO errors and filesystem loop. This PR also - Add a test validating the resilience against filesystem loop to prevent regression. - Emit warning when filesystem loop found while walking the filesystem. This is the only way I can think of now to solve #9528 Fixes #10213.
…alexcrichton Be resilient to most IO error and filesystem loop while walking dirs Let `PathSource::walk` be resilient to most IO errors and filesystem loop. This PR also - Add a test validating the resilience against filesystem loop to prevent regression. - Emit warning when filesystem loop found while walking the filesystem. This is the only way I can think of now to solve rust-lang#9528 Fixes rust-lang#10213.
Faced the same issue during cargo build when I copy sources into root in docker. I see endless wall of warnings with the original repro. Workaround for me was to create directory and copy sources there instead of root. Will it be better to terminate with an error instead of being stuck ~forever with warnings? |
Problem
cargo doc
will mysteriously hang when run from the root of a Linux filesystem. The problem is that the fingerprinting code tries to find the file with the newest mtime by walking the entire filesystem. Unfortunately there are some paths that are infinite black holes.An example is
/sys/block
. This tree has a complex set of cyclical symbolic links. Cargo follows a cycle until it reaches ELOOP (too many symbolic links), and then starts following another cycle. There is a permutation of cycles, and so cargo essentially gets lost forever.I believe this also affects "old" style build scripts which also use
LocalFingerprint::Precalculated
.Steps
rust:latest
docker image.cargo init --name foo
cargo doc
. This step will never finish.Possible Solution(s)
Uncertain. A few ideas:
walkdir
for walking, which has symbolic link cycle detection.As a side note, another problem with the implementation is that it collects the path of every file it visits in memory. This is done with the assumption that
PathSource::list_files
will return a reasonable number of files. However, the mtime computation code doesn't need a full list, but instead just needs to know which file has the newest mtime. Perhaps that code could be changed to take a callback instead of accumulating all the files in memory.Notes
Output of
cargo version
:cargo 1.54.0-nightly (e931e47 2021-05-24)
Linux 4.19.121
The text was updated successfully, but these errors were encountered: