-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Crossgen2 has been failing to load 'Microsoft.DiaSymReader.Native' #69743
Comments
As a first course of action we need to fix this TODO in Line 191 in b59c649
I'll take a look at that today. |
@agocke's comment in dotnet/aspnetcore#41891 (comment) pointed me in the right direction (there's no Microsoft.DiaSymReader.Native on disk) - I think once #69842 is merged, we would just see "module not found". Andy's comment saved us time waiting for that error message and digging into why Windows can't find the file. The problem is this: using System;
using System.Reflection;
using System.Runtime.InteropServices;
class Program
{
[DllImport("none")]
static extern void None();
static void Register()
{
NativeLibrary.SetDllImportResolver(typeof(Program).Assembly, DllImportResolver);
}
private static IntPtr DllImportResolver(string libraryName, Assembly assembly, DllImportSearchPath? searchPath)
{
Console.WriteLine("Resolving...");
return IntPtr.Zero;
}
static void Main()
{
Register();
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
None();
}
} The above program never prints "Resolving" because we collect the System.Reflection.Assembly instance that was associated with the resolver. Assembly instances have a different lifetime on NativeAOT (they can be collected) vs on CoreCLR (we keep them forever, or until unload of the assembly load context, I guess). We cannot keep these in a ConditionalWeakTable on NativeAOT or they'll be collected too early: runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/NativeLibrary.cs Lines 181 to 187 in cf36aae
|
Can we make runtime Assembly objects non-collectible, just like they are in CoreCLR? There is very likely other code out there that makes this same assumption about the lifetimes. |
This matches the policy used by all other runtime flavors. Fixes dotnet#69743
This matches the policy used by all other runtime flavors. Fixes #69743
Description
Crossgen2 has started occasionally failing on aspnetcore CI builds. The earliest failure I found was on 5/5/22, but we've seen 10+ failures since then.
Reproduction Steps
Sadly, the most minimal steps I've been able to repro the issue with is run a CI build of the aspnetcore repo a couple times.
One odd thing I noticed is that when I capture a binlog while trying to reproduce the error I've never been able to repro the failure. Might imply some sort of race which doesn't happen when the machine is slower due to creating a binlog...
Expected behavior
crossgen2.exe to succeed 100% of the time
Actual behavior
Regression?
Yes, we haven't seen crossgen errors in a long time. And started seeing them ~5/5/22. Which is suspiciously close to when a change went in to switch crossgen to AOT: #67636
Known Workarounds
No response
Configuration
No response
Other information
No response
The text was updated successfully, but these errors were encountered: