Custom macOS login Plugin crashes on Catalina ("not in immutable memory") - objective-c

I am using the Apple NameAndPassword Xcode example to customize the macOS login experience. My goal is authenticate a user against Active Directory. I am using the NameAndPassword example as a jumping board to understanding the macOS login process. I don't particularly need a custom UI, but from looking at several threads, the example can also work with PAM authentication.
I am running the NameAndPassword plugin which I built on Catalina. I am performing local code signing. When I log out, the loginwindow app should call the invoke method of my plugin and show a custom SFAuthorizationView, which does not appear. I see the following error in the system.log...
Jan 24 11:20:48 Kolyas-Mac SecurityAgentHelper[890]: objc[890]: CLASS: class 'EXAuthorizationPlugin' 0x104fb7d58 small method list 0x104fb1ec8 is not in immutable memory
Jan 24 11:20:48 Kolyas-Mac com.apple.xpc.launchd[1] (com.apple.security.agent.login.00000000-0000-0000-0000-0000000186E3[883]): Service exited due to SIGILL | sent by exc handler[883]
and see that the SecurityAgentHelper crashes with the following...
Application Specific Information:
dyld3 mode
CLASS: class 'EXAuthorizationPlugin' 0x104fb7d58 small method list 0x104fb1ec8 is not in immutable memory
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff6d368ad6 __abort_with_payload + 10
1 libsystem_kernel.dylib 0x00007fff6d36a3df abort_with_payload_wrapper_internal + 80
2 libsystem_kernel.dylib 0x00007fff6d36a38f abort_with_reason + 19
3 libobjc.A.dylib 0x00007fff6c070820 _objc_fatalv(unsigned long long, unsigned long long, char const*, __va_list_tag*) + 114
4 libobjc.A.dylib 0x00007fff6c0707ae _objc_fatal(char const*, ...) + 135
5 libobjc.A.dylib 0x00007fff6c063e13 realizeClassWithoutSwift(objc_class*, objc_class*) + 2184
6 libobjc.A.dylib 0x00007fff6c0636a0 realizeClassWithoutSwift(objc_class*, objc_class*) + 277
7 libobjc.A.dylib 0x00007fff6c0634bb realizeClassMaybeSwiftMaybeRelock(objc_class*, mutex_tt<false>&, bool) + 317
8 libobjc.A.dylib 0x00007fff6c062ff4 initializeAndMaybeRelock(objc_class*, objc_object*, mutex_tt<false>&, bool) + 104
9 libobjc.A.dylib 0x00007fff6c053d45 lookUpImpOrForward + 1072
10 libobjc.A.dylib 0x00007fff6c053399 _objc_msgSend_uncached + 73
11 com.apple.securityAgentPlugin.NameAndPassword 0x0000000104faee74 AuthorizationPluginCreate + 148 (main.m:66)
Any suggestions on how to resolve this error? Would this be a compiler issue? Maybe a directive for memory?
This is the offending code:
OSStatus AuthorizationPluginCreate(const AuthorizationCallbacks *callbacks,
AuthorizationPluginRef *outPlugin,
const AuthorizationPluginInterface **outPluginInterface)
{
os_log_with_type(OS_LOG_DEFAULT, OS_LOG_TYPE_DEBUG, "AuthorizationPluginCreate");
*outPlugin = [[EXAuthPlugin alloc] initWithCallbacks:callbacks pluginInterface:outPluginInterface];
return noErr;
}

I got the same error when porting my iPad app to Mac using Catalyst. My app needed access to AppKit specific methods, and I added a bundle plugin following this guide. The program worked fine on my MacBook Air M1 running Monterey, but crashed on my 2012 MacBook Pro running Catalina with the error:
CLASS: class 'AppKitBridge.AppKitBridge' 0x11668c388 small method list
0x116687508 is not in immutable memory
After I changed the bundle identifier in the plugin bundle from $(PRODUCT_BUNDLE_IDENTIFIER).AppKitBridge to $(PRODUCT_BUNDLE_IDENTIFIER), and set the plugins deployment target to 10.15, the problem went away.

Related

Tracking down a SIGSEGV…

