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

Activity

2. ghost added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Jan 28, 2022
3. AaronRobinsonMSFT

   added

   area-TypeSystem-coreclr

   on Jan 28, 2022
4. AaronRobinsonMSFT

   added this to the 7.0.0 milestone on Jan 28, 2022
5. AaronRobinsonMSFT

   self-assigned this

   on Jan 28, 2022
6. AaronRobinsonMSFT commented on Jan 28, 2022

   

   AaronRobinsonMSFT

   on Jan 28, 2022

   Member

   More actions

   @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
       }
   }
   
7. trylek commented on Jan 28, 2022

   

   trylek

   on Jan 28, 2022

   Member

   More actions

   @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.

   👍React with 👍1Reacted by Aaron R Robinson
8. ghost added

   in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

   on Jan 28, 2022
9. AaronRobinsonMSFT

   removed

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Jan 29, 2022
10. AaronRobinsonMSFT

    closed this as completedin #64422on Jan 30, 2022
11. ghost removed

    in-prThere is an active PR which will close this issue when it is mergedThere is an active PR which will close this issue when it is merged

    on Jan 30, 2022
12. ghost locked as resolved and limited conversation to collaborators on Mar 1, 2022