Mac crash after quit 2018r2

I’m getting an awful lot of crashing after quitting my apps in DebugBuild since updating to the latest IDE (haven’t tried built apps yet). These crashes did NOT happen in earlier versions of the IDE. The crash logs are all very similar, here are a couple of examples. I get the second type more often than the first:

Thread 0 Crashed:: Dispatch queue:
0 libsystem_kernel.dylib 0x00007fff92c25f06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff954204ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff887f76df abort + 129
3 libsystem_malloc.dylib 0x00007fff9391a396 szone_error + 626
4 libsystem_malloc.dylib 0x00007fff939105f4 tiny_free_list_remove_ptr + 289
5 libsystem_malloc.dylib 0x00007fff9390e946 szone_free_definite_size + 1480
6 XojoFramework 0x00000001050621ea IterateWindowList(unsigned char ()(Window, void*), void*) + 1354
7 XojoFramework 0x0000000104f0b714 TestApplicationQuit() + 101
8 XojoFramework 0x0000000104f0b8b4 ApplicationQuit(long long, unsigned char) + 13
9 XojoFramework 0x000000010503fcde QuitMenuAction + 46
10 My App.debug 0x0000000103e395aa QuitMenuItem.Event_Action%b%o + 26
11 XojoFramework 0x0000000104f6f931 RuntimeMenuItemClick(RunMenuItem*, unsigned char, Window*, unsigned char*) + 1323
12 XojoFramework 0x0000000104e73540 CocoaMenu::_MenuItemAction(NSMenuItem*) + 72
13 XojoFramework 0x0000000104e73ab0 0x104db7000 + 772784
14 libsystem_trace.dylib 0x00007fff94c7d07a _os_activity_initiate + 75
15 0x00007fff87ab0dbd -[NSApplication sendAction:to:from:] + 460
16 0x00007fff87ab0b57 -[NSMenuItem _corePerformAction] + 336
17 0x00007fff87ab08b7 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 114
18 libsystem_trace.dylib 0x00007fff94c7d07a _os_activity_initiate + 75
19 0x00007fff87aaf7a5 -[NSMenu performKeyEquivalent:] + 357
20 0x00007fff87aae949 -[NSApplication _handleKeyEquivalent:] + 920
21 0x00007fff879d50fe -[NSApplication sendEvent:] + 4274
22 XojoFramework 0x0000000104e8acaf 0x104db7000 + 867503
23 My App.debug 0x0000000103e644e5 Application._CallFunctionWithExceptionHandling%%op + 181
24 XojoFramework 0x000000010500b41b CallFunctionWithExceptionHandling(void (*)()) + 262
25 XojoFramework 0x0000000104e8ac2a 0x104db7000 + 867370
26 0x00007fff8783bdf2 -[NSApplication run] + 796
27 XojoFramework 0x0000000105009747 RuntimeRun + 40
28 My App.debug 0x0000000103f2cb53 REALbasic._RuntimeRun + 19
29 My App.debug 0x00000001048b210e _Main + 846 (/#main:693)
30 My App.debug 0x00000001048aa1e3 main + 19
31 libdyld.dylib 0x00007fff9222d5ad start + 1

Thread 0 Crashed:: Dispatch queue:
0 libobjc.A.dylib 0x00007fff8aa6a78c void std::__1::vector<objc_references_support::ObjcAssociation, objc_references_support::ObjcAllocator<objc_references_support::ObjcAssociation> >::__push_back_slow_path<objc_references_support::ObjcAssociation const&>(objc_references_support::ObjcAssociation const&&&) + 184
1 libobjc.A.dylib 0x00007fff8aa6a600 _object_remove_assocations + 222
2 libobjc.A.dylib 0x00007fff8aa64d4d objc_destructInstance + 109
3 libobjc.A.dylib 0x00007fff8aa64ccf object_dispose + 22
4 0x00007fff8783af80 -[NSResponder dealloc] + 139
5 0x00007fff87ad436a -[NSWindow dealloc] + 2117
6 0x00007fff8785b637 -[NSWindow release] + 190
7 0x00007fff93eb29fd -[__NSArrayM dealloc] + 205
8 libobjc.A.dylib 0x00007fff8aa65288 objc_object::sidetable_release(bool) + 242
9 0x00007fff87b26ca9 -[NSWindowController dealloc] + 457
10 XojoFramework 0x000000010d2c067d 0x10d027000 + 2725501
11 libobjc.A.dylib 0x00007fff8aa65288 objc_object::sidetable_release(bool) + 242
12 0x00007fff87857995 -[NSWindowController release] + 154
13 libobjc.A.dylib 0x00007fff8aa63b3b (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 477
14 0x00007fff93eccbc2 _CFAutoreleasePoolPop + 50
15 0x00007fff932ff7ca -[NSAutoreleasePool drain] + 153
16 0x00007fff8783be53 -[NSApplication run] + 893
17 XojoFramework 0x000000010d279747 RuntimeRun + 40
18 My App.debug 0x000000010c19a7d3 REALbasic._RuntimeRun + 19
19 My App.debug 0x000000010cb2053e _Main + 846 (/#main:693)
20 My App.debug 0x000000010cb18613 main + 19
21 libdyld.dylib 0x00007fff9222d5ad start + 1

What are you doing during quit?



The problem is, I have no idea how to reproduce it as it is inconsistent and doesn’t seem to affect built apps.

Me neither. Good to hear that it doesn’t happen for built apps, since I hadn’t tried yet … was worried that they would show the same behaviour, since “crash after quit” is a problem I’ve certainly run into before. The difference is, in the past the crash reports have shown me some reason for the crash - some object or method in my code, and I have been able to fix the problem. These reports tell me nothing about my code. They look like something to do with AppKit or the Xojo framework.

Maybe it’s related to these crashes and they happen with build apps: <>

Needs a response to keep it open…

It’s over 10 days and still open, maybe there is a private response?

Same here. I feel think there is some memory trashing going on that is subtle but deadly.

All responses from non-xojo employees to beta tickets are marked as private, its a bug that’s been reported.

Glad (well, not really, but you get my drift) I’m not the only one that’s seen this.

Yeah, its a bit annoying as I’m just reading a one sided conversation, if I had something to input into the discussion it might have been said already so I just don’t bother. Shame really as xojo could be missing out of valuable public input. I guess it’s not that important. <> <>

Is this perhaps the “calling Quit in a Close event” bug that’s causing the issue? I think it started with 2018r1. I have heard that 2018r2 fixes it, but I’m not wealthy enough to know for sure.

I had to stop calling Quit in my window Close event, and instead fire a 1ms timer that in turn calls Quit in its Action event.

The response is private because i had to attach a project which needs to stay confidential.

I have this bug even in a build app. appeared for me in 2018r2 (but I did not use 2018r1 …)
for now it happens on 64bits apps, but I did not notice it on 32bits apps.

Edit: I still have the bug with a 32 bits app, but it appears really less often than in 64bits app.

Some things might cause this like:
If you use addhandler on timers for example you have to removehandler and nil the timer before closing tue window or it will crash.

This issue is not debug only. It happens with build versions too.'I use Sams declares to bypass this issue with succes. Do a search here (there are several threads about this).

[quote=410028:@Derk Jochems]Some things might cause this like:
If you use addhandler on timers for example you have to removehandler and nil the timer before closing tue window or it will crash.[/quote]

Although this is indeed something you need to take care off, it isnt related to the OP issue.

I used Tim’s declares and they don’t solve the problem.

are they the same as Sam’s ?