Crash on Window.Close in 64 bit with AutoQuit=true

I have a by-now pretty well reproducible crash when closing a windows with ContainerControls.

I had seen this in my Arbed app for a while now, and now see this also in my Excel comparison app.

Apps are built with 2019r1.1. Whereas Arbed used a lot of declares, making it unclear whether this was the cause of it, I was able to remove all declares from my new app, and it still crashes. I have also gotten rid of all MBS plugin uses, and it’s still happening. So, it’s now pure Xojo code.

It crashes often in 64 bit builds but never in 32 bit.
It seems to crash only when App.AutoQuit is true.

It crashes not every time, it might to be some kind of race condition.

Here’s a stack trace of the crash:

[quote]Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000010008

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

VM Regions Near 0x10008:
__TEXT 000000010aec3000-000000010b24f000 [ 3632K] r-x/rwx SM=COW & [/Development/REALbasic/Projects/ExcelCompare/Excel Diff.debug]

Application Specific Information:
Performing @selector(menuItemAction:) from sender NSMenuItem 0x6000002a1680

Thread 0 Crashed:: Dispatch queue:
0 XojoFramework 0x000000010b632de1 RuntimeObjectIsa + 76
1 XojoFramework 0x000000010b644f64 RuntimeViewDestructor + 91
2 Excel Diff.debug 0x000000010aeeb5fb Window.__Exit%%o + 11
3 XojoFramework 0x000000010b632c63 RuntimeUnlockObject + 815
4 Excel Diff.debug 0x000000010b1f4c64 DiffWin.DiffWin._FileClose_Action%b%o<DiffWin.DiffWin> + 228 (/DiffWin:184)[/quote]

I will make more tests tomorrow, with older and newer Xojo versions.

Sorry man, there’s nothing I can see here which I may be able to help with (some crashes I can help).

OH - do you have a Popup menu on the window? I seem to recall there’s something about that causing crashes on close.

Nope, no PopupMenu (neither in Arbed).

It seems I could work around the crash in my new app by not using AutoQuit and using a Timer with Period 0 to quit the app after the Close event has finished.

However, the same work-around does not help in Arbed :frowning:

For the record, here’s how the stack looks in Arbed. It’s slightly different: The crash happens during the cleanup of a control, not of the window.

[quote]Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fdf00000020

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [0]

VM Regions Near 0x7fdf00000020:
Stack 0000700007e04000-0000700007e86000 [ 520K] rw-/rwx SM=COW thread 12
MALLOC_TINY 00007fdf48400000-00007fdf48800000 [ 4096K] rw-/rwx SM=PRV

Application Specific Information:
Performing @selector(menuItemAction:) from sender NSMenuItem 0x7fdf48580630

Thread 0 Crashed:: Dispatch queue:
0 com.xojo.XojoFramework 0x00000001072b056f StringMapIterator<RuntimeObject*>::~StringMapIterator() + 93
1 com.xojo.XojoFramework 0x00000001072b0504 StringMapIterator<RuntimeObject*>::~StringMapIterator() + 14
2 com.xojo.XojoFramework 0x0000000107339571 RuntimeControl::ReleaseData() + 105
3 org.tempel.arbed 0x00000001058ecc74 Control.__Exit%%o + 36
4 com.xojo.XojoFramework 0x00000001073b2c63 RuntimeUnlockObject + 815
5 org.tempel.arbed 0x00000001061c417c RBPrjHLDiff2Win.RBPrjHLDiff2Win._FileClose_Action%b%o<RBPrjHLDiff2Win.RBPrjHLDiff2Win> + 396

The @selector(menuItemAction:) in both crashes is related to the fact that I close the window with Cmd-W.

Yeah, that bit I recognize :slight_smile:

If I had to guess, I’d say that it’s trying to iterate something (in order to release it), but it’s already been released.

The one suggestion I do have, is to do the check manually, on window close, if it’s the last document window, then use API to terminate the application (or exit), thus bypassing Xojo’s destruction routine.

The code I wrote for this is at the top of this post, being used exactly to avoid a crash on quit!

I’m using 2019R1.1 also, and I was browsing release notes to try to decide if/when to upgrade, and I came across these :

  • 2019r2 IDE » Miscellaneous The Windows preference for whether or not to quit when the last window is closed can no longer affect other platforms.
  • 2019r3 Crashes & Assertions » Crash No longer randomly crashes when closing a Window (the crash was dependent on where the Window was being Closed, and how the controls were being destructed in user code, so in most cases this was not an issue).

Both of those seem related to your issue maybe?

Hi Michael, the second one sounds quite much like the one I’m struggling with. I’ll see if I can build Arbed with r3, then (when I tried last, I ran into some other immediate difficulties with that, though, due to Xojo having removed some critical functions that I need in Arbed and other apps).

Huh, looking at the report, it says that it’s a problem specific to Windows, not macOS. So it’s unclear whether this will fix the issue on macOS as well. I’d like to ask for a clarification on that, i.e. whether that fix was a general or OS specific fix, but it seems I can’t add new comments to the report. And William is not reading here, is he?

And, sadly, I haven’t found time to look further into this myself so far.

That case (#57678) was a cross platform fix FWIW.

Oh no - I had spent hour to make Arbed compile in Xojo 2019r3.1, by re-implementing the removed APIs, and it seems that this fixed the crash-on-Close issue indeed in some quick tests.

But just now, after I’ve uploaded a new 1.9b7 version of Arbed and committed my changes to git, viewing the changes in SmartGit with Arbed (i.e. Arbed showed its own source code changes), it crashed again the same way.

So, unfortunately, Xojo 2013r3.1 does not fix the crash on Close for me in Arbed. :frowning:

However, here’s some info for you other Xojo users:

I also found out that the crash (as shown in my first post) occurs when you call quit from within the Window.Close handler.

I wonder if the bug that Willam fixed had the same cause, i.e. the framework code checked App.AutoQuit in the Close handler, and if it’s true, it invoked the Quit method immediately, leading to the same crash I found.

And beware: Calling Quit from Window.Close will still likely crash your app, even in Xojo 2019r3.1! If you need to do this, then use a Timer to delay the call to Quit until after Close has been called.

In Arbed, though, I had already implemented the work-around, with avoiding AutoQuit, but that didn’t help prevent the crash.