JIT: Runtime_82535 crashes on osx x64

[markples]

Failure was on osx x64, but the original issue suggests that it could fail on multiple platforms and architectures.

#82663 added test JIT/Regression/JitBlue/Runtime_82535, which failed under mono and coreclr. mono was fixed in that PR. coreclr stopped failing, but it appears to be because the test stopped running. #89521 fixes the issue that stopped it from running and exposes the failure again.

07:07:35.703 Running test: JIT/Regression/JitBlue/Runtime_82535/Runtime_82535/Runtime_82535.dll
[createdump] Invalid process id: task_for_pid(986) FAILED (os/kern) failure (5)
[createdump] This failure may be because createdump or the application is not properly signed and entitled.
[createdump] Target process is alive
[createdump] Failure took 16ms
waitpid() returned successfully (wstatus 0000ff00) WEXITSTATUS ff WTERMSIG 0
App Exit Code: 22
Expected: 100
Actual: 22
END EXECUTION - FAILED

[ghost]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Failure was on osx x64, but the original issue suggests that it could fail on multiple platforms and architectures.

#82663 added test JIT/Regression/JitBlue/Runtime_82535, which failed under mono and coreclr. mono was fixed in that PR. coreclr stopped failing, but it appears to be because the test stopped running. #89521 fixes the issue that stopped it from running and exposes the failure again.

07:07:35.703 Running test: JIT/Regression/JitBlue/Runtime_82535/Runtime_82535/Runtime_82535.dll
[createdump] Invalid process id: task_for_pid(986) FAILED (os/kern) failure (5)
[createdump] This failure may be because createdump or the application is not properly signed and entitled.
[createdump] Target process is alive
[createdump] Failure took 16ms
waitpid() returned successfully (wstatus 0000ff00) WEXITSTATUS ff WTERMSIG 0
App Exit Code: 22
Expected: 100
Actual: 22
END EXECUTION - FAILED

Author:	markples
Assignees:	-
Labels:	os-mac-os-x, arch-x64, area-CodeGen-coreclr
Milestone:	-

[BruceForstall]

Test PR re-enabling the test: #90290

[BruceForstall]

The test PR verified it still fails.

[BruceForstall]

This test hits a null reference exception inside a write barrier helper (as part of copying a struct). The VM then hits an exception during the processing of this:

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000102fcd977 libcoreclr.dylib`EECodeInfo::GetFunctionEntry() + 39
    frame #1: 0x000000010330c34d libcoreclr.dylib`UnwindManagedExceptionPass1(PAL_SEHException&, _CONTEXT*) + 285
    frame #2: 0x000000010330cecd libcoreclr.dylib`DispatchManagedException(PAL_SEHException&, bool) + 541
    frame #3: 0x0000000103300061 libcoreclr.dylib`HandleHardwareException(PAL_SEHException*) + 1105
    frame #4: 0x0000000102dc68fd libcoreclr.dylib`SEHProcessException(PAL_SEHException*) + 253
    frame #5: 0x0000000102e5e5f1 libcoreclr.dylib`PAL_DispatchExceptionInner(_CONTEXT*, _EXCEPTION_RECORD*) + 289
    frame #6: 0x0000000102e5e48a libcoreclr.dylib`PAL_DispatchException + 74
    frame #7: 0x0000000102e5d914 libcoreclr.dylib`PAL_DispatchExceptionWrapper + 10
    frame #8: 0x00000001034507b0 libcoreclr.dylib`UpdateCardBundle_ByRefWriteBarrier + 16
    frame #9: 0x000000011d7e4ff7
    frame #10: 0x000000011d7e4e84
    frame #11: 0x00000001034500a1 libcoreclr.dylib`CallDescrWorkerInternal + 124
    frame #12: 0x00000001030ee7cb libcoreclr.dylib`CallDescrWorkerWithHandler(CallDescrData*, int) + 315
    frame #13: 0x00000001030ef3fe libcoreclr.dylib`MethodDescCallSite::CallTargetWorker(unsigned long long const*, unsigned long long*, int) + 2174
    frame #14: 0x0000000102ea08d2 libcoreclr.dylib`MethodDescCallSite::Call_RetArgSlot(unsigned long long const*) + 162
    frame #15: 0x0000000102ea06ab libcoreclr.dylib`RunMainInternal(Param*) + 667
    frame #16: 0x0000000102ea03e9 libcoreclr.dylib`RunMain(MethodDesc*, short, int*, REF<PtrArray>*)::$_1::operator()(Param*) const::'lambda'(Param*)::operator()(Param*) const + 25
    frame #17: 0x0000000102e9b786 libcoreclr.dylib`RunMain(MethodDesc*, short, int*, REF<PtrArray>*)::$_1::operator()(Param*) const + 70
    frame #18: 0x0000000102e9b565 libcoreclr.dylib`RunMain(MethodDesc*, short, int*, REF<PtrArray>*) + 453
    frame #19: 0x0000000102e9bb91 libcoreclr.dylib`Assembly::ExecuteMainMethod(REF<PtrArray>*, int) + 529
    frame #20: 0x0000000102f0efbc libcoreclr.dylib`CorHost2::ExecuteAssembly(unsigned int, char16_t const*, int, char16_t const**, unsigned int*) + 2044
    frame #21: 0x0000000102e686d6 libcoreclr.dylib`coreclr_execute_assembly + 342
    frame #22: 0x00000001000054ad corerun`run(config=0x00007ff7bfeff1d8) at corerun.cpp:429:18
    frame #23: 0x0000000100002684 corerun`main(argc=2, argv=0x00007ff7bfeff548) at corerun.cpp:624:21
    frame #24: 0x00007ff8137f241f dyld`start + 1903

In this case, we're calling LazyGetFunctionEntry:

runtime/src/coreclr/vm/jitinterface.cpp

Lines 14502 to 14510 in 3be8fa1

	PTR_RUNTIME_FUNCTION EECodeInfo::GetFunctionEntry()
	{
	LIMITED_METHOD_CONTRACT;
	SUPPORTS_DAC;
	if (m_pFunctionEntry == NULL)
	m_pFunctionEntry = m_pJM->LazyGetFunctionEntry(this);
	return m_pFunctionEntry;
	}

and m_pJM is null.

[BruceForstall]

@mangod9 This looks like an exception handling bug in the VM.

[janvorli]

Based on the stack trace above, I think the issue is caused by the fact that the labels inside of JIT_ByRefWriteBarrier are not wrapped in LOCAL_LABEL macro. The libunwind then doesn't find correct unwind info for the whole function, it thinks that the closest label before the current ip is the actual function start. I was hiting similar issues during other work on macOS x64.
I am working on a fix.

[janvorli]

Reopening until the port to 8 is done