So I've got this weird SIGSEGV happening at very few (less than 1%) of my users…
From the stack trace it looks like an over-release
Thread 0 Crashed:
0 libobjc.A.dylib 0x00007fff9a3f916f objc_release + 31
1 libobjc.A.dylib 0x00007fff9a3f7ac4 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 475
2 CoreFoundation 0x00007fff9cc5c102 _CFAutoreleasePoolPop + 49
3 Foundation 0x00007fff96992cb6 -[NSAutoreleasePool drain] + 152
4 AppKit 0x00007fff9138409b -[NSApplication run] + 892
5 AppKit 0x00007fff91306520 NSApplicationMain + 1175
6 RailModeller Pro 0x000000010b60578b main (main.m:30)
7 libdyld.dylib 0x00007fff9a36b5ad start + 0
..but no matter what I try,
even with the very same data,
following the exact same steps as the users,
same OS/patch level,
using Address Sanitizer (Xcode 7.3),
using Zombies instrument,
using Guard Malloc
all appears to be fine.
The function crashing is a pretty common one in the app and I'd be drowning in bug reports (both from the automated bug reporting system as well as users getting in touch) if this were a more common issue.
However, to these (<1%) users the app appears effectively unusable.
Any hints on how to track down this issue much appreciated!

where to look for a bug. document, app delegate or both?

following situation: i have a document based App. by default when i open the app it displays just the menu on top of the screen. then i hit file->new and it opens up a brand new document.xib interface. working fine on my main pc. but on my secodnary pc running 10.6.8 the app crashes as soon as i run it. (code is compiled with the proper target...)
this application is crashing BEFORE i even see the main menu at the top. could the cause of the crash still be inside the document's xib file? or will it most likely be in the code that is outside the document part? what i mean is: is the code checked completely at the application lounch or does it onyl cause a crash when it reaches the code that is causing it?
thanks
edit
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 ??? 000000000000000000 0 + 0
1 com.apple.AppKit 0x0000000100def22e -[NSCustomObject nibInstantiate] + 416
2 com.apple.AppKit 0x0000000100def01b -[NSIBObjectData instantiateObject:] + 259
3 com.apple.AppKit 0x0000000100dee406 -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] + 336
4 com.apple.AppKit 0x0000000100deca91 loadNib + 226
5 com.apple.AppKit 0x0000000100debfa1 +[NSBundle(NSNibLoading)_loadNibFile:nameTable:withZone:ownerBundle:] + 248
6 com.apple.AppKit 0x0000000100debdd9 +[NSBundle(NSNibLoading) loadNibNamed:owner:] + 326
7 com.apple.AppKit 0x0000000100de935b NSApplicationMain + 279
8 mad-sharky.com.Stockuploader 0x0000000100001194 0x100000000 + 4500
The problem lies not in the XIB file, but rather in one of the objects in said file that is being instantiated incorrectly. Something about the object is causing it's -initWithCoder: method to fail. It appears you're probably not calling through to super in said method, and are simply returning self, which is not allowed.
The other possibility is that you have a "ghost outlet". Sometimes, when an IBOutlet is created and linked, then the piece of code that declares it is removed, IB doesn't de-link the outlet, and NSCoder tries to dearchive a nil outlet.
found the problem. here it is:
now it works without any problems!

CorePlot MonoMac bindings crashing

