Starting with nightly-2021-01-13 (1.51) rustc fails to build archives on Windows 7 #81051

MSxDOS · 2021-01-15T18:57:58Z

E.g. cargo check --verbose on https://github.com/japaric/ufmt

F:\ufmt-master>cargo check --verbose
   Compiling unicode-xid v0.2.1
       Fresh ufmt-write v0.1.0 (F:\ufmt-master\write)
     Running `rustc --crate-name unicode_xid F:\.cargo\registry\src\github.com-1ecc6299db9
ec823\unicode-xid-0.2.1\src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,art
ifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debuginfo=2 -
-cfg "feature=\"default\"" -C metadata=df09097284490053 -C extra-filename=-df0909728449005
3 --out-dir F:\ufmt-master\target\debug\deps -L dependency=F:\ufmt-master\target\debug\dep
s --cap-lints allow`
       Fresh proc-macro-hack v0.5.19
   Compiling proc-macro2 v1.0.24
     Running `rustc --crate-name proc_macro2 --edition=2018 F:\.cargo\registry\src\github.
com-1ecc6299db9ec823\proc-macro2-1.0.24\src\lib.rs --error-format=json --json=diagnostic-r
endered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no
-C debuginfo=2 --cfg "feature=\"default\"" --cfg "feature=\"proc-macro\"" -C metadata=b463
43984a7d2c00 -C extra-filename=-b46343984a7d2c00 --out-dir F:\ufmt-master\target\debug\dep
s -L dependency=F:\ufmt-master\target\debug\deps --extern unicode_xid=F:\ufmt-master\targe
t\debug\deps\libunicode_xid-df09097284490053.rmeta --cap-lints allow --cfg lexerror_displa
y --cfg hygiene --cfg use_proc_macro --cfg wrap_proc_macro --cfg proc_macro_span`
error: failed to build archive: permission denied

error: aborting due to previous error

error: could not compile `unicode-xid`

Caused by:
  process didn't exit successfully: `rustc --crate-name unicode_xid F:\.cargo\registry\src
