When the error is printed (at launch time) the method simply called super. Moreover, if I disable the specialized methods, the error is still there. But the interesting point is that the breakpoint then gives me this backtrace: 0 _NSDetectedLayoutRecursion 53 NSApplicationMain 54 main It seems to indicate that the error is not related to my codes, at least directly. I suppose it could also be related to some conflicted constraints in my XIB files but, in that case, don't you think the error should have been detected by Interface Builder? Moreover, how could it be related to a layout recursion otherwise than from my codes? On the other hand, I tested the app and it works without problem on macOS 26, so I don't think I will waste more time on this issue for now. But anyway, thanks for your help!

Thanks for your answer. Yes I'm subclassing NSWindow: the method -setFrame:display: reproduced above is one of the NSWindow methods specialized by this subclass. But, apart of that, the subclass doesn't interfere with the layout system in no way. You're right about new macOS versions, I definitely intend to test macOS 26 before publishing a new version of the app (I'm developing on Xcode16 because my deployment target is macOS 10.13).

Obviously, my first option is meaningless: the plugin cannot run under Rosetta in the main process if the main process itself is not running under Rosetta... Therefore, my only fallback solution is to find the plugin architecture, warn the user when he tries to open a plugin requiring Rosetta, suggesting him to update the plugin or, as a last resort, to run the app under Rosetta. Finally, it's worth noting that auval itself fails to validate any of these Intel plugins. This seems to confirm that the AUv2 API is no longer supported on Silicon Mac. But it would be very helpful to have an expert opinion on this point.

Related to my last question, I forgot the key: kAudioUnitConfigurationInfo_AvailableArchitectures that is present in the audio component's ConfigurationInfo dictionary. I'm not 100% sure, but it seems that the plugins built with a Universal architecture fill this array with [x86_64, arm64] while the x86 plugins leave it empty. If confirmed, it could be a way to infer that they run under Rosetta.

Thanks, it's interesting to know a little bit more about EtreCheck. You're certainly right about the percentage of people using old systems. However in my sector of activity is something relatively current to keep an outdated system to ensure maximum compatibility with a collection of (expensive) plugins. It's why this app, which is distributed on the App Store, is compatible with macOS 10.11 and later, and also why I was developing on Catalina, and now on Monterey and Xcode13 (the last systems supporting this deployment target). I admit that this almost archeology now :-), I probably will change that soon. Note that it's perfectly possible to upload to the App Store from Monterey, or even Catalina. On the other hand, Test Flight runs only on recent systems, but on the server side it's as the App Store. You probably seen that I finally found and fix a stupid permission error: there were too many changes at the same time in my setup and that makes me confusing. Anyway, thanks for your help!

I just found the solution: that was a simple error of permissions consecutive to a change of the account name. I would have removed my post if it would be possible... Sorry for the noise!

No doubt that working with a child process would be the best option. However, it would also be a little bit dangerous for me to use such a technique as I'm not at all familiar with it. Moreover I'm afraid that it could lead to some complex issues with the sandbox which could require a lot of time to solve. But I keep this interesting suggestion in mind for a future update (I've seen a nice example you wrote in Swift and Objective-C, it could be a good starting point). For now, I will go with snapshots and lock free structures which are more familiar to me, and I will install my signal handlers with sigaction instead of dispatch_sources. Thanks for the great help!

Thanks for the reply! You're right, I probably underestimate the difficulty. However I've already read your interesting post about implementing a custom crash report, and many other related articles on the web. From a previous discussion with you, I finally decided to implement a minimal handling of signals and C++ exceptions and to postpone the dialog I was displaying - to inform the user that we're aware of the problem and try to fix it - to the next startup (if any...). My attempt here is not to test the real instable context of miscellaneous crashes, but to test the mechanism of saving some files on disk while crashing and react to the existence of these files during the next launch. These kind of things is difficult to test, but I recently found that it is possible with UI test thanks to its proxy mechanism. I'm aware of the strong limitations: to write on disk, I only use open, write and other allowed C functions. The first file saved is just an empty file to mark the session as crashed. Then data written on disk is not a crash report but a short description of the application context at crash time to help understanding what happened. This context is not captured within the handler but before, during the normal usage of the app. This way, the writing is only done with dates, numbers and strings already stored so that no memory is allocated. Naturally, this is not perfect, but be sure that I really try to do my best and listen your recommandations very seriously. Finally, about dispatch_source: should I understand that to support SIGABRT and the other signals you mentioned, I should implement a second handler using signal or sigaction? I mean, not only for tests but even for production codes?

Many thanks to the very helpful link! Even if I don't try to implement my own crash reporter, this post contains a lot of useful info. After reading, it seems to me that there is no real benefit in this case to catch signals, or even C++ exceptions. Either to save the application state or to display an alert, I need Objective-C and there is nothing I can do with just C or C++ codes, except printing something in the console. But it wouldn't be helpful here since I'm not in touch with the users whose I receive crash reports via the Xcode Organizer. What you tell about NSException is surprising to me: from my experience, saving a 'recoverable' session and displaying an alert during an exception handling works correctly. The fact that the file could be corrupted in some cases is handled during loading anyway so, theoretically, it cannot lead to a second crash (the file is just discarded if it's corrupted) . To terminate the process after the handler, I don't call exit, but I uninstall my handlers and then raise the exception again (or create one for a signal). Probably not the most elegant way, but I remember doing so because the application didn't quit otherwise (I should try again just returning as you recommend). Finally, it would be nice to know what's going on with Core Audio. I see only two possible scenarios: 1) Core Audio is available but the report lacks some lines in the binary image section 2) Core Audio is unavailable for some reason I cannot imagine... Knowing that could be useful to continue investigating.

Here is a crash report I just try to join to a post two days ago encountering the same error: 2024-03-25_13-04-40.6314.crash

Thanks for your help. I really don't understand what happened with the uploaded report. Many lines are missing from the main thread, but the version I have here is complete. I probably made a mistake somewhere, sorry for that. I join the file again. universalExceptionHandler is a C function I call in my app delegate to catch errors from both Signals and NSExceptions. From there, I try to save a recovered file and open a NSAlert. When required, I use a dispatch block to open the alert in the main thread. But in practice, the alert seems only useful for exceptions while it fails with signals (at least some of them, I'm not sure about that...). About C++, something is weird: all C++ codes used by this software are related to audio units and make an extensive use of Core Audio. However, I don't see any reference to Core Audio in the binary image. I cannot figure out how it is possible... Could it mean that something went wrong during the launch of the application? Or that Core Audio was crashed for some reason?

I wasn't able to post my answer because of the 'This post contains sensitive language. Please revise it in order to continue.' error... What can I do?

I was able to reproduce the issue in a small test project: It seems to be that some of my custom views return NO from -mouseDownCanMoveWindow to ensure that clicking-dragging them doesn't move the window. But, for some reason, the system applies that request to the full toolbar. This is weird, but fortunately less difficult to work around: as some sub-views of these views are sub-classes of NSControl, they already prevent moving the window, so that the undesired effect remains limited to small areas.

Thanks for the tip, that was very helpful! So here are the results of my last tests: I was able to reproduce that bug with several other plugins from different manufacturers which have in common to be authorized with iLok. I don’t describe the symptoms here since they are exactly the same as in my previous post, but they affect dozens of plugins, all from the list of manufacturers coming from this beta-testing session (but it probably exist other cases). I was also able to reproduce the bug with the VST or VST3 versions of the same plugins by opening them in an application hosting VST plugins loaded on the App Store (n-Track). More surprisingly, I got many similar errors when opening Audacity, which is not a sandboxed application: each of these plugins triggered the same error message during validation. However, after quitting and relaunching the app, the plugins were finally available and worked normally. In addition, the Logic Pro question revealed that version 10.7.9 was not sandboxed. Here's what the codesign command returns: Executable=/Applications/Logic Pro X.app/Contents/MacOS/Logic Pro X This command was executed on the Monterrey laptop, but I also loaded the last demo version on Ventura, and the version number is exactly the same. So, apparently, the most recent version of Logic Pro is still not sandboxed (which is confirmed by the fact that there is no container with its name in the user's library). I would have deduced from all this that sandboxing was ultimately not a viable choice for a professional music or audio application, but I also found an iLok-protected plugin that maybe contradicts this idea: My beta tester had pointed out that the GRM Tools plugins (from INA in Paris) didn’t crashed like the others, despite their iLok protection. I investigated this and, indeed, these plugins work perfectly in a sandboxed application on Ventura. The difference seems in the way they are authorized: whereas all other plugins open an iLok window during the validation process, and crash when they are instantiated, the GRM plugins require the customer to explicitly enter a validation code into the iLok manager after installing the plugin bundle and, after this step, there is no further (visible) interaction with iLok during validation or instantiation, and everything works as expected. This finally suggests that manufacturers would have a solution for implementing Pace iLok in a way that is supported by a sandboxed application. But, on the other hand, there are so few sandboxed music apps that they’re probably not aware of this problem. We can therefore fear that this situation will never be resolved, especially if the Logic Pro team doesn’t move in the direction of sandboxing. I fully understand why they don’t, but it would be a great motivation (perhaps the only one) for manufacturers to fix their implementation of iLok... Anyway, I now have many more info to think about the question of an alternative or additional distribution. Thanks a lot for your help!

