[win-x86 gcstress] Consistency check failed: Crst Level violation: Can't take level 9 lock CrstCodeVersioning because you already holding level 5 lock CrstInteropData

[jakobbotsch]

Lots of tests seem to be failing in win-x86 gcstress runs with this assert:
https://dev.azure.com/dnceng-public/public/_build/results?buildId=168907&view=ms.vss-test-web.build-test-results-tab

Assert failure(PID 3764 [0x00000eb4], Thread: 3868 [0x0f1c]): Consistency check failed: Crst Level violation: Can't take level 9 lock CrstCodeVersioning because you already holding level 5 lock CrstInteropData
FAILED: false

CORECLR! CHECK::Trigger + 0x256 (0x6d4c1752)
CORECLR! CrstBase::IsSafeToTake + 0x2C3 (0x6d047d6e)
CORECLR! CrstBase::Enter + 0x134 (0x6d047833)
CORECLR! CrstBase::AcquireLock + 0xD (0x6cf9cc31)
CORECLR! CodeVersionManager::LockHolder::LockHolder + 0x25 (0x6cfdf7df)
CORECLR! EECodeInfo::GetNativeCodeVersion + 0xD3 (0x6d0bca8f)
CORECLR! EECodeInfo::GetSavedMethodCode + 0x8C (0x6d0bceba)
CORECLR! UnwindStackFrame + 0xD0 (0x6d06acb0)
CORECLR! StackFrameIterator::NextRaw + 0x5B6 (0x6d172c64)
CORECLR! StackFrameIterator::Next + 0x50 (0x6d172668)
File: D:\a_work\1\s\src\coreclr\vm\crst.cpp Line: 765
Image: C:\h\w\BE070A56\p\corerun.exe

[janvorli]

cc: @dotnet/interop-contrib - it seems that the issue happens because GC happens while CrstInteropData critical section is entered.

[jkoritzinsky]

@jkotas could this be related to the new struct marshalling stub cache you added?

[jkotas]

#82044