Repository navigation
Assert failure: Consistency check failed: Crst Level violation: Can't take level 17 lock CrstInstMethodHashTable because you already holding level 17 lock CrstInstMethodHashTable #71023
Description
Lots of threading tests are failing, on all platforms, with this assert.
e.g.,
baseservices\threading\generics\WaitCallback\thread23\thread23.cmd [FAIL]
Assert failure(PID 7968 [0x00001f20], Thread: 5880 [0x16f8]): Consistency check failed: Crst Level violation: Can't take level 17 lock CrstInstMethodHashTable because you already holding level 17 lock CrstInstMethodHashTable
FAILED: false
CORECLR! CHECK::Trigger + 0x2D1 (0x00007ffc`005929b1)
CORECLR! CrstBase::IsSafeToTake + 0x36D (0x00007ffb`ffeb044d)
CORECLR! CrstBase::Enter + 0x196 (0x00007ffb`ffeafd56)
CORECLR! InstantiatedMethodDesc::NewInstantiatedMethodDesc + 0xC0C (0x00007ffc`001c3c8c)
CORECLR! MethodDesc::FindOrCreateAssociatedMethodDesc + 0x21E8 (0x00007ffc`001bff78)
CORECLR! MethodDesc::FindOrCreateAssociatedMethodDesc + 0x20FA (0x00007ffc`001bfe8a)
CORECLR! MethodDesc::FindOrCreateAssociatedMethodDesc + 0x1612 (0x00007ffc`001bf3a2)
CORECLR! MethodDesc::ResolveGenericVirtualMethod + 0xB18 (0x00007ffb`fffbae38)
CORECLR! MethodDesc::GetMultiCallableAddrOfVirtualizedCode + 0x3C4 (0x00007ffb`fffb4014)
CORECLR! JIT_VirtualFunctionPointer_Framed + 0x321 (0x00007ffc`00234ae1)
File: D:\a\_work\1\s\src\coreclr\vm\crst.cpp Line: 763
Image: C:\h\w\B71709A2\p\corerun.exe
Return code: 1
Raw output file: C:\h\w\B71709A2\w\AE8609CF\uploads\Reports\baseservices.threading\generics\WaitCallback\thread23\thread23.output.txt
Raw output:
BEGIN EXECUTION
"C:\h\w\B71709A2\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" thread23.dll
Expected: 100
Actual: -1073740286
END EXECUTION - FAILED
Activity
BruceForstall commentedon Jun 20, 2022
@davidwrighton Maybe related to your big #68919?
davidwrighton commentedon Jun 21, 2022
I'm taking a look now.
davidwrighton commentedon Jun 21, 2022
The problem is in the adjusted computation of ComputeLoaderModule. With the new logic the loader module may be different, which will cause different hashtables for the instMethodHash to be used. This can cause this problem. I'll be looking into what to do to fix this, and if its an already existing problem for some of the loader module patterns we already have, but in the meantime, I'm going to revert my larger change.