I'm developing a sandboxed application with Xcode which allows the user to open and work with Audio Unit plugins. Working with a beta-tester having a lot of AUs on its laptop running on macOS 12.5.1, we encountered some weird crashes while opening some plugins (Krotos, Flux Audio, Sound Toys, etc.). The message we got was in French, I try to translate it but the original English version could be a little bit different: Impossible to open “NSCreateObjectFileImageFromMemory-p47UEwps” because the developper can not be verified. After this first warning, a Fatal Error 100001 message opens and the plugin seems crashed (but not the host). I easily found some music application users encountering similar issues on the web. From what I read, this error is related to new security rules introduced in macOS 12. And, effectively, some of these plugins tested on an older system work normally. I also read that some (insecure) entitlements of the Hardened Runtime should be able to fix this issue, especially Allow Unsigned Executable Memory Entitlement, whose the doc says: In rare cases, an app might need to override or patch C code, use the long-deprecated NSCreateObjectFileImageFromMemory (which is fundamentally insecure), or use the DVDPlayback framework. Add the Allow Unsigned Executable Memory Entitlement to enable these use cases. Otherwise, the app might crash or behave in unexpected ways. Unfortunately, checking this option didn't fix the issue. So, what I tried next was to add Disable Executable Memory Protection (no more success), and finally Allow DYLD Environment Variables and Allow Execution of JIT-compiled Code: none of them solved my problem. I really don't see what else to do, while I'm sure that a solution exists because the same plugins work perfectly on other application (Logic, Live Ableton). Any help would be greatly appreciated. Thanks !

