Restore failure due to The process cannot access the file x because it is being used by another process on Mono
#12242
Labels
Comments
ayakael
changed the title
The process cannot access the file x because it is being used by another processThe process cannot access the file x because it is being used by another process on Mono
|
A workaround that seems to work is setting It is quite odd that this is not an issue on |
|
From the stacktrace: while trying to create a directory, it looks like some syscall ( It could be filesystem related. You could try to patch: to and see if that makes any difference. |
None it seems: dotnet7-stage0-runtime.binlog.log |
|
I haven't seen this particular error, no. However, if you still see this with Tom's patch applied (to the bootstrap SDK, of course), something is very weird. The error message can only occur if MkDir returns with errno set to EAGAIN/EWOULDBLOCK (which is the same numerical value). But with the patch, MkDir will never return with such an errno value, so something is weird. |
Indeed I did. I'll try a full rebuild of the bootstrap SDK and come back to you. Maybe something went wrong in my patching methodology. I did this quickly in between two other tasks. |
|
@ayakael if you'll rebuild, can you patch |
Patching System.IO.IOException: The process cannot access the file '/builds/ayakael/aports/testing/dotnet7-stage0/src/dotnet-v7.0.100-rtm.22521.12/src/sdk/artifacts/.nuget/packages/microsoft.bcl.asyncinterfaces/5.0.0/lib/net461' because it is being used by another process.
at System.IO.FileSystem.CreateDirectory(String fullPath, UnixFileMode unixCreateMode)
at System.IO.FileSystem.CreateDirectory(String fullPath)
at System.IO.Directory.CreateDirectory(String path)
at NuGet.Packaging.PackageFileExtractor.ExtractPackageFile(String source, String target, Stream stream)
at NuGet.Packaging.PackageArchiveReader.CopyFiles(String destination, IEnumerable`1 packageFiles, ExtractPackageFileDelegate extractFile, ILogger logger, CancellationToken token)
at NuGet.Packaging.PackageReaderBase.CopyFilesAsync(String destination, IEnumerable`1 packageFiles, ExtractPackageFileDelegate extractFile, ILogger logger, CancellationToken cancellationToken)
at NuGet.Packaging.PackageExtractor.<>c__DisplayClass5_0.<<InstallFromSourceAsync>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at NuGet.Common.ConcurrencyUtilities.<ExecuteWithFileLockedAsync>d__5`1[[System.Boolean, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].MoveNext()
at NuGet.Common.ConcurrencyUtilities.<ExecuteWithFileLockedAsync>d__5`1[[System.Boolean, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].MoveNext()
at NuGet.Packaging.PackageExtractor.InstallFromSourceAsync(PackageIdentity packageIdentity, IPackageDownloader packageDownloader, VersionFolderPathResolver versionFolderPathResolver, PackageExtractionContext packageExtractionContext, CancellationToken token, Guid parentId)
at NuGet.Commands.ProjectRestoreCommand.InstallPackageAsync(RemoteMatch installItem, NuGetv3LocalRepository userPackageFolder, PackageExtractionContext packageExtractionContext, CancellationToken token)
at NuGet.Commands.ProjectRestoreCommand.<>c__DisplayClass15_1.<<InstallPackagesAsync>b__4>d.MoveNext()
--- End of stack trace from previous location ---
at NuGet.Commands.ProjectRestoreCommand.InstallPackagesAsync(HashSet`1 uniquePackages, IEnumerable`1 graphs, IList`1 downloadDependencyInformations, NuGetv3LocalRepository userPackageFolder, CancellationToken token)
at NuGet.Commands.ProjectRestoreCommand.TryRestoreAsync(LibraryRange projectRange, IEnumerable`1 frameworkRuntimePairs, NuGetv3LocalRepository userPackageFolder, IReadOnlyList`1 fallbackPackageFolders, RemoteDependencyWalker remoteWalker, RemoteWalkContext context, Boolean forceRuntimeGraphCreation, CancellationToken token, TelemetryActivity telemetryActivity, String telemetryPrefix)
at NuGet.Commands.RestoreCommand.ExecuteRestoreAsync(NuGetv3LocalRepository userPackageFolder, IReadOnlyList`1 fallbackPackageFolders, RemoteWalkContext context, CancellationToken token, TelemetryActivity telemetryActivity)
at NuGet.Commands.RestoreCommand.ExecuteAsync(CancellationToken token)
at NuGet.Commands.RestoreRunner.ExecuteAsync(RestoreSummaryRequest summaryRequest, CancellationToken token)
at NuGet.Commands.RestoreRunner.ExecuteAndCommitAsync(RestoreSummaryRequest summaryRequest, IRestoreProgressReporter progressReporter, CancellationToken token)
at NuGet.Commands.RestoreRunner.CompleteTaskAsync(List`1 restoreTasks)
at NuGet.Commands.RestoreRunner.RunAsync(IEnumerable`1 restoreRequests, RestoreArgs restoreArgs, CancellationToken token)
at NuGet.Commands.RestoreRunner.RunAsync(RestoreArgs restoreContext, CancellationToken token)
at NuGet.Build.Tasks.BuildTasksUtility.RestoreAsync(DependencyGraphSpec dependencyGraphSpec, Boolean interactive, Boolean recursive, Boolean noCache, Boolean ignoreFailedSources, Boolean disableParallel, Boolean force, Boolean forceEvaluate, Boolean hideWarningsAndErrors, Boolean restorePC, Boolean cleanupAssetsForUnsupportedProjects, ILogger log, CancellationToken cancellationToken) |
|
Well - my workaround seems to have failed me on this run, and there's no stacktrace now: 00:19:35.789 24:15>Project "/builds/ayakael/aports/testing/dotnet7-stage0/src/dotnet-v7.0.100-rtm.22521.12/src/sdk/src/Microsoft.Win32.Msi/Microsoft.Win32.Msi.csproj" (24:15) is building "/builds/ayakael/aports/testing/dotnet7-stage0/src/dotnet-v7.0.100-rtm.22521.12/src/sdk/src/Microsoft.Win32.Msi/Microsoft.Win32.Msi.csproj" (24:16) on node 64 (UpdateXlf target(s)).
00:19:36.809 75:2>Task "AllowEmptyTelemetry" (TaskId:26)
00:19:36.221 31:17>/builds/ayakael/aports/testing/dotnet7-stage0/src/nuget/microsoft.dotnet.xlifftasks/1.0.0-beta.22427.1/build/Microsoft.DotNet.XliffTasks.targets(46,5): error MSB3191: Unable to create directory "/builds/ayakael/aports/testing/dotnet7-stage0/src/dotnet-v7.0.100-rtm.22521.12/src/sdk/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/Release/net7.0/Microsoft.NET.Build.Tasks.xlf/". The process cannot access the file '/builds/ayakael/aports/testing/dotnet7-stage0/src/dotnet-v7.0.100-rtm.22521.12/src/sdk/artifacts/obj/Release/Sdks/Microsoft.NET.Sdk/tools/Release/net7.0' because it is being used by another process. [/builds/ayakael/aports/testing/dotnet7-stage0/src/dotnet-v7.0.100-rtm.22521.12/src/sdk/src/Tasks/Microsoft.NET.Build.Tasks/Microsoft.NET.Build.Tasks.csproj:: TargetFramework=net7.0]
00:19:37.237 11:12>_CheckAndUnsetUnsupportedPrefer32Bit: (TargetId:68)I'm trying now to use both the above patches + (well duh cause for some reason I went from |
erdembayar
added
Functionality:Restore
Platform:Mono
|
Stuff gets weirder and weirder. Hopefully more data points will help triangulate this issue. Another restore-related failure when building arcade: This might be another musl-specific bug if threading is involved and the bug isn't reproducible on glibc. The regressive nature of this puzzles me. |
|
I gave up on edit Nevermind, |
|
There's a lot going on in this thread, and just skimming over the thread I don't follow everything, but I feel like this points to a bug in the mono runtime. The docs for Corelib's Doesn't this imply that Mono is doing something different than CoreCLR, and has behaviour not defined in the docs, so is where the bug is? I feel like the bug report in dotnet/runtime would be more appropriate than here in NuGet/Home. |
Copy that, we'll move this back to runtime land. I had first thought it was runtime, but then stuff pointed towards nuget, but now it looks to be back to runtime. Thanks for the help! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
NuGet Product Used
dotnet.exe
Product Version
7.0.100
Worked before?
6.0.111
Impact
It's more difficult to complete my work
Repro Steps & Context
Description
When building runtime with mono-flavored runtime, restore often fails in CI environment with
The process cannot access the file x because it is being used by another process. This affects runtime, as well as other builds (confirmed roslyn), thus specificity to runtime is that this does not occur on coreclr-flavored runtime.This thus affects
s390xandppc64leplatforms, being mono-flavored runtimes. For some reason, the error occurs more often onppc64le. This was first reported in dotnet/runtime#77364, and it seems to relate to src/NuGet.Core/NuGet.Common/ConcurrencyUtilities.cs.Reproduction Steps
In an Alpine Edge
linux-musl-x64environment, you can use this modified aport to reproduce bug. Following steps to reproduce:git clone https://gitlab.alpinelinux.org/ayakael/aports -b dotnet7/mono-restore cd aports/testing/dotnet7-stage0 abuild deps unpack prepare buildIt should eventually fail.
The aport builds a minimum set of components (runtime-mono, roslyn, sdk, aspnetcore, installer) to be able to build an SDK tar, then using that produced tarball with mono-flavored runtime it builds the whole stack again. This aport is usually used to crossbuild to other platforms, but in this case I am using it to easily reproduce the bug.
You'd likely be able to reproduce this on
linux-x64by building runtime with/p:PrimaryRuntimeFlavor=Monoand trying to build runtime with produced artifacts.Expected behavior
Restore should occur without issue
Actual behavior
Restore fails with error.
Verbose Logs
Binary logs
runtime:
runtime.binlog.log
roslyn
dotnet7-stage0-roslyn.binlog.log
The text was updated successfully, but these errors were encountered: