R2R-CrossGen2 failure - loader\\classloader\\reffields\\validate\\validate.cmd

[runfoapp]

Runfo Tracking Issue: R2R-CrossGen2 failure - loader\classloader\reffields\validate\validate.cmd

Build	Definition	Kind	Run Name	Console	Core Dump	Test Results	Run Client
1578514	runtime-coreclr outerloop	Rolling	R2R-CG2 windows arm Checked @ Windows.10.Arm64v8.Open	console.log			runclient.py
1578514	runtime-coreclr outerloop	Rolling	R2R-CG2 windows arm Checked no_tiered_compilation @ Windows.10.Arm64v8.Open	console.log			runclient.py
1578514	runtime-coreclr outerloop	Rolling	R2R-CG2 windows x64 Checked no_tiered_compilation @ Windows.10.Amd64.Open	console.log	core dump		runclient.py
1578514	runtime-coreclr outerloop	Rolling	R2R-CG2 windows x64 Checked @ Windows.10.Amd64.Open	console.log	core dump		runclient.py
1578514	runtime-coreclr outerloop	Rolling	R2R-CG2 windows x86 Checked @ Windows.10.Amd64.Open	console.log	core dump		runclient.py
1578514	runtime-coreclr outerloop	Rolling	R2R-CG2 windows x86 Checked no_tiered_compilation @ Windows.10.Amd64.Open	console.log	core dump		runclient.py
1578514	runtime-coreclr outerloop	Rolling	R2R-CG2 windows arm64 Checked @ Windows.10.Arm64v8.Open	console.log			runclient.py
1578514	runtime-coreclr outerloop	Rolling	R2R-CG2 windows arm64 Checked no_tiered_compilation @ Windows.10.Arm64v8.Open	console.log			runclient.py
1577796	runtime-coreclr outerloop	Rolling	R2R-CG2 windows x64 Checked @ Windows.10.Amd64.Open	console.log	core dump		runclient.py
1577796	runtime-coreclr outerloop	Rolling	R2R-CG2 windows x64 Checked no_tiered_compilation @ Windows.10.Amd64.Open	console.log	core dump		runclient.py
1577796	runtime-coreclr outerloop	Rolling	R2R-CG2 windows arm64 Checked @ Windows.10.Arm64v8.Open	console.log			runclient.py
1577796	runtime-coreclr outerloop	Rolling	R2R-CG2 windows arm64 Checked no_tiered_compilation @ Windows.10.Arm64v8.Open	console.log			runclient.py
1577796	runtime-coreclr outerloop	Rolling	R2R-CG2 windows x86 Checked @ Windows.10.Amd64.Open	console.log	core dump		runclient.py
1577796	runtime-coreclr outerloop	Rolling	R2R-CG2 windows x86 Checked no_tiered_compilation @ Windows.10.Amd64.Open	console.log	core dump		runclient.py
1577796	runtime-coreclr outerloop	Rolling	R2R-CG2 windows arm Checked @ Windows.10.Arm64v8.Open	console.log			runclient.py
1577796	runtime-coreclr outerloop	Rolling	R2R-CG2 windows arm Checked no_tiered_compilation @ Windows.10.Arm64v8.Open	console.log			runclient.py

Build Result Summary

Day Hit Count	Week Hit Count	Month Hit Count
2	2	2

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.

[AaronRobinsonMSFT]

@MichalStrehovsky or @trylek Any thoughts on this? I've been looking through the CrossGen2 code but it isn't clear to me how this offset is computed. Assert fired from here.

Assert failure(PID 69492 [0x00010f74], Thread: 4060 [0x0fdc]): Verify_FieldOffset 'InvalidCSharp.WithTypedReferenceField`1.Field' Field offset 0!=8(actual) || baseOffset 0!=0(actual)

CORECLR! LoadDynamicInfoEntry + 0x19BD (0x00007ff9`bed3841d)
CORECLR! Module::FixupNativeEntry + 0x35F (0x00007ff9`beb944ef)
CORECLR! Module::FixupDelayListAux<Module *,int (__cdecl Module::*)(CORCOMPILE_IMPORT_SECTION *,unsigned __int64,unsigned __int64 *,int)> + 0x64A (0x00007ff9`bef4202a)
CORECLR! Module::FixupDelayList + 0xCA (0x00007ff9`bef4460a)
CORECLR! ReadyToRunInfo::GetEntryPoint + 0x53C (0x00007ff9`bef454ec)
CORECLR! MethodDesc::GetPrecompiledR2RCode + 0x224 (0x00007ff9`bee3da34)
CORECLR! MethodDesc::GetPrecompiledCode + 0x20A (0x00007ff9`bee3d53a)
CORECLR! MethodDesc::PrepareILBasedCode + 0x592 (0x00007ff9`bee420d2)
CORECLR! MethodDesc::PrepareCode + 0x21C (0x00007ff9`bee41adc)
CORECLR! CodeVersionManager::PublishVersionableCodeIfNecessary + 0x5AE (0x00007ff9`bec29f1e)
    File: D:\runtime\src\coreclr\vm\jitinterface.cpp Line: 13639
    Image: D:\runtime\artifacts\tests\coreclr\windows.x64.Debug\Tests\Core_Root\corerun.exe

When looking at the type in SOS, not R2R, the offset of the field is 0x10.

0:000> !DumpClass /d 00007ff960ac1a48
Class Name:      InvalidCSharp.WithTypedReferenceField`1
mdToken:         0000000002000005
File:            D:\runtime\artifacts\tests\coreclr\windows.x64.Release\Loader\classloader\RefFields\Validate\InvalidCSharp.dll
Parent Class:    00007ff9606d20f8
Module:          00007ff960aac3b8
Method Table:    00007ff960aace38
Vtable Slots:    4
Total Method Slots:  7
Class Attributes:    100101  
NumInstanceFields:   1
NumStaticFields:     0
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ff96077fc18  4000004       10 ...em.TypedReference  1 instance           Field

The type definition in IL is:

.class public auto ansi sealed beforefieldinit InvalidCSharp.WithTypedReferenceField`1<T>
    extends [System.Runtime]System.ValueType
{
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.IsByRefLikeAttribute::.ctor() = (
        01 00 00 00
    )
    .field public typedref Field

    .method public hidebysig specialname rtspecialname
        instance void .ctor (
            !T&
        ) cil managed
    {
        // snip
    }

    .method public hidebysig
        instance class [System.Runtime]System.Type GetFieldType () cil managed
    {
        // snip
    }

    .method public hidebysig
        instance bool ConfirmFieldInstance (
            !T
        ) cil managed
    {
        // snip
    }
}

[trylek]

@AaronRobinsonMSFT - thanks for the heads-up; this is complicated, the latest changes in this space were made by @jkoritzinsky as part of the runtime type layout cleanup; interestingly enough one of the most recent issues was zero-sized structs and I cannot help speculating this may be somehow related as it seems to me that the InvalidCSharp.WithTypedReferenceField`1<T> is exactly a struct derived from a zero-size struct (ValueType) albeit is has auto layout i.e. it seems to me that on this particular occasion Crossgen2 "is right" - there's no reason for Field to be pushed to offset 8 as there shouldn't be any fields "before it". One way or another, according to my experience debugging this basically amounts to stepping through the code in

runtime/src/coreclr/vm/methodtablebuilder.cpp

Line 7994 in c7adf55

VOID MethodTableBuilder::PlaceInstanceFields(MethodTable ** pByValueClassCache)

(for auto layout types) and

runtime/src/coreclr/vm/classlayoutinfo.cpp

Line 585 in c7adf55

VOID EEClassLayoutInfo::CollectLayoutFieldMetadataThrowing(

(for explicit types), taking down notes as to what code paths / algorithms / values were used to place the problematic fields and comparing the logic to

runtime/src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunMetadataFieldLayoutAlgorithm.cs

Line 799 in c7adf55

protected override ComputedInstanceFieldLayout ComputeInstanceFieldLayout(MetadataType type, int numInstanceFields)

(which drives the equivalent algorithm in Crossgen2). I'm disabling another test that fails due to type layout mismatch in

#64420

but at this point I don't have sufficient understanding to make an educated guess whether they are related or not. If it's not directly blocking your current efforts, I would suggest filing an issue with the area-crossgen2-coreclr label and the Crossgen2 team will make sure they get fixed.