I smell a blog post …
[quote=475025:@Norman Palardy]You can just add to the apps plist at build time by creating a text file named info.plist and then dragging it into the project
It lets you add key / value pairs to your build apps default plist[/quote]
Does it work if added to the application plist?
The usage described by @steipete is to set it to the defaults. Sadly it’s undocumented, so there’s no official word from Apple on this.
Now I’ll have to try that and see if a per app setting like this works as expected as it would be different from the user defaults
That just about sums development for Apple up in one sentence. >:(
So, if NSApplicationCrashOnExceptions is false, does the app continue limping on silently or does it crash with no report?
I don’t know; lemme check the documentation… Oh that’s right, it’s not documented.
I can’t tell you how happy I was when I read this tip. I had gotten to a point where I started to accept that 10.14 was just a fundamentally broken OS. I’d take me days to track down which API was breaking functionality, nothing was written to the log, so I just assumed that it’s broken.
Once I saw this tip and now use it all my apps, I started to test things that I thought were broken. Sure they’d changed in behavior, but with this, they’d crash. The crash log would then display the API that was causing the exception, and most importantly WHY!
I’ve pretty much been able to get everything working again.
This has to be one of the most ridiculous changes made to the macOS yet, even people I’d consider my peers have been struggling with apps suddenly going limp and no indication why. I can only assume it was done, to make it seem like newer OS version were more stable, because hey apps don’t crash any more.
A while ago I had found this lovely bug here: feedback://showreport?report_id=58879 (hard crash when making a date). At the customer it was hard to track down because the app didn’t crash on Catalina. The non-crash behaviour is really really clever. The bug isn’t even reviewed, yet. Sigh…
I wonder if this would work with kexts. I have a driver that is running two of my guys bonkers. The driver works in Big Sur IF the system was upgraded from 10.14 or 10.15. But, if it’s a clean install on a new 11.x system, the launch fails with no kernel or crash output.
It is worth a shot, just make sure that you set the default before you do anything else.
Have you tried the CrashReporterPrefs app that’s in the Xcode additional tools?
Doesn’t appear to work with kexts.
Not fully understanding how I fix it?
I’m not currently using NSUserDefaults because I didn’t think IOSKit worked on the latest Xojo
If you use the Ohanaware App Kit, this is set for you when you call
OAK2020.init( true ).
Otherwise if you use one of the other application kits, you should be able to translate the following line.
NSUserDefaultsSetBoolForKey( NSUserDefaultsStandard, true, "NSApplicationCrashOnExceptions" )
Ok so now the App crashes all the time with the following
Termination Signal: Illegal instruction: 4
Termination Reason: Namespace SIGNAL, Code 0x4
Terminating Process: exc handler 
Application Specific Information:
Crashing on exception: -[XOJCanvasView setImageFrameStyle:]: unrecognized selector sent to instance 0x7f94c3d4f860
Application Specific Backtrace 1:
0 CoreFoundation 0x00007fff38de2b57 __exceptionPreprocess + 250
1 libobjc.A.dylib 0x00007fff71c5e5bf objc_exception_throw + 48
2 CoreFoundation 0x00007fff38e61be7 -[NSObject(NSObject) __retain_OA] + 0
3 CoreFoundation 0x00007fff38d473bb forwarding + 1427
4 CoreFoundation 0x00007fff38d46d98 _CF_forwarding_prep_0 + 120
5 Cargo Australia.debug 0x000000010112f498 GameWnd.GameWnd.PlayerShip1_Open%%o<GameWnd.GameWnd>o + 360
6 Cargo Australia.debug 0x00000001011c00d4 Delegate.IM_Invoke%%o + 52
7 Cargo Australia.debug 0x00000001011c0124 AddHandler.Stub.2%% + 52
8 XojoFramework 0x0000000101944d3a FireWindowOpenEvents + 184
9 Cargo Australia.debug 0x0000000100ed4dcc Window.Constructor%%o + 60
10 Cargo Australia.debug 0x00000001011bfa8d GameWnd.GameWnd%o<GameWnd.GameWnd>% + 589
11 Cargo Australia.debug 0x0000000101396d6a _MakeDefaultView + 106
12 Cargo Australia.debug 0x0000000101396fcf _LateStartup + 79
13 XojoFramework 0x00000001017afd1d _Z29CocoaFinishApplicationStartupv + 185
And there you go. Somewhere in your code you’re trying to call setImageFrameStyle: on a Canvas and not an Imagewell.
Bingo I was just back stepping duplicated the project and stepped through with the changes until it happened again. I had several Imagewells that don’t really work in Windows for what I was doing and I simply went through and changed their supers to canvas and kept all the names the same but lurking in the open events of the image wells I was turning the frame off with a declare… Thanks Sam for the replies
Glad I could help. When I saw your post, I immediately thought it sounded like the macOS swallowing the exception rather than reporting it.
I’ve added a comment from Jeff Johnson where he mentions a scenario where NSApplicationCrashOnException will not fire.
My application plist has
and yet in macOS Big Sur, it’s not crashing during exceptions.
In this case, the exception happens during a DragItem.
There are 3 items on the pasteboard, but 1 drag images. There must be 1 draggingItem per pasteboardItem. com.apple.AppKit error AppKit General There are 3 items on the pasteboard, but 1 drag images. There must be 1 draggingItem per pasteboardItem. 0 CoreFoundation 0x00007fff2063783b __exceptionPreprocess + 242 1 libobjc.A.dylib 0x00007fff2036fd92 objc_exception_throw + 48 2 CoreFoundation 0x00007fff2063769f +[NSException raise:format:] + 189 3 AppKit 0x00007fff2310a460 -[NSDraggingSession(NSInternal) _initWithPasteboard:image:offset:source:] + 245 4 AppKit 0x00007fff23109e98 -[NSCoreDragManager dragImage:fromWindow:at:offset:event:pasteboard:source:slideBack:] + 1767 5 AppKit 0x00007fff231097a2 -[NSWindow(NSDrag) dragImage:at:offset:event:pasteboard:source:slideBack:] + 134 6 XojoFramework.dylib 0x000000010677a312 _Z16CocoaPerformDragP14DragItemObject + 2718 7 MyApp 0x00000001047f3474 DragItem.Drag%%o<DragItem> + 36
I’ve fixed this particular crash, but the fact that it silently fails was really hard to debug.
Does NSApplicationCrashOnExceptions no longer work? Or am I doing it wrong?
From what I’m reading, this isn’t a plist entry item but an NSUserDefaults entry.