Hello, I have received 3 almost identical crash reports from the App Store. They all come from the same user, and they are spaced just ± 45 seconds apart. This is the backtrace of the crashed thread: Crashed Thread: 3 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Ssssssss [46033] Thread 3 Crashed: 0 libsystem_kernel.dylib 0x00007ff81b90f196 __pthread_kill + 10 1 libsystem_pthread.dylib 0x00007ff81b946ee6 pthread_kill + 263 (pthread.c:1670) 2 libsystem_c.dylib 0x00007ff81b86dbdf __abort + 139 (abort.c:155) 3 libsystem_c.dylib 0x00007ff81b86db54 abort + 138 (abort.c:126) 4 libc++abi.dylib 0x00007ff81b901282 abort_message + 241 5 libc++abi.dylib 0x00007ff81b8f33fb demangling_terminate_handler() + 267 6 libobjc.A.dylib 0x00007ff81b5c67ca _objc_terminate() + 96 (objc-exception.mm:498) 7 libc++abi.dylib 0x00007ff81b9006db std::__terminate(void (*)()) + 6 8 libc++abi.dylib 0x00007ff81b900696 std::terminate() + 54 9 libdispatch.dylib 0x00007ff81b7a6047 _dispatch_client_callout + 28 (object.m:563) 10 libdispatch.dylib 0x00007ff81b7a87c4 _dispatch_queue_override_invoke + 800 (queue.c:4882) 11 libdispatch.dylib 0x00007ff81b7b5fa2 _dispatch_root_queue_drain + 343 (queue.c:7051) 12 libdispatch.dylib 0x00007ff81b7b6768 _dispatch_worker_thread2 + 170 (queue.c:7119) 13 libsystem_pthread.dylib 0x00007ff81b943c0f _pthread_wqthread + 257 (pthread.c:2631) 14 libsystem_pthread.dylib 0x00007ff81b942bbf start_wqthread + 15 (:-1) In the backtrace of the main thread, I can see that the error is caught by the app delegate which tries to display an alert, but obviously the message has no time to appear. Incidentally (but it's not my main question), I would like to know if it would be possible in such a case to block the background thread for the time the alert is displayed (e.g. using a dispatch queue)? ... (many other related lines) 72 SSUuuuIIIIIIIIIUUuuuu 0x000000010e8089f2 +[NSAlert(Ssssssss) fatalError:] + 32 73 Ssssssss 0x000000010dd5e75b __universalExceptionHandler_block_invoke (in Ssssssss) (SQAppDelegate.m:421) + 333659 74 libdispatch.dylib 0x00007ff81b7a4d91 _dispatch_call_block_and_release + 12 (init.c:1518) 75 libdispatch.dylib 0x00007ff81b7a6033 _dispatch_client_callout + 8 (object.m:560) 76 libdispatch.dylib 0x00007ff81b7b2fcf _dispatch_main_queue_drain + 954 (queue.c:7794) 77 libdispatch.dylib 0x00007ff81b7b2c07 _dispatch_main_queue_callback_4CF + 31 (queue.c:7954) 78 CoreFoundation 0x00007ff81ba62195 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9 (CFRunLoop.c:1780) 79 CoreFoundation 0x00007ff81ba21ebf __CFRunLoopRun + 2452 (CFRunLoop.c:3147) 80 CoreFoundation 0x00007ff81ba20ec1 CFRunLoopRunSpecific + 560 (CFRunLoop.c:3418) 81 HIToolbox 0x00007ff8254a5f3d RunCurrentEventLoopInMode + 292 (EventLoop.c:455) 82 HIToolbox 0x00007ff8254a5d4e ReceiveNextEventCommon + 657 (EventBlocking.c:384) 83 HIToolbox 0x00007ff8254a5aa8 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (EventBlocking.c:171) 84 AppKit 0x00007ff81eabfb18 _DPSNextEvent + 858 (CGDPSReplacement.m:818) 85 AppKit 0x00007ff81eabe9c2 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1214 (appEventRouting.m:407) 86 AppKit 0x00007ff81eab1037 -[NSApplication run] + 586 (NSApplication.m:3432) 87 AppKit 0x00007ff81ea85251 NSApplicationMain + 817 (NSApplication.m:9427) 88 dyld 0x00007ff81b5ec41f start + 1903 (dyldMain.cpp:1165) In all 3 reports, another thread indicates that it is sending or receiving a MIDI data (it's exactly the same backtrace in the 3 reports): Thread 1: 0 libsystem_kernel.dylib 0x00007ff81b908552 mach_msg2_trap + 10 1 libsystem_kernel.dylib 0x00007ff81b9166cd mach_msg2_internal + 78 (mach_msg.c:201) 2 libsystem_kernel.dylib 0x00007ff81b90f584 mach_msg_overwrite + 692 (mach_msg.c:0) 3 libsystem_kernel.dylib 0x00007ff81b90883a mach_msg + 19 (mach_msg.c:323) 4 CoreMIDI 0x00007ff834adfd50 XServerMachPort::ReceiveMessage(int&, void*, int&) + 94 (XMachPort.cpp:62) 5 CoreMIDI 0x00007ff834b118c5 MIDIProcess::MIDIInPortThread::Run() + 105 (MIDIClientLib.cpp:204) 6 CoreMIDI 0x00007ff834af9c44 CADeprecated::XThread::RunHelper(void*) + 10 (XThread.cpp:21) 7 CoreMIDI 0x00007ff834afae9f CADeprecated::CAPThread::Entry(CADeprecated::CAPThread*) + 77 (CAPThread.cpp:324) 8 libsystem_pthread.dylib 0x00007ff81b9471d3 _pthread_start + 125 (pthread.c:893) 9 libsystem_pthread.dylib 0x00007ff81b942bd3 thread_start + 15 (:-1) I wonder if this MIDI activity may be related to the crash, even if it doesn't occur in the crashed thread. I also wonder if the dispatch block starting the backtrace of the thread 3 is the same that leads to the thread 1 (to open the NSAlert), which would mean that it's after the error, or if it's a dispatch block into which the error occurs. Finally, 2024-03-25_13-04-40.6314.crash I wonder if std::terminate() could indicate a problem in C++ codes because I have some part of the application written in C++, and it would be a clue. More generally, is it something in these backtraces that can help me to find what's the problem ? Any help greatly appreciated, thanks! -dp

