AccessViolationException in ILLink in .NET 7

[jonathanpeppers]

We have a integration test that builds 100 class libraries for use in an Android app. This works most of the time, but sometimes on Windows we hit:

    Fatal error. System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
       at Mono.Cecil.MetadataReader.RangesSize(Mono.Cecil.Range[])
       at Mono.Cecil.MetadataReader.ReadCustomAttributes(Mono.Cecil.ICustomAttributeProvider)
       at Mono.Cecil.Mixin+<>c.<GetCustomAttributes>b__13_0(Mono.Cecil.ICustomAttributeProvider, Mono.Cecil.MetadataReader)
       at Mono.Cecil.ModuleDefinition.Read[[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=7.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]](System.__Canon ByRef, System.__Canon, System.Func`3<System.__Canon,Mono.Cecil.MetadataReader,System.__Canon>)
       at Mono.Cecil.Mixin.GetCustomAttributes(Mono.Cecil.ICustomAttributeProvider, Mono.Collections.Generic.Collection`1<Mono.Cecil.CustomAttribute> ByRef, Mono.Cecil.ModuleDefinition)
       at Mono.Cecil.MethodDefinition.get_CustomAttributes()
       at Microsoft.Android.Sdk.ILLink.ApplyPreserveAttribute.GetPreserveAttributes(Mono.Cecil.ICustomAttributeProvider)
       at Microsoft.Android.Sdk.ILLink.ApplyPreserveAttribute.MarkMethodIfPreserved(Mono.Cecil.MethodDefinition)
       at Microsoft.Android.Sdk.ILLink.ApplyPreserveAttribute.ProcessMethod(Mono.Cecil.MethodDefinition)
       at Mono.Linker.Steps.MarkSubStepsDispatcher.DispatchMethod(Mono.Cecil.MethodDefinition)
       at Mono.Linker.Steps.MarkSubStepsDispatcher.BrowseTypes(Mono.Collections.Generic.Collection`1<Mono.Cecil.TypeDefinition>)
       at Mono.Linker.Steps.MarkSubStepsDispatcher.BrowseTypes(Mono.Collections.Generic.Collection`1<Mono.Cecil.TypeDefinition>)
       at Mono.Linker.Steps.MarkSubStepsDispatcher.BrowseAssembly(Mono.Cecil.AssemblyDefinition)
       at Mono.Linker.Steps.MarkSubStepsDispatcher.<Initialize>b__5_0(Mono.Cecil.AssemblyDefinition)
       at Mono.Linker.Steps.MarkStep.MarkAssembly(Mono.Cecil.AssemblyDefinition, Mono.Linker.DependencyInfo)
       at Mono.Linker.Steps.MarkStep.MarkModule(Mono.Cecil.ModuleDefinition, Mono.Linker.DependencyInfo)
       at Mono.Linker.Steps.MarkStep.MarkType(Mono.Cecil.TypeReference, Mono.Linker.DependencyInfo, System.Nullable`1<Mono.Linker.MessageOrigin>)
       at Mono.Linker.Steps.MarkStep.ProcessMarkedPending()
       at Mono.Linker.Steps.MarkStep.Initialize()
       at Mono.Linker.Steps.MarkStep.Process(Mono.Linker.LinkContext)
       at Mono.Linker.Pipeline.ProcessStep(Mono.Linker.LinkContext, Mono.Linker.Steps.IStep)
       at Mono.Linker.Pipeline.Process(Mono.Linker.LinkContext)
       at Mono.Linker.Driver.Run(Mono.Linker.ILogger)
       at Mono.Linker.Driver.Main(System.String[])
    Errors
        C:\a\_work\1\s\bin\Release\dotnet\sdk\7.0.100-rc.1.22425.9\Sdks\Microsoft.NET.ILLink.Tasks\build\Microsoft.NET.ILLink.targets(133,5): error MSB6006: "dotnet.exe" exited with code 57005. [C:\a\_work\1\a\TestRelease\08-31_14.34.17\temp\BuildAMassiveApp\App1\App1.csproj]
    OutputProperties
        _ILLinkExitCode = 57005

I believe this started happening here:

• [main] Update dependencies from dotnet/installer android#7255
• dotnet/linker@f09bacf...6252a21

This Maestro bump, I believe, was the first time we ever saw something like this.

Logs: accessviolation.zip

Let me know if you need the entire project, I believe the solution with 100+ class libraries is too large to attach here.

/fyi @sbomer

[sbomer]

Unfortunately I can't tell much from the stacktrace or binlog - I think we'll need a repro. Would you be able to share the project?

@vitek-karas do you think your repro tool would be able to extract a repro from this binlog? If so, could you please share instructions with @jonathanpeppers?

[jonathanpeppers]

We have this build artifact:

I'll see if I can put it somewhere to share in Teams.

[vitek-karas]

My repro tool would only work on the machine where the failure happens, since it would copy out the files from the local paths mentioned in binlog.

[marek-safar]

I recall seeing this problem before and the workaround was to disable server GC.

[jonathanpeppers]

@marek-safar I think that MSBuild / dotnet build would be using the workstation GC by default:

https://docs.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector#flavors-of-garbage-collection

I don't think we do anything to enable server GC, does the .NET SDK or MSBuild do it?

(note we also are only seeing this issue on Windows)

[sbomer]

ILLink is configured to use server GC by default: https://github.com/dotnet/linker/blob/fdcff4c6e14b48f40011d5c8538053f84ab1d0e0/src/linker/Mono.Linker.csproj#L5 (it runs as a separate process, not hosted by MSBuild). I think you can override it with an environment variable: https://docs.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector#workstation-vs-server

[jonathanpeppers]

Ok, yeah if I look on disk then illink.runtimeconfig.json has:

    "configProperties": {
      "System.GC.Server": true,

I'll see if setting %DOTNET_gcServer% to 0 does anything. I'm not sure if the env var overwrites the runtimeconfig.json.

[jonathanpeppers]

@sbomer FYI, a PR build passed 4 times with the change above. ^^ So we merged it.

So exporting $DOTNET_gcServer as 0, does seem to fix the problem?

[MichalStrehovsky]

Is there an issue tracking this in the runtime repo? I don't think we would want to work around apparent managed heap corruptions without understanding the root cause.

Cc @mangod9

[mangod9]

yeah if there is a dump available for this we could take a look. fyi @AntonLapounov

[jonathanpeppers]

It appears to only happen on Azure DevOps 1 in 3 tries or so during an integration test that runs dotnet build out of process. I'm not sure how we can easily get a dump? We'd have to somehow keep dotnet build (or illink) alive and save one?

[AntonLapounov]

You can enable collecting crash dumps by setting the registry, but I don't know how easy it would be to obtain the collected dumps from the build machines.