Assertion failure: Consistency check failed: FAILED: !implSlot.IsNull() && "Valid method implementation was not found."

[RussKeldorph]

CoreFx tests with Checked runtime

Sample CoreFx build/test Log
https://ci.dot.net/job/dotnet_coreclr/job/master/job/jitstress/job/x64_checked_windows_nt_corefx_baseline/122/consoleFull

Sample failure output

2:26:46   CORECLR! CHECK::Trigger + 0x2C4 (0x00007ff8`0418ea6c)
22:26:46   call D:\j\workspace\x64_checked_w---a7bd363e\_\fx\bin\testhost\netcoreapp-Windows_NT-Release-x64\\dotnet.exe xunit.console.netcore.exe System.Xml.RW.WrappedReader.Tests.dll  -xml testResults.xml -notrait Benchmark=true -notrait category=nonnetcoreapptests  -notrait category=IgnoreForCI -notrait category=OuterLoop -notrait category=failing -notrait category=nonwindowstests
22:26:46   CORECLR! VirtualCallStubManager::Resolver + 0x1594 (0x00007ff8`045b37ec)
22:26:46   CORECLR! VirtualCallStubManager::GetTarget + 0x37E (0x00007ff8`045aaeee)
22:26:46   CORECLR! MethodTable::GetMethodDescForInterfaceMethod + 0x79A (0x00007ff8`046d7f32)
22:26:46   CORECLR! resolveVirtualMethodHelper + 0x2DC (0x00007ff8`0447b7a0)
22:26:46   CORECLR! CEEInfo::resolveVirtualMethod + 0x175 (0x00007ff8`0447b425)
22:26:46   CLRJIT! Compiler::impDevirtualizeCall + 0x414 (0x00007ff8`02d53640)
22:26:46   CLRJIT! Compiler::impImportCall + 0x1D4F (0x00007ff8`02d62eaf)
22:26:46   CLRJIT! Compiler::impImportBlockCode + 0x5B5D (0x00007ff8`02d5baf9)
22:26:46   CLRJIT! Compiler::impImportBlock + 0xED (0x00007ff8`02d55475)
22:26:46       File: d:\j\workspace\x64_checked_w---a7bd363e\src\vm\virtualcallstub.cpp Line: 2278
22:26:46       Image: D:\j\workspace\x64_checked_w---a7bd363e\_\fx\bin\testhost\netcoreapp-Windows_NT-Release-x64\dotnet.exe

[RussKeldorph]

@AndyAyersMS Related to your devirt work?

[AndyAyersMS]

Yes, most certainly.

[AndyAyersMS]

I know roughly what is going on but not quite sure what the best fix is. If we try and devirtualize at a generic interface call we need to pass the owner type context. However sometimes that context refers to a specific instantation when the base interface type refers to the canonical one, and this I believe causes the interface lookup to fail.

For instance in System.Xml.XmlSerializer.Tests while jitting XmlSerializerTests:Xml_CollectionGenericRoot() we end up with the following attempt:

impDevirtualizeCall: Trying to devirtualize interface call:
    class for 'this' is System.Collections.Generic.List`1[__Canon] (attrib 21020000)
    base method is System.Collections.Generic.IEnumerable`1[__Canon]::GetEnumerator
    context (ownerType) is System.Collections.Generic.IEnumerable`1[string]

Seems like in devirtualization, we should either try and map from the specific owner type to the canonical one, or see if we could find the equivalent specific method for the canonical one. My preference is to keep things specific since this gives us better type information.

Am going to work on getting a small repro...

[AndyAyersMS]

Ok, have a local repro....

[AndyAyersMS]

I believe all these failures are related to devirtualization while inlining, so in release builds, this will result in an inlining failure and not bad code.

Not sure it is feasible to enrich types, so will look into mapping the context into a canonical type. This may prevent devirtualization in some variance cases since we can't resolve variance via __Canon.