Thank you. I have already reported a bug: FB17407067. This issue exists not only in macOS 14.6.1, 15.4.1, and iOS 18.3.1, but likely in more versions as well. We have implemented our own in-process crash reporter, which has caused the SIGBUS recovery mechanism of the V8 virtual machine to stop working properly, leading us to discover this issue.

We attempted to capture Go panic crash information on Darwin, but found that Go panics triggered by cgo calls under GCD fail to generate logs. Through comparative testing, we discovered that the issue arises because calling raise to throw SIGABRT does not block the thread under GCD. I'm curious: is this problem caused by GCD or by XNU? Also, could you please explain how this issue occurs? thx.

Meanwhile, in this case, the stack trace of the crashed thread generated by Apple CrashReporter is also incorrect. The test code is as follows: #import <Foundation/Foundation.h> int main(int argc, const char * argv[]) { dispatch_async(dispatch_get_global_queue(0, 0), ^{ raise(SIGABRT); }); printf("Test"); [[NSRunLoop mainRunLoop] run]; return 0; } Crash log gen by Apple CrashReporter: Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: CrashTestMac [32830] Thread 0 Crashed: 0 libdispatch.dylib 0x195ef99ac 0x195ef5000 + 18860 1 CoreFoundation 0x1961226f0 0x19611d000 + 22256 2 CoreFoundation 0x19615b5a4 0x19611d000 + 255396 3 CoreFoundation 0x19615b4f4 0x19611d000 + 255220 4 CoreFoundation 0x19615c69c 0x19611d000 + 259740 5 CoreFoundation 0x19615c46c 0x19611d000 + 259180 6 CoreFoundation 0x19626bd34 0x19611d000 + 1371444 7 libdispatch.dylib 0x195f1085c 0x195ef5000 + 112732 8 libdispatch.dylib 0x195ef9a28 0x195ef5000 + 18984 9 CoreFoundation 0x19616062c 0x19611d000 + 276012 10 Foundation 0x1977a793c 0x19770d000 + 633148 11 CrashTestMac 0x10091bea0 main + 104 (main.m:7) 12 dyld 0x195d0eb98 0x195d08000 + 27544 The crash site is incorrectly shown as [[NSRunLoop mainRunLoop] run], and when debugging with lldb, it still points to this line.