-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
ReleaseMutex failed. WaitOne Id: {originalThreadId} Release Id: {releaseThreadId} in Microsoft.Extensions.Logging.Generators.Roslyn4.0 #63863
Comments
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsFound in a release/7.0 backport PR: dotnet/runtime#75284 Please help determine if this needs a fix to get backported to 7.0.
|
Tagging subscribers to this area: @dotnet/area-extensions-logging Issue DetailsFound in a release/7.0 backport PR: dotnet/runtime#75284 Please help determine if this needs a fix to get backported to 7.0.
|
Looks similar to dotnet/runtime#70836 . |
Should we run these tests on wasm/mobile at all? |
This is probably getting triggered because |
This is not even running any tests, it's failing while building. And the will only build - |
yeah this is a CSC crash it isn't really wasm related |
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:
|
|
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 Issue DetailsFound in a release/7.0 backport PR: dotnet/runtime#75284 Please help determine if this needs a fix to get backported to 7.0.
|
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
|
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: dotnet/runtime#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: dotnet/runtime#75284
Please help determine if this needs a fix to get backported to 7.0.
Build Browser wasm Linux Release _Threading_PerfTracing_BuildOnly
The text was updated successfully, but these errors were encountered: