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
Incompatibility with sccache on long builds #87
Comments
Fix released as v0.5.5 |
I cannot reproduce the issue on actual cargo install sccache --version=0.3.1 # latest as of this writing
cargo install cargo-auditable --version=0.5.4 # latest version that's NOT fixed
git clone https://github.com/mozilla/sccache # a large Rust project
cd sccache
export RUSTC_WRAPPER="$(which sccache)"
cargo auditable build -j1 --release # because of -j1 this takes over 10 minutes with a cold cache |
The real question I'm trying to answer is whether the workaround I've added in 1aef302 is actually necessary; that is, when I suspect that it preserves the environment, so relying on the environment variables alone is sufficient, but I don't want to make any changes without testing them. |
I can't reproduce when building sccache either... - strace shows that cargo also does a cached rustc call at https://github.com/rust-lang/cargo/blob/70898e522116f6c23971e2a554b2dc85fd4c84cd/src/cargo/core/compiler/build_context/target_info.rs#L214, and that affects the window condition too. |
@Shnatsel I was able to reproduce this in cargo-quickinstall CI when compiling It still fails due to:
|
From this CI with backtrace:
|
Here is the |
The process invocation:
|
Fun but probably unrelated fact: if I run |
@NobodyXu the issue you're hitting seems to be a novel one. I admit I am confused by the "no such file or directory" error when invoking |
Also, could you confirm that building without |
Ah, I think I know what the problem is. Based on this command, it seems that I'll have a branch with a fix up for testing shortly. |
I've opened #111 which should fix it. I'd appreciate if you could test it and confirm that it indeed fixes the issue before I cut a release. |
Okay, apparently #111 didn't help. To make matters worse, it only fails on Mac - the Linux build works just fine. So I won't even be able to reproduce it because I don't have any Apple hardware. I think the best way to proceed is to run |
@Shnatsel I was able to use
|
Thanks! I'm afraid it didn't follow forks, you'll need a more advanced command: That should follow subprocesses and capture only the relevant syscalls. Thanks for all the help in debugging this, by the way! |
Somehow
|
@Shnatsel Ok I got the strace output for children from this CI:
|
It's getting late in my timezone, so I'll investigate the log and try to reproduce tomorrow. Thank you! |
You are welcome! |
I also tried upgrading |
I can reproduce this locally when running the command from #87 (comment) Thanks for getting me to this point. The rest should be "just" debugging. |
This is a bug in It appears that There's nothing I can do to fix this in |
Ah, the |
I've also opened #112 to print a more debuggable error when this happens. |
Thank you for taking your time for this issue! |
When using
cargo auditable
withsccache
, cargo auditable sometimes panics. We're seeing that panic on long (5> mins) builds:Running under strace shows that sccache is running
/path/to/cargo-auditable rustc -vV
when compiling a workspace member. Normally sccache runs this when compiling a dependency, and caches the information. On larger builds that cache expires causing sccache to run that command when compiling a workspace member, causing the panicThe panic can trivially by reproduced with
or by creating a new project without any dependencies and building with sccache and cargo auditable:
The text was updated successfully, but these errors were encountered: