I have a Xojo (it was RealBasic then) MacOS app I developed years ago, and it started failing some time ago. It crashes attempting to open a dialog box at startup for password entry. I recompile it and run it on the debugger and when I step into PasswordEnterDlog.ShowModal(), the app crashes with EXC_BAD_ACCESS (SIGSEGV). Sometimes, the dialog box pops on the screen before crash, sometimes not. Can anyone point me to a deprecation or something that might be causing this? Until this crash, I hadn’t needed to compilee this app for years.
Are you perhaps doing this from a thread?
That was “allowed” some years ago, although it shouldn’t have been.
Does the offending dialog has “Open” events? If yes, do they start to execute?
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.
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.
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?