Hi Quinn, thanks for the reply, that's very interesting. Practically, I have to type the name of each library generating my logs: typing the Process name doesn't seem to log anything (although the system proposes it to me). On the other side, if I type the PID, then I get all system logs again. Even for the app's main module, I have to enter a Library name of this form: myApp.debug.dylib. But apart of that, it works very well: I can event retrieve my printf statements by adding stdio in the filter. The only issue is that such a composite filter is a little bit tricky to enter. I thought that it was possible to reuse it through the "Recents" section of the filter menu. But, after giving a try, it appears that this section is cleared on each Xcode launch... that's too bad. It would be very useful to have a way to store frequent filters some way, or maybe to active one from the Scheme (e.g. as it can be done for the OS_ACTIVITY_MODE). Anyway, your post was very helpful, thanks again!

No, I don't use NSStatusBarButton in my codes, sorry. More generally, since I run Xcode on macOS 15, the number of such messages has become incredibly high... many of those logs have clearly nothing to do with what is under my control (the worse being when using UBSan and friends). This ultimately lead me to the deactivation of all logs (os_activity_mode=disable), but after that I couldn't even see some of my own logs anymore... I finally started using printf as a work around, but if someone knows a good solution to disable all system logs while keeping my own, I'm interested, thanks!

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.