I am trying to use the CorePlot 0.9 binding for monomac, but that seems to be a hard task. The monotouch sample builds and runs without any problems, but I don't need that one.
Since only a CorePlotiOS.dll was present in the binding, I had to build one for osx myself, but first of af all, no bmake.exe was present, so I had to download the monomac source and build it myself first. Then I tried to build the CorePlotOSX.dll but that caused some compilation problems. Looking at the build-script for mono touch I tried with this line instead:
MONO_PATH=$(MONOMAC)/src mono $(MONOMAC)/src/bmac.exe -e -unsafe coreplot.cs -s=enums.cs -x=extras.cs -x=AssemblyInfo.cs --sourceonly=list --tmpdir=osx -r:System.Drawing -r:MonoMac -lib:$(MONOMAC)/src -baselib:$(MONOMAC)/src/MonoMac.dll .
Anything wrong there?
I have reduced the problem to this:
graph = new CPTPieChart();
graph.Title = "Test";
The allocation seems to survive, but whenever I try to access the object, I crash:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000bf887fac
VM Regions Near 0xbf887fac:
Stack 00000000b038d000-00000000b040e000 [ 516K] rw-/rwx SM=COW
--> Stack 00000000bc088000-00000000bf888000 [ 56.0M] ---/rwx SM=NUL
Stack 00000000bf888000-00000000c0088000 [ 8192K] rw-/rwx SM=COW
Application Specific Information:
objc[17645]: garbage collection is OFF
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x97c8aebc __CFStringEncodeByteStream + 12
1 com.apple.Foundation 0x9ac8ed49 -[NSString(NSStringOtherEncodings) getBytes:maxLength:usedLength:encoding:options:range:remainingRange:] + 263
2 com.apple.Foundation 0x9ac8e8ee bytesInEncoding + 213
3 com.apple.Foundation 0x9ac8e814 -[NSString(NSStringOtherEncodings) UTF8String] + 42
4 com.apple.CoreFoundation 0x97ce478c -[__NSCFString UTF8String] + 204
5 ??? 0x00f91208 0 + 16323080
6 ??? 0x030d708c 0 + 51212428
7 ??? 0x030d703c 0 + 51212348
8 ??? 0x016877d4 0 + 23623636
Any ideas? Running Mac OSX 10.7.5 btw.
Ok, that was hard. After several days of fighting xcode and monomac, it turned out, that the native CorePlot framework (dynamic lib) was not loaded. I was not aware, that I was supposed to load it myself (I am a monomac newbie, sorry...but isn't it rather ugly it fails silently in that way??)
Two ways to do this: either
Dlfcn.dlopen ("CorePlot.framework/CorePlot", 2); // 2 = load now, 0 = lazy load
or [assembly:MonoMac.RequiredFramework("CorePlot.framework/CorePlot")]

NSEvent charactersIgnoringModifiers randomly throws "TSMProcessRawKeyCode failed" exception

Our Mac cocos2d app (http://deepworldgame.com) has been randomly throwing "TSMProcessRawKeyCode failed" exceptions for some time now, and I'm wondering if anyone has experienced this error or knows how to prevent it.
It always happens via the [NSEvent charactersIgnoringModifiers] call within ccKeysDown or ccKeysUp (it also happens for [NSEvent characters] without the modifiers). I don't think it's related to specific keys. Sometimes it only happens one time and the app continues to function afterward (if the exception is caught), but other times it essentially locks up keyboard input indefinitely and continues to cause exceptions with all future keypresses (again, when these exceptions are caught).
I've found little on the internets regarding this issue, unfortunately. One place I did find was in the Adium source code (https://bitbucket.org/adium/adium/src/6d1f9b903525/Source/AIExceptionController.m), which catches this exception with the comments:
//Ignore various known harmless or unavoidable exceptions (From the system or system hacks)
...
// [TSMProcessRawKeyCode] May be raised by -[NSEvent charactersIgnoringModifiers]
It is indeed harmless when thrown once, but when the occasion happens that it continuously fires, it's a real problem - especially when you're in fullscreen mode and can't use cmd-F to escape!
So, if anyone has any thoughts or experience, I would be HIGHLY grateful. This is pretty much the one remaining superbug in our application, and I would love to squash it into dust.
Thanks!
Here is the typical stack trace (MacManager.m is our object which implements the cocos2d keyboard delegate protocol):
Crashed Thread: 7 CVDisplayLink
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Application Specific Information:
objc[28871]: garbage collection is OFF
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'TSMProcessRawKeyCode failed (-192)'
*** Call stack at first throw:
(
0 CoreFoundation 0x95b27d87 __raiseError + 231
1 libobjc.A.dylib 0x9315a149 objc_exception_throw + 155
2 CoreFoundation 0x95a8f619 +[NSException raise:format:arguments:] + 137
3 CoreFoundation 0x95a8f589 +[NSException raise:format:] + 57
4 AppKit 0x9ac01c1f _convertEventRefToString + 300
5 AppKit 0x9ab23b5e -[NSEvent charactersIgnoringModifiers] + 880
6 Deepworld 0x0001fd8a -[MacManager ccKeyDown:] + 65
7 CoreFoundation 0x95a7d091 -[NSObject performSelector:withObject:] + 65
8 Deepworld 0x0006bc95 -[CCEventDispatcher keyDown:] + 80
9 CoreFoundation 0x95a7d091 -[NSObject performSelector:withObject:] + 65
10 Deepworld 0x0006c014 -[CCEventDispatcher dispatchQueuedEvents] + 143
11 Deepworld 0x0006a9a4 -[CCDirectorDisplayLink getFrameForTime:] + 155
12 Deepworld 0x0006aaf1 MyDisplayLinkCallback + 40
13 CoreVideo 0x9b44a5e1 _ZN13CVDisplayLink9performIOEP11CVTimeStamp + 489
14 CoreVideo 0x9b4494e4 _ZN13CVDisplayLink11runIOThreadEv + 876
15 CoreVideo 0x9b449161 _ZL13startIOThreadPv + 160
16 libsystem_c.dylib 0x968a4ed9 _pthread_start + 335
17 libsystem_c.dylib 0x968a86de thread_start + 34
)
I don't think sending events in general is thread-safe, not to mention from a thread that has been created not within +[NSThread detachNewThreadSelector:toTarget:withObject:] (a thread created using the Objective-C run-time has __NSThread__main__ in the backtrace).
I guess your app is the Deepworld binary part - when dispatching events, try using -[NSObject performSelectorOnMainThread:waitUntilDone:] instead, dispatching the events on the main thread.

Aperture Plug-in crashes with EXC_BAD_ACCESS

I try to run the SampleFTPExportPlugIn that comes with the Aperture SDK 2.1. I had to tweak the Base SDK setting and manually copy the PluginManager.Framework folder to /Library/Frameworks, as described here.
All compiles and Aperture 3.2.3 now offers the menu item File/Export/FTP.
When selecting the "FTP" export method and thus triggering the plug-in code, Aperture crashes with a EXC_BAD_ACCESS. The illegal memory access happens in the initWithAPIManager method of class SampleFTPExportPlugIn when trying to get a reference to the ApertureExportManager:
_exportManager = [[_apiManager apiForProtocol:#protocol(ApertureExportManager)] retain];
This is the second line that gets executed after Aperture hands over control to the plug-in and seems to be the standard way of getting a reference to the ApertureExportManager in any Aperture plug-in (I haven't found any alternative ways of achieving the same anywhere).
Here the stacktrace:
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: 0x000000000000000d, 0x0000000000000000
VM Regions Near 0:
-->
__TEXT 0000000100000000-0000000100798000 [ 7776K] r-x/rwx SM=COW /Applications/Aperture.app/Contents/MacOS/Aperture
Application Specific Information:
objc_msgSend() selector name: class
objc[3000]: garbage collection is OFF
Performing #selector(a_exportPlugIn:) from sender NSMenuItem 0x111d2a540
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff8711c090 objc_msgSend_vtable2 + 16
1 com.apple.CoreFoundation 0x00007fff8381e25f -[__NSCFString isEqualToString:] + 63
2 com.apple.PluginManager 0x0000000101211218 -[PROBundleHandler apiForProtocol:] + 109
3 com.apple.CoreFoundation 0x00007fff83852f4c __invoking___ + 140
4 com.apple.CoreFoundation 0x00007fff83852de4 -[NSInvocation invoke] + 132
5 com.apple.CoreFoundation 0x00007fff83852fb4 -[NSInvocation invokeWithTarget:] + 52
6 com.apple.CoreFoundation 0x00007fff8384dff4 ___forwarding___ + 756
7 com.apple.CoreFoundation 0x00007fff8384dc88 _CF_forwarding_prep_0 + 232
8 com.apple.SampleFTPExportPlugIn 0x000000012c0d5361 -[SampleFTPExportPlugIn initWithAPIManager:] + 209
9 com.apple.PluginManager 0x000000010120c6fa -[PROConcretePlugIn plugInInstance] + 212
I read all about Objective-C memory management but cannot make sense of it. All the other examples I found on the web are implemented just like that so I guess I have a compatibility problem, something missing in my Aperture / Library installation. How can I narrow down the problem?
EDIT:
The problem seems to be with the passed in apiManager. The method signature is:
- (id)initWithAPIManager:(id<PROAPIAccessing>)apiManager
The parameter is then assigned to our internal reference:
_apiManager = apiManager;
However the actual class passed in is PROPlugInFirewall, as this output reviels:
NSLog(#"_apiManager class is: %#", [[_apiManager class] description]);
Then calling the respondsToSelector leads to the same crash although this method is inherited from NSObject.
if ( [_apiManager respondsToSelector:#selector(apiForProtocol:)] ) {
NSLog(#"responds");
}
The _apiManager itself describes itself as:
_apiManager is: <[*<PROBundleHandler: 0x14d79130> (PROAPIAccessing)*]>
Still stuck...
EDIT:
So it looks like Aperture is passing in a pointer that points to nirvana... However, I just installed another plugin, from the Apple webpage, with installer and everything. That one failed too when invoked...
Download FXPlug 1.2.5 SDK
Open the contents of the installer package
Copy PluginManager.framework to /Library/Frameworks
Your plugin should work now!
The newer versions of PluginManager.framework in FXPlug SDK(2.2/2.4) will cause this crash.
Tested on 10.8 with Xcode 4.5
I found that Justin's answer above didn't work for me when needing to build for Aperture 3.4, as it requires x86_64 architecture which the FXPlug 1.x versions don't support.
After trying various versions of the PluginManager framework, I found that the version available here doesn't cause the above crash and also contains the valid 64-bit architecture. Just replace the contents of /Library/Frameworks/PluginManager.framework/Versions/B with the contents of the linked archive and you're good to go.