Please show the relevant section of the crash log.
The messagebox in a thread should do a ThreadSomethingUIException.
Here’s the crash log leading up to the SIGSEGV. Thanks for taking a look:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_platform.dylib 0x7ff81952d6b2 _platform_strlen + 18
1 libsystem_c.dylib 0x7ff8193e6e9a __vfprintf + 5000
2 libsystem_c.dylib 0x7ff819418a5c _vasprintf + 279
3 HIToolbox 0x7ff822464d8a HILogToClient + 150
4 HIToolbox 0x7ff822465248 HIPrintBacktrace + 36
5 HIToolbox 0x7ff8222d9594 MenuBarInstance::EnsureAutoShowObserver() + 102
6 HIToolbox 0x7ff8222d910c MenuBarInstance::EnableAutoShow() + 52
7 HIToolbox 0x7ff82227ce7e SetMenuBarObscured + 408
8 HIToolbox 0x7ff82227ca4a HIApplication::HandleActivated(OpaqueEventRef*, unsigned char, OpaqueWindowPtr*, unsigned char) + 164
9 HIToolbox 0x7ff822276f3a HIApplication::EventObserver(unsigned int, OpaqueEventRef*, void*) + 252
10 HIToolbox 0x7ff82223eef2 _NotifyEventLoopObservers + 153
11 HIToolbox 0x7ff82227699c AcquireEventFromQueue + 522
12 HIToolbox 0x7ff822265a69 ReceiveNextEventCommon + 625
13 HIToolbox 0x7ff8222657e5 _BlockUntilNextEventMatchingListInModeWithFilter + 70
14 AppKit 0x7ff81c00553d _DPSNextEvent + 927
15 AppKit 0x7ff81c003bfa -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1394
16 XojoFramework 0x108c28007 0x108b47000 + 921607
17 XojoFramework 0x108c27300 CocoaProcessOneEvent(signed char) + 250
18 XojoFramework 0x108daedd7 ModalEvents(unsigned char) + 58
19 XojoFramework 0x108dc2b8e RuntimeShowModalWithinWindow + 457
20 AssetRecords.debug 0x107963f34 Window.ShowModal%%o + 36
21 AssetRecords.debug 0x107c76a8b DatabaseWrap.Password.Get%s%oi4 + 2459 (/DatabaseWrap:538)
22 AssetRecords.debug 0x107c6b113 DatabaseWrap.Connect%b%oo + 5875 (/DatabaseWrap:230)
23 AssetRecords.debug 0x107b38287 App.Event_OpenDocument%%oo + 12503 (/App:99)
24 AssetRecords.debug 0x107993302 Application.OpenDocument%%oo + 50
25 AssetRecords.debug 0x107b3c975 App.Event_NewDocument%%o + 789 (/App:164)
The only executable code associated with the dialog is actions for “OK” and “Cancel” buttons. It was thread 0 that crashed; the app doesn’t operate threads explicitly. Thanks for taking a look.
The menubar doesn’t like the modal window. Try to set a timer in App.Open and then show the window with the timer.
Timer to give the menubar time to open? Say a 1-second delay? I will try that, but it will take me a while since I haven’t used Xojo for years and never used timers back then. By the way, how can I interpret line 19 in the log? The main window is not open until after the password allows decryption and connection of the database, so I use ShowModal() not ShowModalWithin(). Just curious. Thanks again. I’ll continue this thread if I can’t fix the app.
Perhaps instead of showmodal the window, you should simply set it as opening window in App.
1 Like
Seems like your routine could be something like Michel states. Your first window could be a splash window without toolbar and there a show modal of whatever could happen. Once satisfied your initialization needs, you could do something like:
main.show() // open the interface
self.Close() // close the splash
Thanks for looking at this. The ShowModal isn’t only used at startup - sorry I didn’t make that clear earlier. At any time, a file can be double-clicked, dropped on the app icon, etc. whether the app is running or not. If not running, the app starts up, authenticates, decrypts, and connects the database. If running, the app authenticates the new file, closes the current database then decrypts and connects the new database.The ShowModal worked well for this for over ten years for the authentication step. I can’t interpret the crash log, so I have no idea what the problem is with the menubar. Is this a common problem, or should I open a support case? As a shot in the dark, could this have anything to do with multiple desktops? I have tried to open the app on desktop A, seen the dialog pop up and disappear on desktop A, then found the crash log window on desktop B with no clue how the OS selected desktop B for the crash log.
Because the “it worked for 10+years but now it crashes” I vote for a Issue report.
1 Like
When you check “Break on exception” in the Project menu, where does the error occur ?
I have that checked, but in the debugger I put a breakpoint at the ShowModal and when I step in the ShowModal the crash happens.
What is the exception ?
Can you make a minimal sample of the case, like cutting off everything in your app and leaving just the window or whatever sequence it carries causing the crash, thus isolating the problem in a smaller haystack to look for the needle? Then attach such zipped sample to your report.
The exception is SIGSEGV. (segment violation; invalid address I think)
I will try this. I already submitted the report, but I can append a zip I think.
You may want to search for SIGSEGV in this forum. There are similar crashes occurring.
I searched as you suggested:
Apple Silicon: ShowModal crash by Mario van Ginnekin seems to be exactly the same crash log as mine.
I should like to link Mario’s issue and mine somehow. Is there a way to link?
1 Like
I have uploaded a snippet at the issue #68727
I was experiencing similar crash reports, and found this by searching for “SetMenuBarObscured” 
I’ve pinned it down to the precise thing that triggers the issue, and filed an Issue report (68800) with demo app and workarounds. It’s very strange…
The crash requires a VERY specific set of items to be true:
- A modal dialog (of any type, Sheet/Movable/etc.) must be shown.
- The Menu Bar must be hidden, either on Desktop (via optional setting in System Prefs > Dock & Menu Bar) or via Full Screen mode where the Menu is hidden by default.
- Crash occurs when switching apps while the modal dialog is visible.
If you are viewing Full Screen, the crash happens when switching away. If you have the Menu hidden on Desktop, the crash happens when switching back to the app. - And one last very important key ingredient…
…Simply calling a method in the dialog window that shows the modal dialog and returns a String! 
If the “show the dialog” method returns anything besides a String, it works perfectly fine—Variant, Text, Integer, Boolean, and Objects. Of course using no return type also works fine. Why in the world would just a String return type trigger a crash but nothing else? How does that logically tie into the Menu Bar being visible or not? 
An obvious workaround is as simple as switching the method’s return type to Variant or Text!
I’ve uploaded a demo app to my Issues report (68800) that clearly demonstrates the issue, and the workarounds:
Modal dialogs crash on macOS Monterey 12.x following this specific recipe