Infinite Recursion When Linking

[naricc]

I am trying to use the dotnet/performance repo to run some wasm-aot programs. And when I do, I am getting this stack trace that looks like an infinite recursion:

     at Mono.Linker.Driver.Run(Mono.Linker.ILogger)
     at Mono.Linker.Pipeline.Process(Mono.Linker.LinkContext)
     at Mono.Linker.Pipeline.ProcessStep(Mono.Linker.LinkContext, Mono.Linker.Steps.IStep)
     at Mono.Linker.Steps.MarkStep.Process(Mono.Linker.LinkContext)
     at Mono.Linker.Steps.MarkStep.Initialize()
     at Mono.Linker.Steps.MarkStep.ProcessMarkedPending()
     at Mono.Linker.Steps.MarkStep.MarkModule(Mono.Cecil.ModuleDefinition, Mono.Linker.DependencyInfo)
     at Mono.Linker.Steps.MarkStep.MarkAssembly(Mono.Cecil.AssemblyDefinition, Mono.Linker.DependencyInfo)
     at Mono.Linker.Steps.MarkStep.MarkEntireAssembly(Mono.Cecil.AssemblyDefinition)
     at Mono.Linker.Steps.MarkStep.MarkCustomAttributes(Mono.Cecil.ICustomAttributeProvider, Mono.Linker.DependencyInfo ByRef, Mono.Cecil.IMemberDefinition)
     at Mono.Cecil.TypeReference.Resolve()
     at Mono.Cecil.ModuleDefinition.Resolve(Mono.Cecil.TypeReference)
     at Mono.Cecil.MetadataResolver.Resolve(Mono.Cecil.TypeReference)
     at Mono.Cecil.MetadataResolver.GetType(Mono.Cecil.ModuleDefinition, Mono.Cecil.TypeReference)
     at Mono.Cecil.ExportedType.Resolve()
     
... Repeats ... 

     at Mono.Cecil.ModuleDefinition.GetType(System.String, System.String)
     at Mono.Cecil.TypeDefinitionCollection.GetType(System.String, System.String)
     at System.Collections.Generic.Dictionary`2[[Mono.Cecil.Metadata.Row`2[[System.__Canon, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]], Mono.Cecil, Version=0.11.3.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e],[System.__Canon, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].TryGetValue(Mono.Cecil.Metadata.Row`2<System.__Canon,System.__Canon>, System.__Canon ByRef)
     at System.Collections.Generic.Dictionary`2[[Mono.Cecil.Metadata.Row`2[[System.__Canon, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e],[System.__Canon, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]], Mono.Cecil, Version=0.11.3.0, Culture=neutral, PublicKeyToken=50cebf1cceb9d05e],[System.__Canon, System.Private.CoreLib, Version=6.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]].FindValue(Mono.Cecil.Metadata.Row`2<System.__Canon,System.__Canon>)
     at Mono.Cecil.Metadata.RowEqualityComparer.GetHashCode(Mono.Cecil.Metadata.Row`2<System.String,System.String>)
  Stack overflow.

I have a repro for this, but because it only comes up in the project dotnet/performance generates (not dotnet performacne itself) , it is a little complicated. I am working on getting a simpler repro.

For now, what I've got is:

1. Download dotnet/runtime, build it for wasm:
   git clone git@github.com:dotnet/runtime.git
cd runtime
dotnet build -c Release -subset mono+libs -arch Browser -os wasm

2. Download dotnet/performance; run the microbenchmarks project (in src/benchmarks/micro) like so:
   git clone git@github.com:dotnet/performance.git
cd performance/src/benchmarks/micro
dotnet run --configuration Release --framework net6.0 --runtimes wasm --aotcompilermode wasm --runtimeSrcDir <path to the clone of dotnet/runtime in 1>. --filter "*ByteMark*"

You can use the --keepfiles option on that last dotnet run command to preserve the temporary project it generates, and the output shows all commands it runs on that project. This would probably be helpful for debugging.

It this a known error? I thought it might be some type of recursive type forwarding between assemblies, but couldn't find any typeforwarding annotations in the dotnet/performance code.

[marek-safar]

Do you have a more complete stack trace? It looks like exported type points to some unknown target but having longer repeated sequence would help

[naricc]

@marek-safar Here is the entire output of the BDN run, including the full stack trace: https://gist.github.com/naricc/1f13c46aa0285a6c4ff0a66b92b5cae8

The full stack trace is too big to paste in here in its entirety.

[akoeplinger]

I debugged the issue and it was due to the runtime pack not being used correctly so we got assembly references from some random nuget packages.

This resulted in getting a System.Runtime.dll that has typeforwarders to mscorlib.dll and an mscorlib.dll that has typeforwarders to System.Runtime.dll which causes the recursion when looking up the System.Runtime.CompilerServices.CompilationRelaxationsAttribute which is the first custom attribute in the assembly.

Here's a repro .zip which you can run:
Repro.zip

dotnet <linker repo>/artifacts/bin/Mono.Linker/Debug/net5.0/illink.dll -a linkertest.dll -reference mscorlib.dll -reference System.Runtime.dll -out .

If it's easy we should probably add some hardening against these infinite recursions.

[akoeplinger]

Unassigning myself since this is a linker hardening issue.

[agocke]

This hsould be fixed now.

[agocke]

Woops, wrong issue, this one might sill repro.