I was finally able to reproduce the issue relatively quickly on Ventura. Here is a report of my tests (sorry for the length of this post): Installed Plugin with iLok protection : IRCAM-Trax from Flux Audio (demo version). OS: macOS 13.2.1, Hardware: iMac Retina 4K, 21.5-inch, 2019, 3,2 GHz Intel Core i7 6 cores Sandbox options: Outgoing Connection • Audio Input • User Selected Files: Read-write • Download, Music and Movies folders: Read-write Test 1: (DEBUG Scheme) SANDBOX, HARDENED RUNTIME (Disable Library Validation) => Failed: Exact same behavior as in macOS 12 (except that the error message is presented fourth instead of twice). The logs provided by the console wasn't very helpful, they don't seem related to the plugin crash. Test 2: (DEBUG Scheme) SANDBOX, HARDENED RUNTIME (Disable Library Validation • Disable Memory Protection • Allow DYLD Environnement Variables • Allow Unsigned Executable Memory • Allo Execution of JIT-compiled Code) => Failed: Exactly as the previous. Test 3: (DEBUG Scheme) => Failed: After deactivating the sandbox and Hardened Runtime, no plugin wants to open although all plugins have been validated again (since the Application Support folder where the referenced plugins are stored has been changed). I realized that the Hardened Runtime's ‘Disable Library Validation’ key is required to open any Audio Unit plugin, even in a non-sandboxed application (probably except those from Apple ? I didn’t test it). Test 4: (DEBUG Scheme) HARDENED RUNTIME (Disable Library Validation) => Failed: Here the iLok manager finally complained about the fact that it detected a debugger when I tried to open Trax… impressive. Test 5: (RELEASE Scheme) HARDENED RUNTIME (Disable Library Validation) => Crashed: Strangely, with the release scheme, the application crashed when I tried to open Trax, I join the report below: Anonymous-08:09:2023.crash Test 6: (RELEASE Scheme) HARDENED RUNTIME (Disable Library Validation • Disable Memory Protection ) => Success: Trax did open and all work as expected! I was happy to finally find a solution, but the bad news is that this solution involves not using a Sandbox, which is not an option for me since I would like to distribute on the AppStore. I still wondered how Logic and Garage Band do to work around this issue, so I tested again with Garage Band (on Monterey, the test was done with a licensed version of Logic Pro 10.7, which I think is sandboxed, and it had worked normally). But, finally, Garage Band 10.4.8 behave exactly the same way than my application: First this message this message was displayed 4 times when I tried to open Trax: Then, the error 100001 (reproduced in a previous post) was displayed. Next, this more informative message was displayed: Finally, you can see the content of the Garage Band’s temporary folder on this last screenshot: each error produces a file with another name and don’t overwrite the previous one. I hope this folder is cleared regularly because, depending on the size of the bundle, and how many times the user gets this error, this could consume some hard drive space unnecessarily... So, it finally appears that there is a real conflict, at least from macOS 12, but it could earlier, between some plugins authorized via iLok and the OS (with the collection of my beta-tester, it was something like 75% of the iLok protected-plugins). The only remaining doubt is about the try we made with success on Logic Pro 10.7.9 and Monterey (but I have no prove that this version is sandboxed, the simplest explanation would be that it’s not...). Do you think there is something else I can do to find a solution ? It seems that these problems are far removed from my application and that I don't have much control over them. Thanks!