Skip to content
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

Stale results served up by sccache when rebasing #2169

Closed
vlovich opened this issue May 9, 2024 · 2 comments
Closed

Stale results served up by sccache when rebasing #2169

vlovich opened this issue May 9, 2024 · 2 comments

Comments

@vlovich
Copy link

vlovich commented May 9, 2024

I'm seeing this frequently although I'm not certain the exact set of steps to repro. When using sccache, I'll do a build, then initiate an interactive rebase & try building an older commit. The older commit throws up compiler errors because older code for some reason is getting compiled against newer APIs.

Configuration:
Linux 6.8.4
XFS filesystem
sccache 0.7.7

My project is a workspace project. I haven't been paying attention but I think that the failures aren't just when the API is in a different workspace crate (i.e. I believe I've seen failures for in-crate code).

Touching the files explicitly that sccache is serving as cached snapshots (i.e. not the file that's failing to compile but the file containing the API that is claimed to be misused) seems to fix the issue.

My hunch is that there's some kind of brittle mtime code that accidentally thinks a file hasn't been changed because it's older than what was compiled in the cache or something. I would hope though that the file size is checked before any mtime logic since mtime is more brittle than file size. Continuing this train of thought, on Linux filesystems that support it, even better than mtime would be to use the FS_IOC_GETVERSION ioctl when it's available (available on most Linux filesystems) which along with the inode would be a more reliable way to detect if file contents have changed without even needing to hash the file.

I originally thought it was a cargo bug (rust-lang/cargo#6529) but turning off sccache fixes the issue (+ that bug is about overbuilding, not building against a stale cache).

@Xuanwo
Copy link
Collaborator

Xuanwo commented May 9, 2024

It's a bit weird since sccache hashes the content of all input files:

sccache/src/compiler/rust.rs

Lines 1346 to 1359 in a092cfc

let source_files_and_hashes_and_env_deps = async {
let (source_files, env_deps) = get_source_files_and_env_deps(
creator,
&crate_name,
&executable,
&filtered_arguments,
&cwd,
&env_vars,
pool,
)
.await?;
let source_hashes = hash_all(&source_files, &source_hashes_pool).await?;
Ok((source_files, source_hashes, env_deps))
};

Could you create a reproducible example for me to investigate?

@vlovich
Copy link
Author

vlovich commented May 9, 2024

No, as I said it's really hard to figure out exactly how to reproduce it. Let's mark this as closed - maybe it's not sccache but rust-analyzer instead.

@vlovich vlovich closed this as completed May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants