assemblyloading_assemblylocationnotadded always failed in Linux #66621
Comments
dotnet-issue-labeler
bot
added
Area-Interactive
untriaged
|
Note: This is merged into main #66492 The stack trace is: Another example run https://dev.azure.com/dnceng-public/public/_build/results?buildId=154270&view=results |
|
cc @jaredpar |
|
Context on this failure. The code that introduced this failure was merged in #66492. During the review of that change we saw one test consistently failing on Linux and followed up with the runtime team in dotnet/runtime#81108. Once we confirmed there was a bug over there we disabled that test on Linux, continued working on the PR and didn't see any future issues. The PR was merged with several clean green runs. Post merge we saw a different test fail on Linux. That was disabled and then another one started failing. At that point @Cosifne and I decided to just stop these tests running on Linux as fast as possible to get the builds moving again (c3afa4e). It's unclear exactly what happened post merge to cause this to spread to most Linux runs. My suspicion is test partitioning changed such that it put more pressure on the underlying runtime issue resulting in wider spread failures. No evidence to back this up though, just a suspicion. The PR #66612 reduces the compilation calls which appear to be putting pressure on the runtime by ~95%. Hopefully that will allow us to re-enable the Linux runs. |
jaredpar
added a commit
to jaredpar/roslyn
that referenced
this issue
Jan 31, 2023
This also has the added benefit that the entire .NET Core set of tests run in less than one second. Previously it close to half a second per test. This will hopefully alleviate the pain for the runtime issue we're hittnig running `AssemblyLoadContext` tests in CI. This reduces the amount of compilations on this code path which seem to be the trigger for the failure. - dotnet#66621 - dotnet/runtime#81108
jaredpar
added a commit
to jaredpar/roslyn
that referenced
this issue
Feb 1, 2023
This also has the added benefit that the entire .NET Core set of tests run in less than one second. Previously it close to half a second per test. This will hopefully alleviate the pain for the runtime issue we're hittnig running `AssemblyLoadContext` tests in CI. This reduces the amount of compilations on this code path which seem to be the trigger for the failure. - dotnet#66621 - dotnet/runtime#81108
jaredpar
added a commit
to jaredpar/roslyn
that referenced
this issue
Feb 1, 2023
This also has the added benefit that the entire .NET Core set of tests run in less than one second. Previously it close to half a second per test. This will hopefully alleviate the pain for the runtime issue we're hittnig running `AssemblyLoadContext` tests in CI. This reduces the amount of compilations on this code path which seem to be the trigger for the failure. - dotnet#66621 - dotnet/runtime#81108
jaredpar
added a commit
to jaredpar/roslyn
that referenced
this issue
Feb 2, 2023
This also has the added benefit that the entire .NET Core set of tests run in less than one second. Previously it close to half a second per test. This will hopefully alleviate the pain for the runtime issue we're hittnig running `AssemblyLoadContext` tests in CI. This reduces the amount of compilations on this code path which seem to be the trigger for the failure. - dotnet#66621 - dotnet/runtime#81108
jaredpar
pushed a commit
that referenced
this issue
Feb 2, 2023
* Continued analyzer assembly loading work This change responds to several concerns raised in #66492: - Collapse the `AnalyzerAssembyLoader` hierarchy by one level and move more logic into the base type. - Fix `AssemblyLoadContext` in tests to not replicate types. That means we can safely pass `ITestOutputHelper` into the custom `AssemblyLoadContext` - Further strengthen the test separation I have deliberately not changed the file names to reflect the new type names because I wanted the review process to be smooth. Once I have two sign offs for the change I will send another commit which does the following: - Rename - DefaultAnalyzerAssemblyLoaderTests.cs -> AnalyzerAssemblyLoaderTests.cs - DefaultAnalyzerAssemblyLoader.Core.cs -> AnalyzerAssemblyLoader.Core.cs - DefaultAnalyzerAssemblyLoader.Desktop.cs -> AnalyzerAssemblyLoader.Desktop.cs - DefaultAnalyzerAssemblyLoader.cs -> AnalyzerAssemblyLoader.cs - Move - `DefaultAnalyzerAssemblyLoader` into DefaultAnalyzerAssemblyLoader.cs - `InvokeUtil` to InvokeUtil.cs. As constructed every edit to this type causes Test Explorer to lose context on the theory branches. Doesn't come back until rebuild. Will be smoother editting in its own file. That should get is into the style we expect here. After that I will merge once tests are green. * Unload AssemblyLoadContext after test completion * Reuse AssemblyLoadTestFixture across test runs This also has the added benefit that the entire .NET Core set of tests run in less than one second. Previously it close to half a second per test. This will hopefully alleviate the pain for the runtime issue we're hittnig running `AssemblyLoadContext` tests in CI. This reduces the amount of compilations on this code path which seem to be the trigger for the failure. - #66621 - dotnet/runtime#81108 * Apply suggestions from code review Co-authored-by: Rikki Gibson <[email protected]> * PR feedback * rename the files * Fixup --------- Co-authored-by: Rikki Gibson <[email protected]>
arunchndr
removed
the
untriaged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Runfo Tracking Issue: assemblyloading_assemblylocationnotadded always failed in Linux
Build Result Summary
The text was updated successfully, but these errors were encountered: