macOS AMFI killing code signed process?

Just received an exception ticket related to a (App-Wrapper) code signed desktop app, in this case on an MacBook Pro equipped with a M1Pro chip running Monterey. From first crash log it looked like a declare into NSAlert would fail, which would be very strange. Deeper inspection revealed several lines like this:

kernel AMFI: constraint violation /Applications/myApp.app/Contents/Frameworks/XojoFramework.framework/Versions/A/XojoFramework has entitlements but is not a main binary\

all related to usual Xojo frameworks which I suspect to be the cause of the app not starting at all for this user.
Did someone run into this too? What could be causing such a system behaviour?

Which version of Xojo do you use? From where did the user launch the app?

Sigh… every new version of macOS brings new idiocy - ah, security.

1 Like

2022r4.1. And the question about the app location is one point on my questions to the user. Also to try that funny “amfi-get-out-of-my-way” command line command.
I hope they simply tried to start it from a wrong location. Otherwise the question still remains is “What makes their system react this way?”

And yes, fun times.

Now and then I get a broken signature on an app. Reinstallation usually helps. Has the user tried that?

They say the issue started a few beta builds ago, so yes.

So IIRC, “Technically” only bundles (excluding Frameworks) and unbundled commandline apps (helpers) should be signed with entitlements.

However, I don’t recall exactly why, but when adhering to this, some apps had trouble loading nested dylibs. Really rummaging my mind leads to believe it was either an early Harden Runtime or it was dylibs loaded via code (instead of being hard linked in the LC_commands)…

I can reproduce the same console messages with the latest Ventura and so I will investigate this, but it will probably have to be an option as I don’t want to release an update that may cause some apps to no longer work. I also didn’t make any notes in the code as to why or when I made this change :frowning:

Further more, while this message is present in the console, it doesn’t appear to prevent the application from launching or cause it any perceivable problems.

I did however have a crash on some Macs with the NSAlert, I’m trying to recall what it was.

I have found one of the NSAlert crashes, this was the part of the stack trace, does it match your customer’s crash report? Customers Machine is 12.6. I was never able to reproduce the crash locally. And other tests on the customers machine worked fine, it was just this error dialog, which included a Xojo stack trace. It’s part of my error reporting functionality.

if I get this again, I’ll remove the use the Xojo message dialog and go direct to NSAlert, just to rule out any possibility of it being a bug in the Xojo framework.

0   CoreFoundation                      0x00000001b5ee1148 __exceptionPreprocess + 240
1   libobjc.A.dylib                     0x00000001b5c2be04 objc_exception_throw + 60
2   CoreFoundation                      0x00000001b5ee0f94 +[NSException exceptionWithName:reason:userInfo:] + 0
3   AppKit                              0x00000001b9264cb0 _NSRunModal + 164
4   AppKit                              0x00000001b8d00f1c -[NSAlert runModal] + 272
5   XojoFramework                       0x000000010459ba14 _Z22CocoaShowMessageDialogP13MessageDialogP6Window + 1312
6   XojoFramework                       0x00000001046a8bbc MessageDialogShowModal + 24
7   Sleep Aid                           0x0000000102f2247c MessageDialog.ShowModal%o<MessageDialogButton>%o<MessageDialog> + 64

Thanks, Sam! Looks like the user somehow managed to trigger a deadly Apple watchdog. He installed a newer version in a different directory and both stopped to work.
And the NSAlert issue is exactly the opposite: I do use a custom declare into NSAlert already …

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   libsystem_platform.dylib      	       0x186b60864 _platform_strlen + 4
1   libsystem_c.dylib             	       0x186a0f6a0 __vfprintf + 4544
2   libsystem_c.dylib             	       0x186a3d8b4 _vasprintf + 280
3   HIToolbox                     	       0x18fa8ede0 HILogToClient + 44
4   HIToolbox                     	       0x18fa8f220 HIPrintBacktrace + 44
5   HIToolbox                     	       0x18f8cc430 MenuBarInstance::EnsureAutoShowObserver() + 120
6   HIToolbox                     	       0x18f8cbff0 MenuBarInstance::EnableAutoShow() + 60
7   HIToolbox                     	       0x18f86d770 SetMenuBarObscured + 372
8   HIToolbox                     	       0x18f86d348 HIApplication::HandleActivated(OpaqueEventRef*, unsigned char, OpaqueWindowPtr*, unsigned char) + 172
9   HIToolbox                     	       0x18f86740c HIApplication::EventObserver(unsigned int, OpaqueEventRef*, void*) + 296
10  HIToolbox                     	       0x18f82dee0 _NotifyEventLoopObservers + 176
11  HIToolbox                     	       0x18f866df8 AcquireEventFromQueue + 508
12  HIToolbox                     	       0x18f855ffc ReceiveNextEventCommon + 380
13  HIToolbox                     	       0x18f855e68 _BlockUntilNextEventMatchingListInModeWithFilter + 72
14  AppKit                        	       0x18977e51c _DPSNextEvent + 860
15  AppKit                        	       0x18977ce14 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1328
16  XojoFramework                 	       0x1056d4fc4 0x1055ec000 + 954308
17  AppKit                        	       0x189a304b4 -[NSApplication _doModalLoop:peek:] + 308
18  AppKit                        	       0x189a2efa4 __35-[NSApplication runModalForWindow:]_block_invoke_2 + 72
19  AppKit                        	       0x189a2ef40 __35-[NSApplication runModalForWindow:]_block_invoke + 108
20  AppKit                        	       0x189a2e6d4 _NSTryRunModal + 128
21  AppKit                        	       0x189a2e584 -[NSApplication runModalForWindow:] + 148
22  AppKit                        	       0x189b98998 __19-[NSAlert runModal]_block_invoke_2 + 160
23  AppKit                        	       0x189b988dc __19-[NSAlert runModal]_block_invoke + 108
24  AppKit                        	       0x189a2e6d4 _NSTryRunModal + 128
25  AppKit                        	       0x189ab8e98 -[NSAlert runModal] + 140
26  myapp         	       0x103c3b6a0 AppkitAddition.Alert.ShowModal%i8%o<AppkitAddition.Alert> + 168
27  myapp         	       0x103c35e00 AppkitAddition.NSAlert%i8%ssi4i8<AppkitAddition.AlertIcons>bsbsA1ss + 3288
28  myapp         	       0x103c40704 CSDesktopExtension.MessageBoxCS%i8%si8<NSColorAddition.MessageBoxButtons>i8<NSColorAddition.MessageBoxIcons>s + 2116
29  myapp         	       0x10323bca4 App.Event_Open%%o<App> + 2500
30  XojoFramework                 	       0x1056d46a4 CocoaFinishApplicationStartup() + 184
1 Like

You guys might want to try using beginSheetModalForWindow:completionHandler: Instead of runModal:

I’ve had no end of issues with the latter.

1 Like

Me, the idiot, did some testing for sending emails with an API. I wanted to use multiple emails. My test domain worked fine. But the iCloud email went into dev0 after a couple of tests. The email wasn’t even recognised as spam like Gmail does for legit emails. It just disappeared.

Thanks, Greg! Well, I did not have any issues yet with RunModal ;). It strikes me there are duplicate calls to block_invoke. Can that be correct?

It’s probably not. If you notice, it’s block_invoke + an offset.

But those are also down in the bowels of AppKit so there’s nothing much you could do about it.

Thanks Greg, I was using the Xojo framework to show the modal.

Apple Mail can’t find the original mails, Spotlight can, but only shows me the customers e-mail and not the entire conversation. IIRC this issue doesn’t occur on Ventura and only happened when (in my case) when displaying the Xojo stack trace. Other mesgbox worked fine.

If it still occurred in Ventura then I’d probably replace the messagedialog calls with direct declares, bypassing Xojo, just to rule out it being a Xojo bug.