Hello, I'm trying to simulate miscellaneous crashes to test my handlers. Things works as expected with NSException and C++ exceptions, however I cannot find a way to trig a C signal. I tried with this code: NSArray *runningApplications = [NSRunningApplication runningApplicationsWithBundleIdentifier:@"com.myCompany.myApp"]; NSRunningApplication *app = runningApplications[0]; UInt32 pid = [app processIdentifier]; kill(pid, SIGABRT); It is caught by my handler, but it doesn't crash the app (although it's detached from the debugger), I can even continue using the app normally. I'm wondering if this could be related to something wrong in my handler (especially on how it ends): signal(sig, SIG_IGN); dispatch_source_t source = dispatch_source_create(DISPATCH_SOURCE_TYPE_SIGNAL, sig, 0, dispatch_get_global_queue(0, 0)); dispatch_source_set_event_handler(source, ^{ // I write some logs on disk here, then uninstall the handlers associated with this or that signal: for(int i=0; i<SignalSourceCount; i++) { if (_signalSources[i]) { dispatch_source_cancel(_signalSources[i]); _signalSources[i] = NULL; } } }); dispatch_resume(source); I've seen some examples finishing rather with exit() or abort(). Abort crashes the app as expected, however the Crash Report produced by Apple then focuses on the handler instead of the code triggering the signal... Any help appreciated, thanks

Hi, A user sent us a crash report that indicates an error occurring just after loading the default Metal library of our app. Application Specific Information: Crashing on exception: *** -[__NSArrayM objectAtIndex:]: index 0 beyond bounds for empty array The report pointed me to these (simplified) lines of codes in the library setup: _vertexFunctions = [[NSMutableArray alloc] init]; _fragmentFunctions = [[NSMutableArray alloc] init]; id<MTLLibrary> library = [device newDefaultLibrary]; 2 vertex shaders and 5 fragment shaders are then loaded and stored in these two arrays using this method: -(BOOL) addShaderNamed:(NSString *)name library:(id<MTLLibrary>)library isFragment:(BOOL)isFragment { id shader = [library newFunctionWithName:name]; if (!shader) { ALOG(@"Error : Unable to find the shader named : “%@”", name); return NO; } [(isFragment ? _fragmentFunctions : _vertexFunctions) addObject:shader]; return YES; } As you can see, the arrays are not filled if the method fails... however, a few lines later, they are used without checking if they are really filled, and that causes the crash... But this coding error doesn't explain why no shader of a certain type (or both types) have been added to the array, meaning: why -newFunctionWithName: returned nil for all given names (since the implied array appears completely empty)? Clue This error has only be detected once by a user running the app on macOS 10.13 with a NVIDIA Web Driver instead of the default macOS graphic driver. Moreover, it wasn't possible to reproduce the problem on the same OS using the native macOS driver. So my question is: is it some known conflicts between NVIDIA drivers and the use of Metal libraries? Or does this case would require some specific options in the Metal implementation? Any help appreciated, thanks!

Hi, I develop a Mac application, initially on Catalina/Xcode12, but I recently upgrade to Monterey/Xcode13. I'm about to publish a new version: on Monterey all works as expected, but when I try the app on Sequoia, as a last step before uploading to the App Store, I encountered some weird security issues: The main symptom is that it's no longer possible to save any file from the app using the Save panel, although the User Select File entitlement is set to Read/Write. I've tried reinstalling different versions of the app, including the most recent downloaded from TestFlight. But, whatever the version, any try to save using the panel (e.g. on the desktop) results in a warning telling that I don't have authorization to record the file to that folder. Moreover, when I type spctl -a -t exec -v /Applications/***.app in the terminal, it returns rejected, even when the application has been installed by TestFlight. An EtreCheck report tells that my app is not signed, while codesign -dv /Applications/***.app returns a valid signature. I'm lost... It suspect a Gate Keeper problem, but I cannot found any info on the web about how this system could be reset. I tried sudo spctl --reset-default, but it returns This operation is no longer supported... I wonder if these symptoms depend on how the app is archived and could be propagated to my final users, or just related to a corrupted install of Sequoia on my local machine. My feeling is that a signature problem should have been detected by the archive validation, but how could we be sure? Any idea would be greatly appreciated, thanks!

Hi, Updating a macOS application from Ventura to Sonoma, I encountered some issues, especially related to the new default value of -clipsToBounds (NO instead of YES previously), so that I had to add explicit definitions of this method in all my class views. All these problems are fixed now, except for one that I can't solve and that may or may not be related: The main window of this application has a toolbar containing a few custom views and using the NSWindowToolbarStyleExpanded style. In Sonoma, I can no longer move the window by clicking and dragging, even when I click on the title bar, and despite the fact that all my custom views inside this toolbar now have their -clipsToBounds method returning YES. -isMovable however returns YES, -isMovableyWindowBackground returns NO, and the window receives the events. But -mouseDown: is only called when the window can't be moved, which seems to mean that the event wasn't properly caught somewhere. Curiously, If I put the style to NSWindowToolbarStyleAutomatic, I can move the window again, but only by clicking on the left part (where is displayed the title and the following empty space). Does anybody encountered such an issue on Sonoma ? Or have an idea to fix or work around this issue ? Any help or advice is welcome, thank you!

My app encountered problems when trying to open an x86 audioUnit v2 on a Silicon Mac (although Rosetta is installed). There seems to be a XPC connection issue with the AUHostingService that I don't know how to fix. I observed other host apps opening the same plugins without problem, so there is probably something wrong or incompatible in my codes. I noticed that: The issue occurs whether or not the app is sandboxed. The issue does no longer occur when the app itself runs under Rosetta. There is no error reported by CoreAudio during allocation and initialization of the audio unit. The first notified errors appears when the unit calls AudioUnitRender from the rendering callback. With most x86 plugins, the error is on first call: kAudioUnitErr_RenderTimeout and on any subsequent call: kAudioComponentErr_InstanceInvalidated On the UI side, when the Cocoa View is loaded, it appears shortly, then disappears immediately leaving its superview empty. With another x86 plugin, the Cocoa View is loaded normally, but CoreAudio still emits kAudioUnitErr_NoConnection from AudioUnitRender, whether the view has been loaded or not, and the plugin produces no sound. I also find these messages in the console (printed in that order): CLIENT ERROR: RemoteAUv2ViewController does not override - and thus cannot react to catastrophic errors beyond logging them AUAudioUnit_XPC.mm:641 Crashed AU possible component description: aumu/Helm/Tyte My app uses the AUv2 API and I suspect that working with the AUv3 API would spare me these problems. However, considering how my audio system is built (audio units are wrapped into C++ classes and most connections between units are managed on the fly from the rendering callback), it would be a lot of work to convert, and I’m even not sure that all I do with the AUv2 API would be possible with the AUv3 API. I could possibly find an intermediate solution, but in the immediate future I'm looking for the simplest and fastest possible fix. If I cannot find better, I see two fallback options: In this part of the doc: “Beginning with macOS 11, the system loads audio units into a separate process that depends on the architecture or host preference”, does “host preference” means that it would be possible to disable the “out of process” behavior, for example from the app entitlements or info.plist? Otherwise, as a last resort, I could completely disable the use of x86 audioUnits when my app runs under ARM64, for at least making things cleaner. But the Audio Component API doesn’t give any info about the plugin architecture, how could I found it? Any tip or idea about this issue will be much appreciated. Thanks in advance!

Hi all, when I launch my macOS app from Xcode 16 on ARM64, appKit logs me this error on the debug console: It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future. _NSDetectedLayoutRecursion doesn't help a lot, giving me these assembly codes from a call to a subclassed window method that looks like this: -(void) setFrame:(NSRect)frameRect display:(BOOL)flag { if (!_frameLocked) [super setFrame:frameRect display:flag]; } I have no direct call to -layoutSubtreeIfNeeded from a -layout implementation in my codes. I have a few calls to this method from update methods, however even if I comment all of them, the error is still logged... Finally, apart from that log, I cannot observe any layout error when running the program. So I wonder if this error can be safely ignored? Thanks!

Hi, I have a recurrent problem with an Xcode workspace that I cannot figure out how to solve: When I command-click a symbol (or press ctrl-cmd-J) to find its definition, and when that definition is in a header file belonging to a custom static library, Xcode opens a header located in the derivedData folder rather than in the project's source codes. The exact location of this file is not in the main 'Build' folder but rather in a folder that seems dedicated to indexing: derivedData/myProject/Index.noIndex/Build/Products/Debug/Include/theHeader.h Consequently the file opened by Xcode is uneditable, I have to close it and reopen the source using another method. Even when the correct header is already opened, and I try again, Xcode reopens the wrong file so that it's opened twice with different paths. In the config file of the main application project, I reference the sources of these static libraries like this: HEADER_SEARCH_PATHS = ${SRCROOT}/myLibrary1/Sources ${SRCROOT}/myLibrary2/Sources ${SRCROOT}/myLibrary3/Sources However, removing this doesn't fix the issue and I don't see any other related-settings. Any idea to fix this annoying issue would be greatly appreciated, thanks!