Unhandled NSInternalInconsistencyException

Targets macOS
1

Does anyone have an idea what might cause below crash?

default 21:27:31.215975+1000 mDNSResponder [R690] DNSServiceQueryRecord(1D000, 0, <mask.hash: ‘M2skEvLy0MWYsqHfIUE3CA==’>, AAAA) STOP PID[904](Mail Archiver X)
default 21:27:33.145224+1000 Mail Archiver X The application quits now due to an unhandled NSInternalInconsistencyException.

NSWindow drag regions should only be invalidated on the Main Thread!
Please report to the application developer.
default 21:27:33.145358+1000 Mail Archiver X callStackSymbols: (
0 CoreFoundation 0x00007fff207f898b __exceptionPreprocess + 242
1 libobjc.A.dylib 0x00007fff20530d92 objc_exception_throw + 48
2 CoreFoundation 0x00007fff20821086 -[NSException raise] + 9
3 AppKit 0x00007fff22fa3872 -[NSWindow(NSWindow_Theme) _postWindowNeedsToResetDragMarginsUnlessPostingDisabled] + 321
4 AppKit 0x00007fff22f8e44a -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1296
5 AppKit 0x00007fff231504cf -[NSPanel _initContent:styleMask:backing:defer:contentView:] + 50
6 AppKit 0x00007fff22f8df33 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 42
7 AppKit 0x00007fff23150484 -[NSPanel initWithContentRect:styleMask:backing:defer:] + 64
8 AppKit 0x00007fff22f8c04a -[NSWindowTemplate nibInstantiate] + 393
9
default 21:27:33.151436+1000 Mail Archiver X Entering exit handler.
default 21:27:33.151472+1000 Mail Archiver X Exiting exit handler.
default 21:27:33.155940+1000 kernel AGC:: [Mail Archiver X pid 904 mux-aware] exiting, non-mux-aware app count 0, runtime: 0:02:11.794
default 21:27:33.232486+1000 mDNSResponder [R467] DNSServiceCreateConnection STOP PID[904](Mail Archiver X)
default 21:27:38.249654+1000 loginwindow -[PersistentAppsSupport saveLogoutPersistentState:finalSnapshot:] | previouslyRunningApps: (
{
BackgroundState = 2;
BundleID = “com.apple.console”;
Hide = 0;
Path = “/System/Applications/Utilities/Console.app”;
},
{
BackgroundState = 0;
BundleID = “com.apple.mail”;
Hide = 0;
Path = “/System/Applications/Mail.app”;
},
{
BackgroundState = 2;
BundleID = “com.mothsoftware.mailarchiverx”;
Hide = 0;
Path = “/Applications/Mail Archiver X/Mail Archiver X.app”;
},
{
BackgroundState = 2;
BundleID = “com.apple.finder”;
Hide = 0;
Path = “/System/Library/CoreServices/Finder.app”;
}
)

The user is archiving emails here with a sheet in front of the main window with some progress bars. The user already has done the needful and restarted.

Xojo 2020r2 on some version of 11.0 Intel.

2

That seems to be the explanation. The UI can’t be updated from a different thread.

3

The app has been available for years and years and this is the first crash of this sort. There is a sheet shown with show modal in front of the main window. There is no drag going on because the user can’t do anything.

I forgot to add that the crash occurs always when parsing the same specific email. Even dragging the complete window around would make the crash at different locations. But I’ll ask the user if he did something with the window.

4

I get that the application has not been recompiled.

Did you update macOS in any way ?

5

My guess would be that it is creating a window when the application exits, somehow the OS or the Xojo framework is updating parts of the window on a second thread.

6

But then I would need some sort of exception. And there is nothing. Just the hard crash.

7

Unless you “NSApplicationCrashOnExceptions” is set to true in the NSUserDefaults, at which point the application crashes (there are some where it still won’t).

Are you using the terminate trick to kill your application at the end of the exit routine?

8

Yes. When doing a scheduled archival I had some users where the app wouldn’t quit.

9

So when the app quits it does some stuff, which may be causing a window to appear during that process.

Are you returning True in CancelClose of the App, performing the tasks, then quitting?

10

There is no window when quitting. The app only closes a database when necessary.

Correction: there is a window when the app has an exception.

11

You do capture that exception to the same log as everything else (and before it tries to display the window) right?

I write them to disk ASAP in the same place crash reports are written.

12

Yes. There is nothing in the log. The exception also should be mirrored to the console log.