Open carlossanlop opened 2 years ago
Tagging subscribers to 'arch-wasm': @lewing See info in area-owners.md if you want to be subscribed.
Author: | carlossanlop |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `area-Extensions-Logging`, `source-generator` |
Milestone: | - |
Tagging subscribers to this area: @dotnet/area-extensions-logging See info in area-owners.md if you want to be subscribed.
Author: | carlossanlop |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `area-Extensions-Logging`, `source-generator` |
Milestone: | - |
@lewing @radical @steveisok @akoeplinger
Looks similar to https://github.com/dotnet/runtime/issues/70836 .
Should we run these tests on wasm/mobile at all?
This is probably getting triggered because src/libraries
has changes.
This is not even running any tests, it's failing while building. And the will only build - Build Browser wasm Linux Release _Threading_PerfTracing_BuildOnly
.
yeah this is a CSC crash it isn't really wasm related
error : One or more errors occurred. (ReleaseMutex failed. WaitOne Id: 12 Release Id: 12) [/__w/1/s/src/libraries/Microsoft.Extensions.Logging.Abstractions/gen/Microsoft.Extensions.Logging.Generators.Roslyn4.0.csproj]
Does this suggest something not supported on WASM?
There is no wasm running at all at this point, it looks like the generator failed for some reason.
Looks like it is coming from this line in Roslyn:
"/__w/1/s/.packages/microsoft.dotnet.arcade.sdk/7.0.0-beta.22418.4/tools/Build.proj" (default target) (1) ->
"/__w/1/s/Build.proj" (Build target) (3:2) ->
"/__w/1/s/src/libraries/oob.proj" (default target) (333) ->
"/__w/1/s/src/libraries/shims.proj" (default target) (334) ->
"/__w/1/s/src/libraries/shims/src/WindowsBase.csproj" (default target) (362) ->
"/__w/1/s/src/libraries/oob-src.proj" (default target) (339:23) ->
"/__w/1/s/src/libraries/Microsoft.Extensions.Caching.Memory/src/Microsoft.Extensions.Caching.Memory.csproj" (default target) (366:6) ->
"/__w/1/s/src/libraries/Microsoft.Extensions.Logging.Abstractions/src/Microsoft.Extensions.Logging.Abstractions.csproj" (default target) (389:7) ->
"/__w/1/s/src/libraries/Microsoft.Extensions.Logging.Abstractions/gen/Microsoft.Extensions.Logging.Generators.Roslyn4.0.csproj" (default target) (462:2) ->
(CoreGenerateSatelliteAssemblies target) ->
/__w/1/s/.dotnet/sdk/7.0.100-preview.7.22377.5/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(952,5): error MSB3883: Unexpected exception: [/__w/1/s/src/libraries/Microsoft.Extensions.Logging.Abstractions/gen/Microsoft.Extensions.Logging.Generators.Roslyn4.0.csproj]
/__w/1/s/.dotnet/sdk/7.0.100-preview.7.22377.5/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(952,5): error : One or more errors occurred. (ReleaseMutex failed. WaitOne Id: 12 Release Id: 12) [/__w/1/s/src/libraries/Microsoft.Extensions.Logging.Abstractions/gen/Microsoft.Extensions.Logging.Generators.Roslyn4.0.csproj]
Make sense @lewing.
Looking at the build analysis results too and I am seeing https://github.com/dotnet/runtime/pull/75284/checks?check_run_id=8258063425 all failures are on Mono only. This suggests specific to Mono.
Tagging subscribers to this area: @directhex See info in area-owners.md if you want to be subscribed.
Author: | carlossanlop |
---|---|
Assignees: | - |
Labels: | `arch-wasm`, `untriaged`, `area-Infrastructure-mono`, `source-generator` |
Milestone: | - |
There is no mono running at this point either, perhaps it is a linker bug that is breaking the generator?
Ok, it looks make sense to move this to Roslyn repo then.
Actually looking at this as @eerhardt points out it appears to be the compiler service breaking
cc @MattGal
Unhandled exception: System.IO.IOException: Connection timed out : 'Global\msbuild-server-launch-NDSZDEInz8s3G_evUwEeKheECB+4j1X89xWLxyQAqoU'
at System.Threading.Mutex.CreateMutexCore(Boolean initiallyOwned, String name, Boolean& createdNew)
at Microsoft.Build.Experimental.MSBuildClient.TryLaunchServer()
cc @MattGal
Unhandled exception: System.IO.IOException: Connection timed out : 'Global\msbuild-server-launch-NDSZDEInz8s3G_evUwEeKheECB+4j1X89xWLxyQAqoU' at System.Threading.Mutex.CreateMutexCore(Boolean initiallyOwned, String name, Boolean& createdNew) at Microsoft.Build.Experimental.MSBuildClient.TryLaunchServer()
I noted yesterday on an email thread that we'd seen problems that led to finding out that "MSBuild Server by default" was a new behavior on Linux, but I'd ping someone like @rokonec for subject-matter-expertise as I only know about this in the context of investigating build failures.
If it happens to be related to the server running where it didn't previously and you can get a local repro, setting DOTNET_CLI_DO_NOT_USE_MSBUILD_SERVER = true and seeing it stop reproducing will confirm it. It's possible this is a red herring, of course.
We actually have a quite long running tracking issue in runtime here: https://github.com/dotnet/runtime/issues/53420
According to runfo it fails about twice a week. Given how old the issue is and afaik we disabled the msbuild server in arcade recently I don't think it is related to that.
Found in a release/7.0 backport PR: https://github.com/dotnet/runtime/pull/75284
Please help determine if this needs a fix to get backported to 7.0.
Build Browser wasm Linux Release _Threading_PerfTracing_BuildOnly