Closed CyberAndrii closed 2 weeks ago
cc @AaronRobinsonMSFT
Tagging subscribers to this area: @dotnet/area-system-runtime-compilerservices See info in area-owners.md if you want to be subscribed.
Seems to be failing during instrumentation for PGO
Assert failure(PID 21772 [0x0000550c], Thread: 33224 [0x81c8]): Consistency check failed: AV in clr at this callstack:
------
CORECLR! tagCOR_ILMETHOD_FAT::GetCodeSize + 0x12 (0x00007ffb`69cad322)
CORECLR! CEEJitInfo::allocPgoInstrumentationBySchema + 0x2E7 (0x00007ffb`69cbbc77)
CLRJIT! Compiler::fgInstrumentMethod + 0x6A8 (0x00007ffb`ca6c6f28)
CLRJIT! CompilerPhaseWithStatus::DoPhase + 0x2B (0x00007ffb`ca6364db)
CLRJIT! Phase::Run + 0x6D (0x00007ffb`ca89de7d)
CLRJIT! DoPhase + 0x35 (0x00007ffb`ca636425)
CLRJIT! Compiler::compCompile + 0x20C (0x00007ffb`ca640bac)
CLRJIT! Compiler::compCompileHelper + 0x1212 (0x00007ffb`ca6450d2)
CLRJIT! `Compiler::compCompile'::`170'::__Body::Run + 0x69 (0x00007ffb`ca63ea79)
CLRJIT! Compiler::compCompile + 0xFC1 (0x00007ffb`ca6434e1)
CLRJIT! ``jitNativeCode'::`8'::__Body::Run'::`6'::__Body::Run + 0x189 (0x00007ffb`ca63e909)
CLRJIT! `jitNativeCode'::`8'::__Body::Run + 0x6D (0x00007ffb`ca63e98d)
CLRJIT! jitNativeCode + 0x19A (0x00007ffb`ca64dc2a)
CLRJIT! CILJit::compileMethod + 0x1A6 (0x00007ffb`ca6589f6)
CORECLR! invokeCompileMethodHelper + 0x1A0 (0x00007ffb`69cdfa70)
CORECLR! invokeCompileMethod + 0x1B9 (0x00007ffb`69cdf839)
CORECLR! UnsafeJitFunction + 0xB88 (0x00007ffb`69cba218)
CORECLR! MethodDesc::JitCompileCodeLocked + 0x239 (0x00007ffb`69da82c9)
CORECLR! MethodDesc::JitCompileCodeLockedEventWrapper + 0x3E3 (0x00007ffb`69da8a53)
-----
This is likely caused by a JIT optimization.
@CyberAndrii Agree. There are few cases where the generated IL for the UnsafeAccessor
method won't be inlined. Applying the [MethodImpl(MethodImplOptions.NoOptimization)]
would mean inlining isn't occurring and a small thunk is present, that is very help data. Can you try removing [MethodImpl(MethodImplOptions.NoOptimization)]
, but disable Tiered Compilation? That can be accomplished by setting the following environment variable - DOTNET_TieredCompilation=0
.
@dotnet/jit-contrib What can we collect here that would help root out the issue? Is a JIT dump sufficient?
Thanks @EgorBo! Didn't see your reply. Let me know if this is something I should be able to handle.
Thanks @EgorBo! Didn't see your reply. Let me know if this is something I should be able to handle.
From a quick look, it seems that GetAndVerifyILHeader
returns NULL for Func
and it is not expected (we only expect nulled ILHeader for dynamic methods)
GetAndVerifyILHeader
Oh... this is another one. Okay. I will handle this. We had a few of these during the first pass of UnsafeAccessor
work.
The actual crash is basically a null-reference on GetCodeSize() call here
Bah. This is definitely a VM issue. Thanks @EgorBo for the pointer. I have a local repro and see the issue; as I mentioned, this is yet another place where we assume only dynamic MethodDesc
instances lack a header. I'm in transit but should have a fix by EOD.
Flight is delayed so code gets fixed :-) Looks like this upper code section was actually "dead" anyways. I traced through the PgoManager
class and it appears to be doing the right thing with UnsafeAccessor
methods, so we are good there - yay!
Description
Calling a virtual method via
UnsafeAccessor
many times crashes the runtime with exit code 139. This is likely caused by a JIT optimization.Reproduction Steps
Expected behavior
Prints:
Exit code: 0
Actual behavior
Prints:
Exit code: 139
Regression?
No. Crashes on both .NET 8 and 9.
Known Workarounds
Apply
[MethodImpl(MethodImplOptions.NoOptimization)]
to the UnsafeAccessor method.Configuration
Happens on both linux-x64 and osx-x64.
Other information
No response