Test failed: Loader_classloader._DefaultInterfaceMethods_aredgenerics_aredgenerics_d_aredgenerics_d_._DefaultInterfaceMethods_sharedgenerics_sharedgenerics_d_sharedgenerics_d_sh

[VincentBu]

Job:
https://mc.dot.net/#/user/coreclr-gcstress0x3-gcstress0xc/ci~2Fdotnet~2Fcoreclr~2Frefs~2Fheads~2Fmaster/test~2Ffunctional~2Fcli~2F/20190714.1/workItem/Loader.classloader/analysis/xunit/Loader_classloader._DefaultInterfaceMethods_aredgenerics_aredgenerics_d_aredgenerics_d_~2F_DefaultInterfaceMethods_sharedgenerics_sharedgenerics_d_sharedgenerics_d_sh

Failed tests:
Loader_classloader.DefaultInterfaceMethods_aredgenerics_aredgenerics_d_aredgenerics_d._DefaultInterfaceMethods_sharedgenerics_sharedgenerics_d_sharedgenerics_d_sh

Log:

/home/helixbot/work/9d303505-455d-4606-a672-c0413d0059f5/Work/04d0cdcf-457a-454d-9758-d58949ac18e7/Exec/Loader/classloader/DefaultInterfaceMethods/sharedgenerics/sharedgenerics_d/sharedgenerics_d.sh: line 252:  5426 Segmentation fault      (core dumped) $LAUNCHER $ExePath \"${CLRTestExecutionArguments[@]}\"

Return code:      1
Raw output file:      /home/helixbot/work/9d303505-455d-4606-a672-c0413d0059f5/Work/04d0cdcf-457a-454d-9758-d58949ac18e7/Exec/Loader/classloader/Reports/Loader.classloader/DefaultInterfaceMethods/sharedgenerics/sharedgenerics_d/sharedgenerics_d.output.txt
Raw output:
BEGIN EXECUTION
/home/helixbot/work/9d303505-455d-4606-a672-c0413d0059f5/Payload/corerun sharedgenerics_d.exe ''
Calling IFoo<string>.Foo on FooBar<string, object> - expecting default method IFoo<string>.Foo
Expected: 100
Actual: 139
END EXECUTION - FAILED
Test Harness Exitcode is : 1
To run the test:
> set CORE_ROOT=/home/helixbot/work/9d303505-455d-4606-a672-c0413d0059f5/Payload
> /home/helixbot/work/9d303505-455d-4606-a672-c0413d0059f5/Work/04d0cdcf-457a-454d-9758-d58949ac18e7/Exec/Loader/classloader/DefaultInterfaceMethods/sharedgenerics/sharedgenerics_d/sharedgenerics_d.sh
Expected: True
Actual:   False

[BruceForstall]

This is failing on all architectures on Linux in multiple configurations in the GCStress runs.

[BruceForstall]

This is easy to repro on Linux/x64. On my machine, in directory ~/gh/coreclr2/bin/tests/Linux.x64.Checked/Loader/classloader/DefaultInterfaceMethods/sharedgenerics/sharedgenerics_d, I run:

export COMPlus_TieredCompilation=0
export COMPlus_GCStress=4
/home/bruce/gh/coreclr2/bin/tests/Linux.x64.Debug/Tests/Core_Root/corerun ./sharedgenerics_d.exe

It's difficult to run under a debugger due to the GCStress breakpoints. I created a core dump and got:

#0  0x00007fb91346d82d in NativeCodeVersion::GetGCCoverageInfo (this=0x7ffe657680f8) at /home/bruce/gh/coreclr2/src/vm/codeversion.cpp:419
dotnet/coreclr#1  0x00007fb9136c9ae0 in OnGcCoverageInterrupt (regs=0x1390fa0) at /home/bruce/gh/coreclr2/src/vm/gccover.cpp:1380
dotnet/coreclr#2  0x00007fb9134ae062 in IsGcMarker (pContext=0x1390fa0, pExceptionRecord=0x1391470) at /home/bruce/gh/coreclr2/src/vm/excep.cpp:6604
dotnet/coreclr#3  0x00007fb91382cb81 in HandleHardwareException (ex=0x7ffe65768ac0) at /home/bruce/gh/coreclr2/src/vm/exceptionhandling.cpp:5197
dotnet/coreclr#4  0x00007fb913cadbd5 in SEHProcessException (exception=0x7ffe65768ac0) at /home/bruce/gh/coreclr2/src/pal/src/exception/seh.cpp:286
dotnet/coreclr#5  0x00007fb913cb092e in common_signal_handler (code=0xb, siginfo=0x7fb915710af0, sigcontext=0x7fb9157109c0, numParams=0x2) at /home/bruce/gh/coreclr2/src/pal/src/exception/signal.cpp:837
dotnet/coreclr#6  0x00007fb913cb02c8 in signal_handler_worker (code=0xb, siginfo=0x7fb915710af0, context=0x7fb9157109c0, returnPoint=0x7fb915710430) at /home/bruce/gh/coreclr2/src/pal/src/exception/signal.cpp:378
dotnet/coreclr#7  0x00007fb913d95a96 in CallSignalHandlerWrapper0 () at /home/bruce/gh/coreclr2/src/pal/src/arch/amd64/callsignalhandlerwrapper.S:30
dotnet/coreclr#8  0x00007fb89a67e15f in ?? ()

