-
Notifications
You must be signed in to change notification settings - Fork 10.3k
'The process cannot access the file' during CI build sometimes #32219
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
Comments
@JunTaoLuo this may be the start of the general issue around file contention in our builds that we discussed yesterday. |
We're hitting this somewhat frequently. Today there were two occurences: https://dev.azure.com/dnceng/public/_build/results?buildId=1172134&view=results, https://dev.azure.com/dnceng/public/_build/results?buildId=1172278&view=results |
Bin Logs: CI: Pipelines - https://dev.azure.com/dnceng/public/_build/results?buildId=1176795&view=artifacts&pathAsName=false&type=publishedArtifacts Commit Used: 0d75fcb Original Failure: https://dev.azure.com/dnceng/public/_build/results?buildId=1172134&view=results |
Thought someone considered putting up a PR to implement @rainersigwald's idea (thanks @rainersigwald). Was that #33565 @pranavkm❔ Given that's done, do we have additional monitoring to do to ensure we addressed the main problem or to find additional build contention problems❔ Basically wondering if we can close this or need an over-arching "our build contends w/ itself (ick ❕) issue❔ If we don't need to track other build ordering / contention issues (@Pilchie @dotnet/aspdoi your thoughts ❔), suggest closing this near the end of your ops rotation @BrennanConroy. |
Yeah, that was based on @rainersigwald's analysis. He had suggested making the outputs different, after playing around with it enough I realized we didn't need two sets of them. |
Today:
|
Not necessarily fixed yet, we've seen the issue on other projects other than just |
Do you know which other projects? Maybe just a matter of adding this to the appropriate references? |
|
Still failing on
https://github.com/dotnet/aspnetcore/pull/34033/checks?check_run_id=3013535904 Created PR to generate bin logs: #34189 |
And still failing on my PR: https://github.com/dotnet/aspnetcore/pull/33482/checks?check_run_id=3080384712 |
Failing in rolling builds too e.g. https://dev.azure.com/dnceng/public/_build/results?buildId=1242042&view=results
@HaoK thoughts on taking |
There are plenty more than this, this is just a few of the "cannot access the file" issues from the past couple days. Tests: Helix x64, Build shared fx
Tests: Helix x64, Build shared fx
Test: Windows 2016 x64, Run build.cmd
Test: macOS 10.15, Run build.sh
Tests: Helix x64, Build shared fx
Test: Windows Server 2016 x64, Run build.cmd
|
Have seen another variant of this in the last few days, most recently in validation of #37412. We're back to what #34137 should have fixed
|
FYI @agocke @vitek-karas @sbomer @dougbu - do you happen to have a binlog or repro steps to recreate the error? |
There's only one place we use memory mapping in the linker and it looks like that file hasn't changed since Aug 31, so it seems unlikely this is a linker change. |
Ah, rerun overwrote the _Logs artifact 😦 I got the dumps from the Windows_Test_Dumps artifact. Went looking there because we capture Might be interesting to include the attempt number in some of the artifact names❔ |
Looks like source build does that already. I think it's probably ok to do that - we would be increasing the amount of stuff we upload, but wouldn't be going beyond what one would typically expect (that is, we wouldn't be uploading more sets of logs than jobs ran. Whereas today we may upload fewer) |
Is:
the same issue, or should I create a new one? |
This remains a problem in some of our branches, especially release/5.0. We probably have fixes or partial fixes in 'main' that haven't been backported to either or both release/3.1 or release/5.0. Might even have a couple that aren't in release/6.0. For example, are the following everywhere they could be (and did they help 😃)❔ |
I think this problem is behind us in 'main' only question remaining is whether we need to backport some of the relevant fixes to servicing branches. Thoughts❔ |
I don't think I've seen this issue in servicing lately, but I'm not 100% sure. It definitely seems to be less prevalent, at least. |
I'm encountering this on edit Note that the runtime is Mono flavored, and so far the issue hasn't occured on |
@ayakael the problem is rather inconsistent and doesn't happen frequently. Building a second time is usually successful. |
The issue is that is guaranteed to happen at least once during the building process of dotnet7 for Alpine on s390x. As our builders restart the building process from scratch when there's a failure, it'll often take 5-6 full rebuilds before getting through. I'm more perplexed by it not being an issue on dotnet6, but suddently it is on dotnet7, suggesting a regression. |
I've reproduced this with ppc64le, thus seems to be specific to mono flavored runtime with dotnet7. This particular instance is with runtime: link Another failure with roslyn is shown here Usually, error appears as so:
Thus occurs during restore. Further research has shown that there are many different ways that this bug can occur, so it likely doesn't have to do with aspnetcore. Some pointers would be appreciated, though. |
I suggest examining a binary log and trying to determine what else is accessing the file. We don't use |
I think this is related to We were having this issue in our Github Actions build, so we added the I'm not sure if this is the solution, but it might help. Good luck! P.S: A Stackoverflow about this |
Closing as we haven't seen this in a while - will re-open if it comes back. |
We're still seeing this occasionally - @amcasey suggested trying to NoWarn |
This suggestion assumes, perhaps naively, that there's a different error code when the last retry fails. |
This has been happening a few times recently. It's odd because BlazorTemplates.Tests doesn't depend on Microsoft.DotNet.Web.Spa.ProjectTemplates so it shouldn't be copying it anywhere.
There is some custom msbuild logic being invoked right before the error: https://github.com/dotnet/aspnetcore/blob/main/src/ProjectTemplates/TestInfrastructure/PrepareForTest.targets
So maybe that has something to do with it. We might just need to add
/bl
to this part of the build temporarily.Example build:
https://dev.azure.com/dnceng/public/_build/results?buildId=1106179&view=logs&j=48c285a2-daf4-5ecb-cb99-42232769ca29&t=73646f8d-7520-5361-e1ad-d9d207b2cd21
The text was updated successfully, but these errors were encountered: