Interop.0.1 failing on gcstress pipeline

[kunalspathak]

https://dev.azure.com/dnceng-public/public/_build/results?buildId=578218&view=results

I see some failures like:

Testing GenericCalli with int as the return type
Fatal error. Internal CLR error. (0x80131506 (COR_E_EXECUTIONENGINE))
   at FunctionPtr.RunGenericFunctionPointerTest(Single)
   at Program.<<Main>$>g__TestExecutor29|25_30(System.IO.StreamWriter, System.IO.StreamWriter, <>c__DisplayClass25_0 ByRef)
   at Program.<Main>$(System.String[])
App Exit Code: -1073741819

Known Issue Error Message

Fill the error message using step by step known issues guidance.

{
  "ErrorMessage": "Internal CLR error",
  "ErrorPattern": "Internal CLR error",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=578218
Error message validated: [Internal CLR error]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 3/5/2024 1:18:23 AM UTC

Report

Build	Definition	Test	Pull Request
589245	dotnet/runtime	System.Net.Sockets.Tests.WorkItemExecution	#98218
588964	dotnet/runtime	System.Net.Http.WinHttpHandler.Functional.Tests.WorkItemExecution	#99185
578218	dotnet/runtime	Interop.0.1.WorkItemExecution

Summary

24-Hour Hit Count	7-Day Hit Count	1-Month Count
2	2	3

[JulieLeeMSFT]

Ping @mangod9. It is still failing in gcstress pipelines.

[mangod9]

This is from the weekend and I know @janvorli has made some changes related to it. Also adding @AaronRobinsonMSFT since this is an interop failure.

[JulieLeeMSFT]

@kunalspathak please turn this to a known issue format, It is happening more widely for all tests in gcstress0xc pipeline.

[janvorli]

This doesn't seem to be related to anything I was working on. The failure assert / stack trace is as follows. It fails because ThrowHR is called in a NOTHROW region. It seems to be something wrong with the signature the MetaSig::GetElemSize is called on, since the ThrowHR is called either when the eType argument is out of range or of an unexpected type.
Since this is happening for PInvokeCalliHelper and seems to occur over all architectures / OSes, I guess it is related to some interop related change.

Assert failure(PID 11164 [0x00002b9c], Thread: 11284 [0x2c14]): CONTRACT VIOLATION by operator new at "D:\a\_work\1\s\src\coreclr\utilcode\clrhost_nodependencies.cpp":301

THROWS called in a NOTHROW region.

VIOLATED-->  CONTRACT in MetaSig::GetElemSize at "D:\a\_work\1\s\src\coreclr\vm\siginfo.cpp":2598
                        CONTRACT in ArgIteratorTemplate<class ArgIteratorBase>::ForceSigWalk at "D:\a\_work\1\s\src\coreclr\vm\callingconvention.h":2076
                        FAULT_FORBID in ScanStackRoots at "D:\a\_work\1\s\src\coreclr\vm\gcenv.ee.cpp":128
                        GCX_NOTRIGGER in ScanStackRoots at "D:\a\_work\1\s\src\coreclr\vm\gcenv.ee.cpp":128
                        CANNOTTHROW in ScanStackRoots at "D:\a\_work\1\s\src\coreclr\vm\gcenv.ee.cpp":128
                        CONTRACT in GetILStubForCalli at "D:\a\_work\1\s\src\coreclr\vm\dllimport.cpp":5991
                        CONTRACT in MethodDescCallSite::CallTargetWorker at "D:\a\_work\1\s\src\coreclr\vm\callhelpers.cpp":280
                        GCX_COOP in Assembly::ExecuteMainMethod at "D:\a\_work\1\s\src\coreclr\vm\assembly.cpp":1409
                        CONTRACT in Assembly::ExecuteMainMethod at "D:\a\_work\1\s\src\coreclr\vm\assembly.cpp":1395
                        GCX_COOP in CorHost2::ExecuteAssembly at "D:\a\_work\1\s\src\coreclr\vm\corhost.cpp":329
                        CONTRACT in CorHost2::ExecuteAssembly at "D:\a\_work\1\s\src\coreclr\vm\corhost.cpp":269



CORECLR! CONTRACT_ASSERT + 0x2E4 (0x72251d5c)
CORECLR! ClrDebugState::CheckOkayToThrow + 0x23 (0x7225333f)
CORECLR! operator new + 0x20 (0x7278344e)
CORECLR! ThrowHR + 0x6D (0x72788d2c)
CORECLR! MetaSig::GetElemSize + 0x14B (0x7241ef7c)
CORECLR! ArgIteratorTemplate<ArgIteratorBase>::ForceSigWalk + 0x1C2 (0x72259a65)
CORECLR! ArgIteratorTemplate<ArgIteratorBase>::SizeOfArgStack + 0xF (0x72276c58)
CORECLR! ArgIteratorTemplate<ArgIteratorBase>::GetNextOffset + 0x7D (0x72276045)
CORECLR! TransitionFrame::PromoteCallerStackHelper + 0x118 (0x72347b11)
CORECLR! PInvokeCalliFrame::PromoteCallerStack + 0x57 (0x723478d9)
    File: D:\a\_work\1\s\src\coreclr\utilcode\clrhost_nodependencies.cpp:301
    Image: C:\h\w\BE0909DD\p\corerun.exe

[janvorli]

The etype argument is ELEMENT_TYPE_END in this case.

[janvorli]

And this is the stack trace from !clrstack -f:

OS Thread Id: 0x8bc4 (0)
        Child SP               IP Call Site
000000A672B766C0 00007FFCA92396CE KERNELBASE!RaiseFailFastException + 174 at d:\rs1\minkernel\kernelbase\xcpt.c:1106
000000A672B76C90 00007FFC7DE84E8C coreclr!_DbgBreakCheck + 748 at D:\a\_work\1\s\src\coreclr\utilcode\debug.cpp:291
000000A672B77E00 00007FFC7DE84735 coreclr!_DbgBreakCheckNoThrow + 85 at D:\a\_work\1\s\src\coreclr\utilcode\debug.cpp:310
000000A672B77EB0 00007FFC7DE8493F coreclr!DbgAssertDialog + 431 at D:\a\_work\1\s\src\coreclr\utilcode\debug.cpp:462
000000A672B77FD0 00007FFC7D663810 coreclr!CONTRACT_ASSERT + 800 at D:\a\_work\1\s\src\coreclr\inc\contract.inl:593
000000A672B7B6A0 00007FFC7DE415EE coreclr!operator new + 158 at D:\a\_work\1\s\src\coreclr\utilcode\clrhost_nodependencies.cpp:309
000000A672B7B6F0 00007FFC7DE482DE coreclr!ThrowHR + 126 at D:\a\_work\1\s\src\coreclr\utilcode\ex.cpp:1015
000000A672B7B770 00007FFC7D906670 coreclr!MetaSig::GetElemSize + 544 at D:\a\_work\1\s\src\coreclr\vm\siginfo.cpp:2616
000000A672B7B840 00007FFC7D6738B1 coreclr!ArgIteratorTemplate::GetNextOffset + 321 at D:\a\_work\1\s\src\coreclr\vm\callingconvention.h:1234
000000A672B7B870 00007FFC7D7CA41C coreclr!TransitionFrame::PromoteCallerStackHelper + 428 at D:\a\_work\1\s\src\coreclr\vm\frames.cpp:1419
000000A672B7B920 00007FFC7D7C6DFA coreclr!PInvokeCalliFrame::GcScanRoots + 250 at D:\a\_work\1\s\src\coreclr\vm\frames.h:2019
000000A672B7B9F0 00007FFC7DA4FD41 coreclr!GcStackCrawlCallBack + 1137 at D:\a\_work\1\s\src\coreclr\vm\gcenv.ee.common.cpp:310
000000A672B7BBF0 00007FFC7D917294 coreclr!Thread::StackWalkFramesEx + 628 at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp:927
000000A672B7C000 00007FFC7D916F7F coreclr!Thread::StackWalkFrames + 383 at D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp:1011
000000A672B7D130 00007FFC7DA4E6E4 coreclr!ScanStackRoots + 596 at D:\a\_work\1\s\src\coreclr\vm\gcenv.ee.cpp:207
000000A672B7D300 00007FFC7DA4BF37 coreclr!GCToEEInterface::GcScanRoots + 407 at D:\a\_work\1\s\src\coreclr\vm\gcenv.ee.cpp:304
000000A672B7D350 00007FFC7DDCD20A coreclr!WKS::gc_heap::mark_phase + 1162 at D:\a\_work\1\s\src\coreclr\gc\gc.cpp:29617
000000A672B7D430 00007FFC7DDC27C8 coreclr!WKS::gc_heap::gc1 + 552 at D:\a\_work\1\s\src\coreclr\gc\gc.cpp:22191
000000A672B7D4F0 00007FFC7DDC253A coreclr!WKS::gc_heap::garbage_collect + 1850 at D:\a\_work\1\s\src\coreclr\gc\gc.cpp:24204
000000A672B7D5A0 00007FFC7DDA83A3 coreclr!WKS::GCHeap::GarbageCollectGeneration + 1251 at D:\a\_work\1\s\src\coreclr\gc\gc.cpp:50696
000000A672B7D600 00007FFC7DDA7E46 coreclr!WKS::GCHeap::GarbageCollect + 502 at D:\a\_work\1\s\src\coreclr\gc\gc.cpp:49851
000000A672B7D660 00007FFC7DDABB18 coreclr!WKS::GCHeap::StressHeap + 1816 at D:\a\_work\1\s\src\coreclr\gc\gc.cpp:49470
000000A672B7D740 00007FFC7DA053EA coreclr!GetILStubForCalli + 1530 at D:\a\_work\1\s\src\coreclr\vm\dllimport.cpp:6004
000000A672B7DBC0 00007FFC7DA103F0 coreclr!GenericPInvokeCalliStubWorker + 192 at D:\a\_work\1\s\src\coreclr\vm\dllimport.cpp:5974
000000A672B7DBE8                  [PInvokeCalliFrame: 000000a672b7dbe8] 
000000A672B7DC30 00007FFC7DE04EAE coreclr!GenericPInvokeCalliGenILStub + 94 at D:\a\_work\1\s\src\coreclr\vm\amd64\PInvokeStubs.asm:68
000000A672B7DCE0 00007ffc1f560453 Interop.dll!FunctionPtr.RunGenericFunctionPointerTest(Single) + 99
000000A672B7DCE8 0000000000010000 
000000A672B7DCF0 000001EE7995C1E0 
000000A672B7DCF8 00007FFC7E1A64C8 coreclr!`string'
000000A672B7DD00 00007FFC7E1A61C8 coreclr!`string'
000000A672B7DD90 00007ffc1f56012f Interop.dll!Program.$>g__TestExecutor29|25_30(System.IO.StreamWriter, System.IO.StreamWriter, c__DisplayClass25_0 ByRef) + 271
000000A672B7DE30 00007ffc1e5d2031 Interop.dll!Program.$(System.String[]) + 961

[janvorli]

(This is a dump from my PR where I've hit the issue too, obtained by runfo get-helix-payload -j "2c7fae10-0676-4eb0-a4e3-28a474dfaa84" -w "Interop.0.1" -o .)

All architectures / OSes were failing in this test, including Windows x86: https://dev.azure.com/dnceng-public/public/_build/results?buildId=588479&view=ms.vss-test-web.build-test-results-tab&runId=14198304&resultId=168380&paneView=debug

[AaronRobinsonMSFT]

This might be fixed with #99253. Support for generics and calli was introduced in #97079.

/cc @jkotas @hez2010

[jkotas]

Yes, this is fixed with #99253.

"ErrorMessage": "Internal CLR error",

@kunalspathak This is not good ErrorMessage pattern. It is very generic and it is going to match a lot of unrelated failures. 2 out of 3 matches above are unrelated to this issue.

A better error message pattern would be at FunctionPtr.RunGenericFunctionPointerTest.

[kunalspathak]

A better error message pattern would be at FunctionPtr.RunGenericFunctionPointerTest.

Ah, ok. Thanks for letting me know.