LLDB crash

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 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

On the crash, can you tell what Vision.framework is doing? On my iOS 18.5 (I don't have iPad, but I suppose it's similar, if not same.), the crash point (-[VNCoreMLModel predictWithCVPixelBuffer:options:error:] + 148) is attempting to access .model property of VNCoreMLModel object. (lldb) dis -s 0x00000001bc61626c -e 0x00000001bc61626c+148 Vision`-[VNCoreMLModel predictWithCVPixelBuffer:options:error:]: : ;; x0 is self, which is `VNCoreMLModel` object. 0x1bc616290 <+36>: mov x23, x0 : ;; Accessing `.model` property of the `VNCoreMLModel` object. 0x1bc6162f8 <+140>: mov x0, x23 0x1bc6162fc <+144>: bl 0x1bc857f60 ; objc_msgSend$model ;; Return address 0x1bc616300 <+148>: bl 0x1bdf7d200 If you see the same, I might suspect the MLModel object stored in CoreMLModelContainer is somehow broken, perhaps overreleased. (It's hard to tell whether it's a framework bug or application's bug. )

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.

Thank you Quinn for your support. I finally solved the issue. I checked the system log and found this error: syspolicyd: [com.apple.syspolicy.exec:default] Error Domain=GatekeeperPolicyScanError Code=-67018 Code did not match any currently allowed policy UserInfo={NSURL=file:///Applications/HotelOrganizer.app/Contents/Frameworks/numpy/_core/_multiarray_umath.cpython-311-darwin.so, NSLocalizedDescription=Code did not match any currently allowed policy} I then tried to delete the file _multiarray_umath.cpython-311-darwin.so from my app bundle, and the gatekeeper finally accepted the app. BINGO! However, without that files, my app crashes. Thus I tried to move this file from Frameworks folder to Resources folder and it also worked with gatekeeper. After some fighting with pyinstaller and other dependencies that were refusing to import numpy from the new location, I finally manage to defeat gatekeeper while having my app working well. Now some feedback for Apple: I find it completely illogical that gatek

Smart Keyboard make crash iPad after ipados26. Io i use iPad without magickeybord iPad works

I am getting frequent crashes in Xcode 16.4 that is running on macOS 26 Beta 4 restarting when Previews are active. It happens especially if you change some code in the swift file. The next thing is it freezes, a magenta screen appears for a while, then macOS restarts.

The other way was to quit by using Command+Q, then it would crash. On the next launch, the screen appearing that shows New Project or select recent would appear. This would prevent opening the previously open project.