Closed
Description
There have been a few instances of this error happening on CI:
= note: LINK : fatal error LNK1201: error writing to program database 'D:\a\rust\rust\build\i686-pc-windows-msvc\test\run-make-fulldeps\extern-flag-fun\extern-flag-fun\foo.pdb'; check for insufficient disk space, invalid path, or insufficient privilege
Or some variant of that. See:
- Revert 78373 ("dont leak return value after panic in drop") #81257 (comment)
- Remove usages of
expr_method_call
in derive(Ord,PartialOrd,RustcEncode,RustcDecode) #81411 (comment) - Box Item::Attributes #80802 (comment)
- remove allow(incomplete_features) from std #80591 (comment)
- Remove pointer comparison from slice equality #80209 (comment)
- Revert "cg_llvm:
fewer_names
inuncached_llvm_type
" #80122 (comment) - Use tcx.symbol_name when determining clashing extern declarations. #80009 (comment)
- Fix overflow when converting ZST Vec to VecDeque #80003 (comment)
(and probably many more)
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
copy[_nonoverlapping]()
debug-checks #90041[-]spurious CI error for i686 MSVC[/-][+]spurious CI error for MSVC[/+]kennytm commentedon Nov 13, 2021
Not just i686.
dist
command to match the components they generate #90684 (comment)dist
command to match the components they generate #906841 remaining item
hkratz commentedon Nov 28, 2021
The cargo test
lto::complicated
has been triggering this a lot lately. And cargo itself prints warnings, because the same .pdb file is written multiple times:So I guess something locks the file after it is written so it can't be overwritten shortly thereafter. Can the test be updated not to do this?
ehuss commentedon Nov 29, 2021
@hkratz I'm looking into fixing that test (and doing some other collision stuff).
I'm also trying to dig into
LNK1201
. Most of the errors seem to be on tests that build the same crate twice in a row. Unfortunately everything I've tried to reproduce it haven't succeeded.Just on the off chance we can find someone who wants to help:
@rustbot ping windows
This issue is causing significant trouble on CI, and I'm having a hard time making progress on it. A huge help would be if someone can find some way to reproduce it. I've tried running
rustc -g
in a loop, but I can't trigger the error. A really trivial test that triggered this error in the past is https://github.com/rust-lang/rust/blob/master/src/test/run-make-fulldeps/override-aliased-flags/Makefile.rustbot commentedon Nov 29, 2021
Hey Windows Group! This bug has been identified as a good "Windows candidate".
In case it's useful, here are some instructions for tackling these sorts of
bugs. Maybe take a look?
Thanks! <3
cc @arlosi @danielframpton @gdr-at-ms @kennykerr @luqmana @lzybkr @nico-abram @retep998 @rylev @sivadeilra @wesleywiser
hkratz commentedon Nov 29, 2021
@ehuss Great! I wrote a little script to grep through the CI logs and of the last 30 failed msvc runs which had LNK1201 in it all failed at
lto::complicated
. So fixing this test will solve this for us.The script for reference (excuse my Python, not a Python native):
Auto merge of #10137 - ehuss:lto-pdb-collision-test, r=alexcrichton
wesleywiser commentedon Nov 29, 2021
I talked with an engineer internally and they said that LNK1201 most often occurs because some program has a lock on the file. I don't know what the configuration of the GH runners looks like but perhaps Windows Defender (or similar AV/AM software) is scanning the file right after the linker finishes writing it the first time?
Regardless, rust-lang/cargo#10137 looks like the correct approach to resolving this to me. Thanks @ehuss!
ematipico commentedon Aug 25, 2023
I tried to upgrade the toolchain to rust
1.72.0
and I hit this issue: https://github.com/biomejs/biome/actions/runs/5975779047/job/16212389309?pr=66Interestingly, this issue occurs only when running tests using
nextest
.nandin-borjigin commentedon Jul 31, 2024
@wesleywiser, did you mean [rust-lang/cargo#10137] is a fix only to the CI error mentioned in this issue, or is it supposed to fix the transient LNK1201 errors (due to something, most likely MsDefender, locking the artifacts) for all cases?
I assume you meant the former, right? Do we have an issue tracking the LNK1201 that happens (occasionally) even though there is not colliding artifacts?
ehuss commentedon Sep 8, 2024
I'm going to close as I do not think we have been hitting LNK1201 errors in a while. I don't know what happened with the
extern-flag-fun
test, but hopefully this is a thing of the past.