ExecutionEngineException in assembly.GetTypes() when the assembly has a class with covariant return types

[roy-t]

Description

Whenever I try to run assembly.GetTypes() on an assembly with a class similar to the one below I get an ExecutionEngineException. A minimal reproduction can be found here: https://github.com/roy-t/ExecutionEngineExceptionReproduction.

public abstract class ABase
{
    public abstract object this[int index] { get; }
}

public sealed class Concrete<T> : ABase
    where T : class
{
    public override T this[int index] // <- covariant indexer
    {
       get
       {
            throw null;
        }
    }
}

I think the problem is the covariant indexer. Whenever I replace the covariant indexer with a regular one that just returns object the problem goes away. I've also tried to reproduce the problem with methods and properties with covariant return types, but that did not trigger the bug.

Update: after more experimentation I did find it possible to trigger this bug with covariant return types for methods and properties. See my comment down below.

Configuration

I'm running .NET 5.0 (v5.0.100) on Window 10 x64. I have not tried it on another machine yet.

Regression?

Not really, since .NET 5.0 is the first version that supports covariant return types. However in previous .net versions you were able to call GetTypes() on an assembly without a crash :).

Other information

Unfortunately there's no stack trace. The only information I get from Visual Studio is:

An unhandled exception of type 'System.ExecutionEngineException' occurred in System.Private.CoreLib.dll

The program '[17496] FooCrash.exe' has exited with code -1 (0xffffffff).

By the way, I hope this is the right GitHub project for these types of exceptions. I saw that System.Private.Corelib lives in this repository so it was my best guess :)

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

 # Child-SP          RetAddr           Call Site
00 (Inline Function) --------`-------- coreclr!MethodTable::GetFlag [F:\workspace\_work\1\s\src\coreclr\src\vm\methodtable.h @ 3705] 
01 (Inline Function) --------`-------- coreclr!MethodTable::IsArray [F:\workspace\_work\1\s\src\coreclr\src\vm\methodtable.h @ 2659] 
02 00000005`1297d940 00007ff8`1713f821 coreclr!MethodTable::CanCastTo+0x1a [F:\workspace\_work\1\s\src\coreclr\src\vm\methodtable.cpp @ 1694] 
03 00000005`1297d970 00007ff8`170833cb coreclr!ClassLoader::IsCompatibleWith+0x1d9 [F:\workspace\_work\1\s\src\coreclr\src\vm\class.cpp @ 1124] 
04 00000005`1297d9d0 00007ff8`16fa70c0 coreclr!ClassLoader::ValidateMethodsWithCovariantReturnTypes+0x233 [F:\workspace\_work\1\s\src\coreclr\src\vm\class.cpp @ 1184] 
05 (Inline Function) --------`-------- coreclr!PushFinalLevels+0x62 [F:\workspace\_work\1\s\src\coreclr\src\vm\clsload.cpp @ 3536] 
06 00000005`1297dc40 00007ff8`16f4e200 coreclr!ClassLoader::LoadTypeHandleForTypeKey+0x1d0 [F:\workspace\_work\1\s\src\coreclr\src\vm\clsload.cpp @ 3620] 
07 00000005`1297dd10 00007ff8`16f4ec13 coreclr!ClassLoader::LoadTypeDefThrowing+0x1f0 [F:\workspace\_work\1\s\src\coreclr\src\vm\clsload.cpp @ 2501] 
08 00000005`1297de30 00007ff8`16ffbdbc coreclr!ClassLoader::LoadTypeDefOrRefThrowing+0x213 [F:\workspace\_work\1\s\src\coreclr\src\vm\clsload.cpp @ 2673] 
09 00000005`1297df20 00007ff8`17075ba3 coreclr!GetTypesInner+0x27c [F:\workspace\_work\1\s\src\coreclr\src\vm\commodule.cpp @ 999] 
0a 00000005`1297e160 00007ff8`106e874a coreclr!COMModule::GetTypes+0xb3 [F:\workspace\_work\1\s\src\coreclr\src\vm\commodule.cpp @ 932] 
0b 00000005`1297e2d0 00007ff8`106d57aa System_Private_CoreLib!System.Reflection.RuntimeModule.GetTypes()+0xa [/_/src/coreclr/src/System.Private.CoreLib/src/System/Reflection/RuntimeModule.cs @ 454] 
0c 00000005`1297e300 00007ff7`b75161e4 System_Private_CoreLib!System.Reflection.Assembly.GetTypes()+0x3a [/_/src/libraries/System.Private.CoreLib/src/System/Reflection/Assembly.cs @ 71] 
0d 00000005`1297e360 00007ff8`1707a2f3 FooCrash!FooCrash.Program.Main(System.String[])+0x74*** WARNING: Unable to verify checksum for C:\ExecutionEngineExceptionReproduction\FooCrash\bin\Debug\net5.0\FooCrash.dll

[jkotas]

cc @janvorli @davidwrighton

[roy-t]

Its worse than I thought, making it really hard to work around.

This does not trigger the bug (hence I thought regular covariant return types do work):

public abstract class ABase { public abstract IReadOnlyList<object> Get(int index); }

public sealed class Concrete<T> : ABase
        where T : class
{        
    public override IReadOnlyList<T> Get(int index) => throw null;
}

However this does trigger the bug

public abstract class ABase { public abstract object Get(int index); }

public sealed class Concrete<T> : ABase
    where T : class
{
    public override T Get(int index) => throw null;
}

So basically any assembly with a class that has a plain covariant return type is unable to be loaded using assembly.GetTypes(). This is especially problematic when using dependency injection, because a single class taking use of the covariant return types feature makes the entire assembly unusable for DI.

I've updated the title of this bug report. I've also updated my reproduction repository to include all three examples.

[marek-safar]

/cc @lambdageek

[roy-t]

I've found yet another way to trigger an execution engine exception using covariant types.

typeof(Concrete<>) , (see class above). I've updated my repo to add this case as well (its a comment in the Main method)

Hope that helps with tracking down the problem. :)

[roy-t]

I think I've found another problem with covariant return types which was triggered by similar code. But since it leads to a very different exception I believe it to be a different problem. So I've submitted it as issue #45082. If anybody believes its the same problem I'll close the other issue and add the problem to the reproduction repository.

All and all it seems there are still some kinks in the covariant return types feature that need to be worked out. I already see a lot of people tagged (sorry for the spam over the weekend, its when I have time to play with C#). Hope these issues don't ruin your Monday tomorrow :).

[lambdageek]

@marek-safar Works correctly in Mono.

[janvorli]

I am looking into it. The problem is that we don't handle uninstantiated generic types in the code that detects covariant return type compatibility at all. So it works for runtime cases when an instantiation of a generic type is used, but it doesn't work for the Assembly.GetTypes() case which returns the uninstantiated types too.