\github.com-1ecc6299db9ec823\unicode-xid-0.2.1\src\lib.rs --error-format=json --json=diagn
ostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C embed-bitc
ode=no -C debuginfo=2 --cfg "feature=\"default\"" -C metadata=df09097284490053 -C extra-fi
lename=-df09097284490053 --out-dir F:\ufmt-master\target\debug\deps -L dependency=F:\ufmt-
master\target\debug\deps --cap-lints allow` (exit code: 1)
warning: build failed, waiting for other jobs to finish...
error: failed to build archive: permission denied

error: aborting due to previous error

error: build failed

rustc 1.51.0-nightly (e38fb306b 2021-01-14)
binary: rustc
commit-hash: e38fb306b7f5e65cca34df2dab1f0db15e1defb4
commit-date: 2021-01-14
host: x86_64-pc-windows-msvc
release: 1.51.0-nightly
LLVM version: 11.0

The text was updated successfully, but these errors were encountered:

tesuji · 2021-01-16T02:59:18Z

Cannot reproduce on Windows target on CI.
Maybe check you systems again.

MSxDOS · 2021-01-17T15:21:09Z

The failure happens on a Windows 7 x64 machine. I reproduced this on another machine running Windows 7 x86, this time with i686-pc-windows-gnu toolchain.

tesuji · 2021-01-17T15:38:34Z

I don't have any Windows machine to test (left alone Windows 7 which not available on CI).
All builds on Windows 10 with msvc and gnu toolchain succeeded: https://github.com/lzutao/ufmt/runs/1717188912?check_suite_focus=true

Let's ping Windows group to see if any folks can verify the issue:
@rustbot ping windows

rustbot · 2021-01-17T15:38:35Z

Error: Only Rust team members can ping teams.

Please let @rust-lang/release know if you're having trouble with this bot.

LeSeulArtichaut · 2021-01-17T16:40:34Z

@rustbot ping windows

rustbot · 2021-01-17T16:40:36Z

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

sivadeilra · 2021-01-17T17:43:08Z

Speaking for the Windows team at Microsoft, Windows 7 has reached End of Life. We're not interested in providing any further support for Win 7 development.

We (and members of the Rust community) are also actively working on min_api_target_version RFC, which would officially deprecate some older Windows platforms (those that are EOL) for Rust.

I realize that this position may not be satisfying. However, we have to draw the line somewhere on supporting old versions of OSes, and Windows 7 has reached its official EOL. You may still be able to target Windows 7, by cross-compiling (compiling on a modern Windows version, or by compiling on Linux targeting Windows).

sivadeilra · 2021-01-17T17:55:15Z

Also, you might check whether you have any anti-virus products installed. If so, try disabling them, or at least adding an exception that covers your development tree. Sometimes "permissions" problems are caused by anti-virus products opening and scanning executable files.

camelid · 2021-01-18T19:34:52Z

Apparently, Windows 7 is still a Tier 1 target, so even though it's EOL for Microsoft, Rust still has to support it. It seems that maybe we should reduce Windows 7 to a lower tier at some point soon.

KamilaBorowska · 2021-01-19T09:45:41Z

I would like to point out that according to Firefox Hardware Across the Web report, Windows 7 is used by 23% of Firefox users. Microsoft also offers paid extended security updates through January 2023 for Windows 7 which may be actually used in enterprise environments. I think it's too early to drop support for Windows 7.

That said, this particular issue feels like an issue with anti-virus. @MSxDOS, could you check whether this issue occurs with an antivirus product disabled?

asaadmohammed74 · 2021-01-19T10:51:30Z

I would like to point out that according to Firefox Hardware Across the Web report, Windows 7 is used by 23% of Firefox users. Microsoft also offers paid extended security updates through January 2023 for Windows 7 which may be actually used in enterprise environments. I think it's too early to drop support for Windows 7.

That said, this particular issue feels like an issue with anti-virus. @MSxDOS, could you check whether this issue occurs with an antivirus product disabled?

im having the same issue, i also use windows 7 x64. and don't have any anti virus installed

MSxDOS · 2021-01-19T15:47:12Z

could you check whether this issue occurs with an antivirus product disabled?

I've already checked and eliminated that from the list of possible causes along with any possible system issues I could think of. The problem appears on two machines with different hardware and software, one of which had a fresh installation of Rust toolchain via rustup and the issue appeared instantly.

There's not much I can draw from that cargo log. By the looks of it the issue happens with crates that depend on and use proc-macro crates. In some cases cargo check doesn't trigger it but cargo build does.

asaadmohammed74 · 2021-01-19T18:39:42Z

using RUSTC_LOG=debug
INFO rustc_codegen_ssa::back::link preparing rlib to "G:\\Development\\rust\\hello_world\\target\\debug\\deps\\libanyhow-a96d4d06084a2ac6.rlib

apiraino · 2021-01-20T13:48:28Z

@asaadmohammed74 and @MSxDOS just a blind shot, IIUC the error error: failed to build archive: permission denied suggests there's an issue when rustc tries to write on those volumes (F: and G:).

Does the user executing rustc have proper permission to those volumes? Does the error happens intermittently or it is always reproducible?

tmiasko · 2021-01-20T21:58:53Z

The commit range includes the update of LLVM submodule #80796, so it is probably caused by one of:

lzybkr · 2021-01-20T22:05:34Z

Permission denied sometimes means another process has an open handle to the file. Process Monitor has been useful to me in tracking down similar issues, which turned out to be an antivirus product in my case.

FredericaBernkastel · 2021-01-29T01:57:24Z

Downgraded to nightly-2021-01-12, compilation is successful again.

MSxDOS · 2021-01-29T03:02:55Z

@apiraino There are no issues with permissions on both machines... The error is always reproducible.

leafinsky-li · 2021-02-04T03:13:10Z

Downgraded to nightly-2021-01-12, compilation is successful again.
I encountered the same problem when upgrading the latest version. After downgrading this version, everything works fine again.

moxian · 2021-02-07T09:02:40Z

The issue title downplaying the problem a bit.
nightly-2021-01-14 and onward is unable to compile any library crate. I.e. running

rustc +nightly src/lib.rs --crate-type lib

on an empty lib.rs gives the same

error: failed to build archive: permission denied

error: aborting due to previous error

This makes rustc effectively unusable on windows 7. (except for binaries with zero non-proc-macro dependencies)

Here's what's happening, per process monitor:

I am neither windows, nor LLVM expert so i cannot really interpret it, but to transcribe what's happening (judging purely by the names of the winapi calls):

On stable:

we create the temporary libmain.rlib.temp-archive-6748ddf.a
write to it
SetDispositionInformationFile(Delete = False) (??)
rename it to libmain.rlib

very straightforward

On nightly many more things are happening and i'm not sure why:

We create the temporary libmain.rlib.temp-archive-d4be097.a
Open it and immediately close, multiple times with different arguments (??)
SetDispositionInformationFile(Delete = True) (????) (!!!)
Write to it
QueryOpen it, get told that DELETE_PENDING
give up.

Oh, and @tmiasko implied, but did not explicitly mention, the regression happened in #80960.

moxian · 2021-02-07T09:10:54Z

(Not sure if i have permission to do this, but..)
@rustbot modify labels: +I-prioritize

LeSeulArtichaut · 2021-02-07T09:20:56Z

Let's @rustbot ping llvm

cuviper · 2021-02-26T23:51:07Z

I opened rust-lang/llvm-project#92 to start, a simple revert which reportedly fixes this issue -- #81051 (comment).

… TempFile doesn't reside on a local drive" This reverts commit 79657e2. The change regressed on Windows 7 -- rust-lang/rust#81051

… TempFile doesn't reside on a local drive" This reverts commit 6ec777c, which was cherry picked to 11.x from 79657e2. The change regressed on Windows 7 -- rust-lang/rust#81051

… TempFile doesn't reside on a local drive" This reverts commit 79657e2. The change regressed on Windows 7 -- rust-lang/rust#81051

Revert LLVM D81803 because it broke Windows 7 This submodule update reverts <https://reviews.llvm.org/D81803>. While that change is meant to fix a real bug, [LLVM PR42623], it caused new permission errors on Windows 7 that make it unable to build any archives. This is probably the same root cause as [LLVM PR48378]. Fixes rust-lang#81051. We'll file a new Rust issue to track the LLVM resolution. [LLVM PR42623]: https://bugs.llvm.org/show_bug.cgi?id=42623 [LLVM PR48378]: https://bugs.llvm.org/show_bug.cgi?id=48378

moxian · 2021-03-01T01:12:47Z

I just want to confirm that the fix is in nightly, and it's working!

Thanks, @cuviper!

klensy · 2021-03-01T01:28:45Z

But while it not applied to beta, it can't build rust with download-ci-llvm = true, as it download beta files from 2021-02-14, or maybe i do something wrong.

moxian · 2021-03-01T01:34:22Z

Either setting your src/stage0.txt to have

date: 2021-02-28
rustc: nightly

or setting in your config.toml

[build]
rustc = "/path/to/nightly/toolchain/bin/rustc.exe"
cargo = "/path/to/nightly/toolchain/bin/cargo.exe"

should work

P.s.: correction: for some reason src/stage0.txt method does not work for me, but the config.toml does.

Although now that I re-read your message, i'm not sure if download-ci-llvm = true would further impact this. I.e. I don't know if the llvm on ci has the fix commit or not. But then again, download-ci-llvm = true seems to do nothing for me, as in I'm trying to run python x.py build and it's currently rebuilding llvm from source anyway, so..

cuviper · 2021-03-01T02:01:21Z

I'm not sure how that download is updated, but the PR is beta-nominated, so once that's approved we can backport it to the beta branch and then update master stage0.txt. Hopefully that will sort it out!

Mark-Simulacrum · 2021-03-01T02:20:35Z

Normally we only do so once a cycle, but we're happy to accept PRs if there's some reason to update it outside of that.

cuviper · 2021-03-01T19:43:14Z

See #82677 to track long-term resolution between Windows 7 and the reverted bug fix.

This submodule update reverts <https://reviews.llvm.org/D81803>. While that change is meant to fix a real bug, [LLVM PR42623], it caused new permission errors on Windows 7 that make it unable to build any archives. This is probably the same root cause as [LLVM PR48378]. Fixes rust-lang#81051. We'll file a new Rust issue to track the LLVM resolution. [LLVM PR42623]: https://bugs.llvm.org/show_bug.cgi?id=42623 [LLVM PR48378]: https://bugs.llvm.org/show_bug.cgi?id=48378 (cherry picked from commit 31814c4)

As reported here: https://bugs.llvm.org/show_bug.cgi?id=48378#c0 and here: rust-lang/rust#81051 since 79657e2, some programs such as llvm-ar don't work properly on Windows 7. The issue is shown in the snippet by Oleksandr Prodan: https://pastebin.com/v51m3uBU In essence, once the 'DeleteFile' flag has been set on FILE_DISPOSITION_INFO, the file path can't be queried anymore with GetFinalPathNameByHandleW. This however works on Windows 10, GetFinalPathNameByHandleW would return sucessfully. To workaround the issue, we simply reset the 'DeleteFile' flag before even checking if we're dealing with a network file. Tested with `llvm-ar r empty.a a.obj` ran on a network mount. At the moment, we cannot specifically add a test coverage for this, since it requres mounting a network drive.

aganea · 2021-03-24T19:40:54Z

Hello! I've fixed the issue in LLVM in llvm/llvm-project@64ab2b6 - please let me know if the issue is still there in the next code drop.

cuviper · 2021-03-24T20:06:51Z

Thanks @aganea! I don't have access to test this myself, but hopefully the Windows 7 users here can try it out. Let's collect further feedback on the new open issue, #82677.

As reported here: https://bugs.llvm.org/show_bug.cgi?id=48378#c0 and here: rust-lang/rust#81051 since 79657e2, some programs such as llvm-ar don't work properly on Windows 7. The issue is shown in the snippet by Oleksandr Prodan: https://pastebin.com/v51m3uBU In essence, once the 'DeleteFile' flag has been set on FILE_DISPOSITION_INFO, the file path can't be queried anymore with GetFinalPathNameByHandleW. This however works on Windows 10, GetFinalPathNameByHandleW would return sucessfully. To workaround the issue, we simply reset the 'DeleteFile' flag before even checking if we're dealing with a network file. Tested with `llvm-ar r empty.a a.obj` ran on a network mount. At the moment, we cannot specifically add a test coverage for this, since it requres mounting a network drive. (cherry picked from commit 64ab2b6)

As reported here: https://bugs.llvm.org/show_bug.cgi?id=48378#c0 and here: rust-lang/rust#81051 since 79657e2, some programs such as llvm-ar don't work properly on Windows 7. The issue is shown in the snippet by Oleksandr Prodan: https://pastebin.com/v51m3uBU In essence, once the 'DeleteFile' flag has been set on FILE_DISPOSITION_INFO, the file path can't be queried anymore with GetFinalPathNameByHandleW. This however works on Windows 10, GetFinalPathNameByHandleW would return sucessfully. To workaround the issue, we simply reset the 'DeleteFile' flag before even checking if we're dealing with a network file. Tested with `llvm-ar r empty.a a.obj` ran on a network mount. At the moment, we cannot specifically add a test coverage for this, since it requres mounting a network drive.

As reported here: https://bugs.llvm.org/show_bug.cgi?id=48378#c0 and here: rust-lang/rust#81051 since 79657e2, some programs such as llvm-ar don't work properly on Windows 7. The issue is shown in the snippet by Oleksandr Prodan: https://pastebin.com/v51m3uBU In essence, once the 'DeleteFile' flag has been set on FILE_DISPOSITION_INFO, the file path can't be queried anymore with GetFinalPathNameByHandleW. This however works on Windows 10, GetFinalPathNameByHandleW would return sucessfully. To workaround the issue, we simply reset the 'DeleteFile' flag before even checking if we're dealing with a network file. Tested with `llvm-ar r empty.a a.obj` ran on a network mount. At the moment, we cannot specifically add a test coverage for this, since it requres mounting a network drive. (cherry picked from commit 64ab2b6)

As reported here: https://bugs.llvm.org/show_bug.cgi?id=48378#c0 and here: rust-lang/rust#81051 since cf62b1d, some programs such as llvm-ar don't work properly on Windows 7. The issue is shown in the snippet by Oleksandr Prodan: https://pastebin.com/v51m3uBU In essence, once the 'DeleteFile' flag has been set on FILE_DISPOSITION_INFO, the file path can't be queried anymore with GetFinalPathNameByHandleW. This however works on Windows 10, GetFinalPathNameByHandleW would return sucessfully. To workaround the issue, we simply reset the 'DeleteFile' flag before even checking if we're dealing with a network file. Tested with `llvm-ar r empty.a a.obj` ran on a network mount. At the moment, we cannot specifically add a test coverage for this, since it requres mounting a network drive. (cherry picked from commit 1d96b47)

As reported here: https://bugs.llvm.org/show_bug.cgi?id=48378#c0 and here: rust-lang/rust#81051 since 79657e2339b58bc01fe1b85a448bb073d57d90bb, some programs such as llvm-ar don't work properly on Windows 7. The issue is shown in the snippet by Oleksandr Prodan: https://pastebin.com/v51m3uBU In essence, once the 'DeleteFile' flag has been set on FILE_DISPOSITION_INFO, the file path can't be queried anymore with GetFinalPathNameByHandleW. This however works on Windows 10, GetFinalPathNameByHandleW would return sucessfully. To workaround the issue, we simply reset the 'DeleteFile' flag before even checking if we're dealing with a network file. Tested with `llvm-ar r empty.a a.obj` ran on a network mount. At the moment, we cannot specifically add a test coverage for this, since it requres mounting a network drive.

MSxDOS added the C-bug Category: This is a bug. label Jan 15, 2021

rustbot added I-prioritize Issue: Indicates that prioritization has been requested for this issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 17, 2021

rustbot added the O-windows Operating system: Windows label Jan 17, 2021

apiraino added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed I-prioritize Issue: Indicates that prioritization has been requested for this issue. labels Jan 27, 2021

rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Feb 7, 2021

LeSeulArtichaut added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label Feb 7, 2021

cuviper mentioned this issue Feb 26, 2021

Revert "[Support] PR42623: Avoid setting the delete-on-close bit if a… rust-lang/llvm-project#93

Merged

cuviper mentioned this issue Feb 27, 2021

Revert LLVM D81803 because it broke Windows 7 #82605

Merged

bors closed this as completed in 31814c4 Feb 28, 2021

cuviper mentioned this issue Mar 1, 2021

Track Windows 7 vs. delete-on-close fixes #82677

Open

pineapplemachine mentioned this issue Mar 5, 2021

wasm-ld: error: failed to write the output file: permission denied emscripten-core/emscripten#13067

Open

SimonN mentioned this issue Apr 2, 2021

Merge LLVM's commit that fixes lld-link on Windows 7 and Wine ldc-developers/ldc#3691

Closed

moxian mentioned this issue May 24, 2021

Use lld by default on x64 msvc windows #71520

Open

6 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Starting with nightly-2021-01-13 (1.51) rustc fails to build archives on Windows 7 #81051

Starting with nightly-2021-01-13 (1.51) rustc fails to build archives on Windows 7 #81051

MSxDOS commented Jan 15, 2021 •

edited by rustbot

Loading

tesuji commented Jan 16, 2021

MSxDOS commented Jan 17, 2021

tesuji commented Jan 17, 2021

rustbot commented Jan 17, 2021

LeSeulArtichaut commented Jan 17, 2021

rustbot commented Jan 17, 2021

sivadeilra commented Jan 17, 2021 •

edited

Loading

sivadeilra commented Jan 17, 2021

camelid commented Jan 18, 2021

KamilaBorowska commented Jan 19, 2021 •

edited

Loading

asaadmohammed74 commented Jan 19, 2021

MSxDOS commented Jan 19, 2021

asaadmohammed74 commented Jan 19, 2021

apiraino commented Jan 20, 2021

tmiasko commented Jan 20, 2021

lzybkr commented Jan 20, 2021

FredericaBernkastel commented Jan 29, 2021

MSxDOS commented Jan 29, 2021

leafinsky-li commented Feb 4, 2021

moxian commented Feb 7, 2021 •

edited

Loading

moxian commented Feb 7, 2021

LeSeulArtichaut commented Feb 7, 2021

cuviper commented Feb 26, 2021 •

edited

Loading

moxian commented Mar 1, 2021

klensy commented Mar 1, 2021

moxian commented Mar 1, 2021 •

edited

Loading

cuviper commented Mar 1, 2021

Mark-Simulacrum commented Mar 1, 2021

cuviper commented Mar 1, 2021

aganea commented Mar 24, 2021

cuviper commented Mar 24, 2021

Starting with nightly-2021-01-13 (1.51) rustc fails to build archives on Windows 7 #81051

Starting with nightly-2021-01-13 (1.51) rustc fails to build archives on Windows 7 #81051

Comments

MSxDOS commented Jan 15, 2021 • edited by rustbot Loading

tesuji commented Jan 16, 2021

MSxDOS commented Jan 17, 2021

tesuji commented Jan 17, 2021

rustbot commented Jan 17, 2021

LeSeulArtichaut commented Jan 17, 2021

rustbot commented Jan 17, 2021

sivadeilra commented Jan 17, 2021 • edited Loading

sivadeilra commented Jan 17, 2021

camelid commented Jan 18, 2021

KamilaBorowska commented Jan 19, 2021 • edited Loading

asaadmohammed74 commented Jan 19, 2021

MSxDOS commented Jan 19, 2021

asaadmohammed74 commented Jan 19, 2021

apiraino commented Jan 20, 2021

tmiasko commented Jan 20, 2021

lzybkr commented Jan 20, 2021

FredericaBernkastel commented Jan 29, 2021

MSxDOS commented Jan 29, 2021

leafinsky-li commented Feb 4, 2021

moxian commented Feb 7, 2021 • edited Loading

moxian commented Feb 7, 2021

LeSeulArtichaut commented Feb 7, 2021

cuviper commented Feb 26, 2021 • edited Loading

moxian commented Mar 1, 2021

klensy commented Mar 1, 2021

moxian commented Mar 1, 2021 • edited Loading

cuviper commented Mar 1, 2021

Mark-Simulacrum commented Mar 1, 2021

cuviper commented Mar 1, 2021

aganea commented Mar 24, 2021

cuviper commented Mar 24, 2021

MSxDOS commented Jan 15, 2021 •

edited by rustbot

Loading

sivadeilra commented Jan 17, 2021 •

edited

Loading

KamilaBorowska commented Jan 19, 2021 •

edited

Loading

moxian commented Feb 7, 2021 •

edited

Loading

cuviper commented Feb 26, 2021 •

edited

Loading

moxian commented Mar 1, 2021 •

edited

Loading