The crash is:

   0x00007fb91346d828 <+104>:   call   0x7fb91346cf60 <NativeCodeVersion::GetMethodDesc() const>
=> 0x00007fb91346d82d <+109>:   mov    rax,QWORD PTR [rax+0x20]

with rax = 0x1e15f

(gdb) p *this
$2 = {
  m_storageKind = NativeCodeVersion::Unknown,
  {
    m_pVersionNode = 0x1e15f,
    m_synthetic = {
      m_pMethodDesc = 0x1e15f
    }
  }
}
...
(gdb) p *(MethodDesc*)0x7fb89a9127b8
$3 = {
...
  m_pszDebugMethodName = 0x7fb89a9204a8 "Foo",
  m_pszDebugClassName = 0x7fb89a920478 "IFoo`1[__Canon]",
  m_pszDebugMethodSignature = 0x7fb89a920568 "instance class [mscorlib]System.Type *(!0)",

This code is:

PTR_GCCoverageInfo NativeCodeVersion::GetGCCoverageInfo() const
{
    WRAPPER_NO_CONTRACT;

    if (m_storageKind == StorageKind::Explicit)
    {
        return AsNode()->GetGCCoverageInfo();
    }
    else
    {
        return GetMethodDesc()->m_GcCover; <------- here
    }
}

@kouvel Looks like you added this code recently, in dotnet/coreclr#25261. Can you take a look? Maybe there's a problem with generic default interface methods and this code, on Linux?

cc @MichalStrehovsky

[MichalStrehovsky]

Thanks for troubleshooting this Bruce!

I've never heard of NativeCodeVersion before - and looking through dotnet/coreclr#25261 I don't see any obvious interaction (in the diff). The only (hopefully) useful tidbit of information I would have is that invocation of default interface methods on shared generic types goes through an instantiating stub (same as invocation of virtual methods on generic structs, for example).

So if we're calling e.g. interface method IFoo<string>.Foo() and the implementation we resolved into is the same IFoo<string>.Foo() (nobody overrode it and we're calling the default implementation), before we can call the method body IFoo<__Canon>.Foo(), we need to supply an extra hidden argument to the method that has the generic context (because we're actually calling IFoo<__Canon>.Foo(IntPtr hiddenParam)). This is done by calling the instantiating stub that prepends this hidden argument and calls the real target method.

Maybe the instantiating stub is throwing things off here? (Can't get NativeCodeVersion for the instantiating stub?)

[kouvel]

Looks like there is a discrepancy between MethodDesc::SetNativeCodeInterlocked() and MethodDesc::GetNativeCode() for default interface methods, where the former sets the precode's target, and the latter always returns null. In this case code versioning tries to find a code version matching the start address of the method using GetNativeCode() and fails to find one because it returns null. I don't think it should be returning null but there are some other things to follow up on, will look into it.

[kouvel]

I don't think this is necessary to fix for 3.0, moving to future

[kouvel]

For the same reason sos does not show the native code entry point for !dumpmd on the MethodDesc

[BruceForstall]

Is it GCStress (and SOS DumpMD) only issue? (I.e., not main scenario) If so, moving to future makes sense.

However, we want our tests to run clean in 3.0, so you might need to mark this test GCStressIncompatible in 3.0 so it doesn't cause failures every GCStress run, if the bug itself is not fixed.

[kouvel]

GetNativeCode() returning null has side-effects that may be relied upon (I don't have the full context yet). It only affects GCStress, the sos issue is preexisting. There is a small fix I could do but I don't think it's worth it, I'd rather fix it properly in master. I'll go ahead and flag it as incompatible for 3.0.