App keeps running

Does anybody have some advice what I should be looking for with following symptoms:

  • The app keeps running when I close the last window from the window close button. The App.Close event trigger does not get activated. No window is visible anymore.
  • The app terminates correctly when I close it using the Exit entry in the main menu of the last window

Additional information:

  • Xojo 2024r1.1 on MX Linux 23.3 with Xfce
  • I am new to Linux, I have been developing this App on Windows, while others have taken care of the MacOS and Linux side of it
  • the app terminates correctly on Windows 8.1 (64-Bit), run with Xojo 2022r1.1 as a 32-Bit app
  • the app uses some features from API2 but most of it uses the original API. No Desktop… application, windows or controls are being used.
  • the window has a CancelClose event handler which returns False, and a Close event handler
  • the app has a no CancelClose event handler, but a Close event handler.
  • before the app hangs, the window’s CancelClose and Close events get triggered, but App.Close does not get triggered
  • App.WindowCount = 0 in MainWindow.Close
  • when I pause the application when it hangs, the debugger sais Eventloop in the Stack panel
  • I tried calling Quit from MainWindow.Close, both, with App.AutoQuit = True Or False, only to find out that this causes a real mess (the app segfaults)
  • I could not replicate the error with a test application, neither with Application / Window nor with DesktopApplication / DesktopWindow. With a DesktopApplication AllowAutoQuit = False even stops System.Log from working. I could not reproduce the hang nor the segfault. With Quit from MainWindow.Closing, App.Closing did not get triggered.
  • As I cannot install Xojo 2024r1.1 on Windows 8.1, I tried remote debugging from Linux on Windows. This did not work, as the app displays a message on the windows system: “Cannot connect to debugger ‘Since we could not locate the target IDE to start a debug session, this application will now exit.’” The firewall is opened for the remote debugger application on Windows, I did not find any requirements that need to be met on the Linux side.
  • I tried to isolate the culprit by commenting out stretches of code that still allow the app to start up. Doing so I found two stretches of code that both, individually seem to trigger the fault, i.e. if I skip both, the app terminates, if I leave in the one or the other, the app hangs. I could not make out anything remotely “dangerous” in either of them. I could not find something they have in common, apart maybe the fact that they create objects and use up some memory. But other stretches of code do this also, without triggering the fault. The second stretch of code registers the initial placement and size of controls to help in adjusting the layout after a resize operation or after a movement of a divider bar within the window. If I disable the first stretch of code, I am able to add 31 controls to the object created to handle the adjustments. When I add the 32nd, the hang re-appears. It has not to do with which controls are added, only with the number. (Note: when I wanted to verify this last claim, I could no longer get the app to close correctly even with the two stretches disabled entirely.)

Having said all that, it is pretty clear either the bug is in my code, but likely not in those stretches I identified, or the fault is in the platform (i.e. caused by Xojo).

I would not even bother to file an issue, without being able to provide a simple sample application (I could provide the real application, as it is open source anyway, but that likely would not help to get Xojo look at it).

How should I proceed from here?

On Mac it is normal that applications don’t quit when the last window is closed. I think the same sometimes applies to Windows and Linux. That said you can choose to make it quit when the last window is closed by setting:

app.AllowAutoQuit = True

I am aware of this. In Linux App.AutoClose defaults to True, But I set it to True explicitly anyway. Sorry I did not say so.
Somewhere in the details I mention AutoClose, and the DesktopApplication rename AllowAutoClose. This AutoClose is also the reason I mentioned App.WindowCount being 0.

Because I suspected problems with the App detecting this I tried to call Quit myself when the last window closes. But this caused more trouble.

How do you close an App on Mac without the AllowAutoClose feature? I looked for an event in App but found nothing I could use.

Are you setting App.AllowAutoQuit = True in the Open or Opening event of your app?

Otherwise it won’t do its thing. See: AllowAutoQuit

While what you say is true, there are a number of macOS apps that do quit when teh last window is closed, system apps even, because it makes sense to do so. Disk Utility is a good example; the one window lists all drives and volumes and the app and its user can’t do much unless it is displaying that list. This is a contrast to such as Word, where just beacuse I’ve closed a given window, doesn’t mean I’ve finished.

The Xojo IDE is in the same category as the likes of Word, and having it quit just because I closed a project window is very annoying, especially given the possible startup overhead of the IDE.

Are you opening and hiding windows, if so it could be the window is failing to close correctly. If WindowCount is zero I suppose it could be some sort of bug (either within the framework or your code) which is somehow hanging on to a reference to a window, without the debugger being able to see it.

Which is fine. it’s the difference between document based apps and more utility type ones.

My app has multiple windows but I am testing this issue just with the MainWindow.

Actually there is a splash window showing during startup before the main window opens. The Close trigger for this is running and the app quits normally if this splash window is shown and closes with the call to MainWindow.Show being commented.

If there is only ever one MainWindow, you could put the following into the the Window.Closing event:


I wrote about this. No! Quit cannot be called from Window.Closing:

  • It causes the CancelClosing trigger to be called again.
  • App.Closing will not be called.
  • The App may terminate with a segfault or some other crash.

all of this was mentioned above.

In which case what happens if you do away with your splashscreen? Only open the one MainWindow and then close it, does that work. If so then at least you know the direction to look, unless that is one of the code parts you’ve disabled already.

Ensure App.AllowAutoQuit (or the folder version) is the first thing called in App.Open, before any windows are opened, incase that matters?

I don’t suppose you have “Implicit Instance” turned on in the MainWindow. If so that could easily be the culprit. Just referring the window will make it open again. Click on the window, in the inspector click on the cog icon and you will see the option.

AutoQuit on Linux don’t work in a sample.

Make a sample, open a report, attach that sample, specify the details of the reproduction there.

If it’s a bug it needs fixing.

As I have said above: I cannot reproduce the fault in a test app.
I have taken the BevelButton example project, added some triggers and some System.Log calls.
I added

  AllowAutoQuit = True

  System.Log(System.LogLevelInformation, CurrentMethodeName)

  System.Log(System.LogLevelInformation, CurrentMethodeName)
  Return False

    System.Log(System.LogLevelInformation, CurrentMethodeName)

Everything works as it should except the System.Log call in App.Closing does not get recorded in the messages panel within the IDE. It does get recorded in syslog, though.

Thanks for that hint. It was actually set to Implicit Instance. Changing it did however not change the closing behavior.

Everything works as it should except the System.Log call in App.Closing does not get recorded in the messages panel within the IDE.

i remember there was a bug with app close event long ago.

Maybe you could put the crash report here so we can take a look? :man_shrugging:

It would be worth turning that off for all windows. It is rarely a good idea.

You could have an app.quitting property that you set when you call Quit(), and then check for that in CancelClosing. If it’s already True you just return.

I use this sort of mechanism because under some circumstances, when Quit() happens I need to run a thread to do some tidying up, and only when the tidying up is complete can the quit actually proceed.

So your app is retaining the application and should be uploaded in a private case for a Xojo inspection. Not sure if a bug in your part, or some valid combination of factors triggered a hidden bug in Xojo.

Where would I find a crash report, or how would I create one?

I guess this from the syslog will not help much:

mx kernel: [23251.703731] Debugopensong[23254]: segfault at fff0 ip 000000000000fff0 sp 00007fff61380ff8 error 14 in Debugopensong[200000+169000] likely on CPU 2 (core 0, socket 0)

nor this from the terminal:


which translated means “Memory access error”