Me too, Chrome and Safari on iPad.

This limitation is also documented at the Eclectic Light web site, see the Networking section of this page: https://eclecticlight.co/2023/09/14/current-limitations-on-macos-virtual-machines-running-on-apple-silicon-macs/

Why questions are hard. In this case I suspect the answer is “Because BSD has always behaved this way.” As far as I can determine, the flag O_SYMLINK only exists on macOS, so its behavior isn’t really a BSD question. However, finding a definitive answer would require more research than I have time for right now. That’s reasonable.

Thanks for the hints on simplifying my signal handler, but it looks like the unpleasantness at the top of the stack trace is just an artifact of Rosetta. The trace is cleaner on Intel.

I'm using Objective-C++, and I don't know how this translates to Swift, but I use a pattern like this: if (@available( macOS 10.15, * )) { // do it the new way } else { #pragma clang diagnostic push #pragma clang diagnostic ignored "-Wdeprecated-declarations" // do it the old way #pragma clang diagnostic pop }

How is your app signed? A problem with the signature might prevent the OS from "remembering" that permission has been granted before.

If you're using the tools from Xcode 15, you should be able to use the flag -std=c++2b. And yes, that is a b instead of a 3.

The _sigtramp in the stack trace suggests that some code in your app process was trying to handle the SIGSEGV signal - either code you wrote, or a third party crash reporter package. You're right, I do have a sigaction handler, which writes to a file and then attempts to re-send the signal as follows: signal( inSignal, SIG_DFL ); // restore default signal handling pthread_kill( pthread_self(), inSignal ); // re-send the signal usleep( 10000 ); /* give time for signal to happen */ Is this kind of signal handler doomed to mess up the stack trace, or is there a more careful way I could do it?

Did you try adding it as a text attachment? See Posting a Crash Report for the specifics. No, didn't think of that... KVO-crash.txt This crash report is coming from Rosetta. Is that expected? Yes, the app is x86_64 only. Performance on Apple Silicon seems fine, so updating that hasn't seemed like a priority.

I tried to add the full crash report, but the forum software won't let me, I guess it's too long. I've added as much as I could. I usually debug using Address Sanitizer, and that hasn't helped me in this case. I tried launching in Terminal with NSZombieEnabled=1, is that pretty much the same as using the Zombies instrument? Does your application include a 3rd party crash reporter? Depends on what you mean. I have a helper that watches to see if my app crashes, and if so offers to send me the report. But it doesn't do any funny business to create its own crash report, it just looks for the one written by Apple. Process: MyApp 4.2 [903] Path: /Users/USER/*/MyApp 4.2.app/Contents/MacOS/MyApp 4.2 Identifier: com.myapp.myapp Version: 4.2.0.2 (4.2.0.2) Code Type: X86-64 (Translated) Parent Process: launchd [1] User ID: 501 Date/Time: 2023-11-19 15:02:56.8986 -0800 OS Version: macOS 14.2 (23C5047e) Report Version: 12 Anonymous UUID: E2250852-79B5-CFB8-A8CE-C60A82A41C40 Time Awake Since Boot: 180 seconds System Integrity Protection: enabled Notes: PC register does not match crashing frame (0x0 vs 0x1022A3630) Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000018 Exception Codes: 0x0000000000000001, 0x0000000000000018 VM Region Info: 0x18 is not in any region. Bytes before following region: 140723250839528 REGION TYPE START - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> mapped file 7ffcaf60c000-7ffcd7f48000 [649.2M] r-x/r-x SM=COW ...t_id=b7394f27 Error Formulating Crash Report: PC register does not match crashing frame (0x0 vs 0x1022A3630) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 <translation info unavailable> 0x1022a3630 ??? 1 libsystem_platform.dylib 0x7ff819d0b393 _sigtramp + 51 2 AppKit 0x7ff81d3549a6 -[NSControl _setWindow:] + 59 3 AppKit 0x7ff81d413c19 -[NSSegmentedControl _setWindow:] + 42 4 AppKit 0x7ff81defd3be __21-[NSView _setWindow:]_block_invoke.391 + 324 5 AppKit 0x7ff81d33a62c -[NSView _setWindow:] + 1886 6 AppKit 0x7ff81defd3be __21-[NSView _setWindow:]_block_invoke.391 + 324 7 AppKit 0x7ff81d33a62c -[NSView _setWindow:] + 1886 8 AppKit 0x7ff81d572d08 -[NSWindow dealloc] + 922 9 MyApp 4.2 0x1011b6b81 0x100ef3000 + 2898817 10 Foundation 0x7ff81b3d179c _NSKVOPerformWithDeallocatingObservable + 151 11 Foundation 0x7ff81acc6d54 NSKVODeallocate + 150 12 libobjc.A.dylib 0x7ff8199189d7 AutoreleasePoolPage::releaseUntil(objc_object**) + 169 13 libobjc.A.dylib 0x7ff819915cf0 objc_autoreleasePoolPop + 235 14 CoreFoundation 0x7ff819d794a1 _CFAutoreleasePoolPop + 22 15 Foundation 0x7ff81ac869ea -[NSAutoreleasePool drain] + 133 16 AppKit 0x7ff81d315694 -[NSApplication run] + 653 17 AppKit 0x7ff81d2e9662 NSApplicationMain + 816 18 MyApp 4.2 0x100ef5034 0x100ef3000 + 8244 Thread 1:: com.apple.rosetta.exceptionserver 0 runtime 0x7ff7fff10294 0x7ff7fff0c000 + 17044 Thread 2: 0 runtime 0x7ff7fff2e94c 0x7ff7fff0c000 + 141644 Thread 3:: com.apple.NSURLConnectionLoader 0 ??? 0x7ff8aa25ea78 ??? 1 libsystem_kernel.dylib 0x7ff819c9da0e mach_msg2_trap + 10 2 libsystem_kernel.dylib 0x7ff819cabe1a mach_msg2_internal + 84 3 libsystem_kernel.dylib 0x7ff819ca4b42 mach_msg_overwrite + 653 4 libsystem_kernel.dylib 0x7ff819c9dcff mach_msg + 19 5 CoreFoundation 0x7ff819db8b19 __CFRunLoopServiceMachPort + 143 6 CoreFoundation 0x7ff819db758c __CFRunLoopRun + 1371 7 CoreFoundation 0x7ff819db6a69 CFRunLoopRunSpecific + 557 8 CFNetwork 0x7ff81f05add9 0x7ff81ee13000 + 2391513 9 Foundation 0x7ff81acab78c __NSThread__start__ + 1013 10 libsystem_pthread.dylib 0x7ff819cdd202 _pthread_start + 99 11 libsystem_pthread.dylib 0x7ff819cd8bab thread_start + 15 Thread 4:: com.apple.CFSocket.private 0 ??? 0x7ff8aa25ea78 ??? 1 libsystem_kernel.dylib 0x7ff819ca68fe __select + 10 2 CoreFoundation 0x7ff819de067f __CFSocketManager + 637 3 libsystem_pthread.dylib 0x7ff819cdd202 _pthread_start + 99 4 libsystem_pthread.dylib 0x7ff819cd8bab thread_start + 15 Thread 5:: com.apple.NSEventThread 0 ??? 0x7ff8aa25ea78 ??? 1 libsystem_kernel.dylib 0x7ff819c9da0e mach_msg2_trap + 10 2 libsystem_kernel.dylib 0x7ff819cabe1a mach_msg2_internal + 84 3 libsystem_kernel.dylib 0x7ff819ca4b42 mach_msg_overwrite + 653 4 libsystem_kernel.dylib 0x7ff819c9dcff mach_msg + 19 5 CoreFoundation 0x7ff819db8b19 __CFRunLoopServiceMachPort + 143 6 CoreFoundation 0x7ff819db758c __CFRunLoopRun + 1371 7 CoreFoundation 0x7ff819db6a69 CFRunLoopRunSpecific + 557 8 AppKit 0x7ff81d48176c _NSEventThread + 122 9 libsystem_pthread.dylib 0x7ff819cdd202 _pthread_start + 99 10 libsystem_pthread.dylib 0x7ff819cd8bab thread_start + 15 Thread 6:: engine.unload-texture 0 ??? 0x7ff8aa25ea78 ??? 1 libsystem_kernel.dylib 0x7ff819ca05ae __psynch_cvwait + 10 2 libsystem_pthread.dylib 0x7ff819cdd76b _pthread_cond_wait + 1211 3 libc++.1.dylib 0x7ff819c153c2 std::__1::condition_variable::wait(std::__1::unique_lock<std::__1::mutex>&) + 18 4 SBEngineLib4 0x10b8315f0 WorkerThreadLoop() + 81 5 SBEngineLib4 0x10b83208d void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct>>, void (*)()>>(void*) + 36 6 libsystem_pthread.dylib 0x7ff819cdd202 _pthread_start + 99 7 libsystem_pthread.dylib 0x7ff819cd8bab thread_start + 15 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x00007fb73664b360 rbx: 0x00007fb7860aa5f0 rcx: 0x00007fb7860aa5f0 rdx: 0x0000000000000000

One thing to watch out for during development is that Xcode: Builds all your apps and frameworks into your Products/Debug directory Set up a dynamic linker environment variable to force your apps to look for framework in that same directory I have specified legacy build locations in my project, so that the app and frameworks are built in different directories.

The frameworks SBEngineLib4.framework and Cal3D.framework exist in the main app. Having one app load frameworks out of an ‘unrelated’ app is a tricky business. Perhaps I wasn't clear, but I definitely wasn't trying to have one app load frameworks out of another app. The main app contains private frameworks just for its own use, and the helper contains dylibs for its own use. It's just under this debugging situation that things somehow got confused.

Aha! When I re-signed the helper app using the hardened runtime and an entitlements file that sets com.apple.security.cs.allow-unsigned-executable-memory to YES, then the helper runs even when I'm debugging. I don't know why it needs that entitlement, but it probably has something to do with the helper was built using the FireMonkey framework, not Xcode. So, thanks for asking about hardened runtime.

I tried re-signing the helper with the hardened runtime, and then it won't launch at all. Trying to launch it in Terminal shows Runtime error 217 at 000000011003B572 Googling "runtime error 217" just shows Windows errors.

Is this helper app nested within your main app? No. That means you selected your main app’s scheme and chose Product > Run, right? So you’re debugging the main app and hit this problem when the main app tries to run the helper app. Correct. Is any of this stuff sandboxed? No. If not, do you have the hardened runtime enabled? Hardened runtime is enabled for the main app, not the helper. Is the main app running the helper as a child process (fork then exec*, or posix_spawn, or NSTask, or Process, or similar). Or as an independent app (NSWorkspace, or Launch Services, or similar)? Running as an independent app using -[NSWorkspace openApplicationAtURL:configuration:completionHandler:]. The configuration includes an additional argument.