App crash on quit with 2026r2

This started happening with 2026r2, does not happen when i revert to 2025r2.1. Like the subject line says, the app crashes on quit, both built and while debugging (the latter is untraceable, gives that “your app crashed popup”). Crash log and Claude’s diagnosis below:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x191f595d0 __pthread_kill + 8
1 libsystem_pthread.dylib 0x191f91c20 pthread_kill + 288
2 libsystem_c.dylib 0x191e9ea30 abort + 180
3 libsystem_malloc.dylib 0x191daedc4 malloc_vreport + 896
4 libsystem_malloc.dylib 0x191dd2ea8 malloc_zone_error + 104
5 libsystem_malloc.dylib 0x191dd2c10 _tiny_check_and_zero_inline_meta_from_freelist + 188
6 libsystem_malloc.dylib 0x191da4948 tiny_malloc_from_free_list + 1376
7 libsystem_malloc.dylib 0x191da3d70 tiny_malloc_should_clear + 292
8 libsystem_malloc.dylib 0x191da2afc szone_malloc_should_clear + 92
9 CoreAutoLayout 0x19a960d6c _hashMapRehash + 172
10 CoreAutoLayout 0x19a960f14 NSISSparseVectorMapInsert + 232
11 CoreAutoLayout 0x19a945ac8 -[NSISObjectiveLinearExpression setPriorityVector:forKnownAbsentVar:] + 56
12 CoreAutoLayout 0x19a945ca8 -[NSISObjectiveLinearExpression addVar:priority:times:processVarNewToReceiver:processVarDroppedFromReceiver:] + 252
13 CoreAutoLayout 0x19a95fb80 NSISLinExpEnumerateVarsAndCoefficients + 104
14 CoreAutoLayout 0x19a945554 -[NSISObjectiveLinearExpression initWithLinearExpression:priority:engine:] + 140
15 CoreAutoLayout 0x19a94d0e0 -[NSISEngine tryUsingArtificialVariableToAddConstraintWithMarker:row:usingInfeasibilityHandlingBehavior:mutuallyExclusiveConstraints:] + 240
16 CoreAutoLayout 0x19a9510d8 -[NSISEngine _tryToAddConstraintWithMarkerEngineVar:row:mutuallyExclusiveConstraints:] + 472
17 CoreAutoLayout 0x19a950ba0 -[NSISEngine tryToAddConstraintWithMarker:expression:mutuallyExclusiveConstraints:] + 672
18 CoreAutoLayout 0x19a965320 -[NSLayoutConstraint _addLoweredExpression:toEngine:lastLoweredConstantWasRounded:mutuallyExclusiveConstraints:] + 232
19 CoreAutoLayout 0x19a9680d4 -[NSLayoutConstraint _addToEngine:mutuallyExclusiveConstraints:] + 152
20 AppKit 0x1966150e4 __60-[NSView(NSConstraintBasedLayoutInternal) _setLayoutEngine:]_block_invoke_2 + 312
21 CoreAutoLayout 0x19a94f588 -[NSISEngine withBehaviors:performModifications:] + 88
22 AppKit 0x196615880 -[NSView(NSConstraintBasedLayoutInternal) _withAutomaticEngineOptimizationDisabled:] + 48
23 AppKit 0x196614f78 __60-[NSView(NSConstraintBasedLayoutInternal) _setLayoutEngine:]_block_invoke + 328
24 AppKit 0x196614de4 -[NSView(NSConstraintBasedLayoutInternal) _setLayoutEngine:] + 492
25 AppKit 0x19661504c __60-[NSView(NSConstraintBasedLayoutInternal) _setLayoutEngine:]_block_invoke_2 + 160
26 CoreAutoLayout 0x19a94f588 -[NSISEngine withBehaviors:performModifications:] + 88
27 AppKit 0x196615880 -[NSView(NSConstraintBasedLayoutInternal) _withAutomaticEngineOptimizationDisabled:] + 48
28 AppKit 0x196614f78 __60-[NSView(NSConstraintBasedLayoutInternal) _setLayoutEngine:]_block_invoke + 328
29 AppKit 0x196614de4 -[NSView(NSConstraintBasedLayoutInternal) _setLayoutEngine:] + 492
30 AppKit 0x19592e138 make_and_host_engine + 144
31 AppKit 0x1966145c8 -[NSView(NSConstraintBasedLayoutInternal) _didChangeHostsAutolayoutEngineTo:] + 56
32 AppKit 0x196614b08 -[NSView(NSConstraintBasedLayoutInternal) _engageAutolayout] + 100
33 AppKit 0x196614b20 -[NSView(NSConstraintBasedLayoutInternal) _engageAutolayout] + 124
34 AppKit 0x196615800 -[NSView(NSConstraintBasedLayoutInternal) _layoutEngine_windowDidChange] + 96
35 AppKit 0x1958e3298 -[NSView _setWindow:] + 1224
36 AppKit 0x1958eabc4 -[NSView addSubview:] + 212
37 AppKit 0x19590a8c8 -[NSWindow setContentView:] + 300
38 AppKit 0x1958df004 -[NSWindowTemplate nibInstantiate] + 380
39 AppKit 0x1958b132c -[NSIBObjectData instantiateObject:] + 212
40 AppKit 0x1958b0cf8 -[NSIBObjectData nibInstantiateWithOwner:options:topLevelObjects:] + 252
41 AppKit 0x1958a68e4 loadNib + 340
42 AppKit 0x1958a5f14 +[NSBundle(NSNibLoading) _loadNibFile:nameTable:options:withZone:ownerBundle:] + 560
43 AppKit 0x195a37c34 -[NSWindowController loadWindow] + 252
44 AppKit 0x195a37a1c -[NSWindowController window] + 64
45 XojoFramework 0x10d481b68 0x10d1e0000 + 2759528
46 XojoFramework 0x10d2e18a8 TooltipImpCocoa::~TooltipImpCocoa() + 36
47 XojoFramework 0x10d2e18d4 TooltipImpCocoa::~TooltipImpCocoa() + 12
48 XojoFramework 0x10d3cb8ec RuntimeListbox::~RuntimeListbox() + 104
49 XojoFramework 0x10d28d398 CocoaListbox::~CocoaListbox() + 12
50 XojoFramework 0x10d47ad40 SubPane::Unlock() + 252
51 XojoFramework 0x10d47aca4 SubPane::Unlock() + 96
52 XojoFramework 0x10d47aca4 SubPane::Unlock() + 96
53 XojoFramework 0x10d3404d8 RuntimeView::UnifiedClose(bool) + 524
54 XojoFramework 0x10d3328e8 0x10d1e0000 + 1386728
55 XojoFramework 0x10d492964 IterateWindowList(unsigned char ()(Window, void*), void*) + 880
56 XojoFramework 0x10d332798 TestApplicationQuit() + 120
57 XojoFramework 0x10d332938 ApplicationQuit(long long, unsigned char) + 20
58 XojoFramework 0x10d392360 RuntimeMenuItemClick(RunMenuItem*, unsigned char, Window*, unsigned char*) + 268
59 XojoFramework 0x10d29d0b4 CocoaMenu::_MenuItemAction(NSMenuItem*) + 76
60 XojoFramework 0x10d29d734 0x10d1e0000 + 775988
61 AppKit 0x195a74ffc -[NSApplication(NSResponder) sendAction:to:from:] + 460
62 AppKit 0x195b3f088 -[NSMenuItem _corePerformAction] + 372
63 AppKit 0x1960ef48c _NSMenuPerformActionWithHighlighting + 152
64 AppKit 0x195b77830 -[NSMenu performActionForItemAtIndex:] + 200
65 AppKit 0x195b77750 -[NSMenu _internalPerformActionForItemAtIndex:] + 76
66 AppKit 0x1960e5dec +[NSCocoaMenuImpl _performActionForMenuItem:] + 84
67 AppKit 0x195f0ec10 -[NSMenuTrackingSession _performPostTrackingDismissalActions] + 268
68 AppKit 0x195f0e984 -[NSMenuTrackingSession startRunningMenuEventLoop:] + 1128
69 AppKit 0x195fb6d3c -[NSMenuBarTrackingSession startMonitoringEventsInMode:] + 68
70 AppKit 0x195fb5d24 -[NSMenuBarTrackingSession _mouseDownEventHandler:] + 264
71 AppKit 0x195fb5c04 -[NSMenuBarTrackingSession handleEvent:] + 248
72 AppKit 0x195fb5ae4 __57-[NSMenuBarTrackingSession _addLocalEventMonitorIfNeeded]_block_invoke + 192
73 AppKit 0x195acaa5c _NSSendEventToDequeuingObservers + 252
74 AppKit 0x1960c5aa4 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 2192
75 XojoFramework 0x10d2b92f0 0x10d1e0000 + 889584
76 XojoFramework 0x10d2b9370 0x10d1e0000 + 889712
77 ImageTrak64 0x102fd3120 Application._CallFunctionWithExceptionHandling%%op + 164
78 XojoFramework 0x10d4363c8 CallFunctionWithExceptionHandling(void (*)()) + 180
79 XojoFramework 0x10d2b9314 0x10d1e0000 + 889620
80 AppKit 0x1958c1ffc -[NSApplication run] + 476
81 XojoFramework 0x10d434bfc RuntimeRun + 48
82 ImageTrak64 0x10317e558 REALbasic._RuntimeRun + 28
83 ImageTrak64 0x10a33e9c8 _Main + 476
84 ImageTrak64 0x10a3237c4 main + 36
85 dyld 0x191c07154 start + 2476

Claude:

This crash report gives a fuller picture than the sampling profiles, and it actually strengthens the diagnosis. The destructor chain is identical — TooltipImpCocoa::~TooltipImpCocoa() → RuntimeListbox::~RuntimeListbox() → CocoaListbox::~CocoaListbox() → SubPane::Unlock() → RuntimeView::UnifiedClose() during quit — but now we can see exactly what the spurious NIB load does: it calls -[NSWindowTemplate nibInstantiate] → -[NSWindow setContentView:] → -[NSView addSubview:] → -[NSView _setWindow:], which triggers AppKit’s Auto Layout engine to spin up (_engageAutolayout, make_and_host_engine).

The actual crash then happens inside Apple’s CoreAutoLayout framework, specifically _hashMapRehash while inserting into a sparse vector map (NSISSparseVectorMapInsert) during constraint-solving setup — that memory operation lands on already-corrupted heap metadata and malloc aborts. So the sequence is: Xojo’s tooltip destructor wrongly triggers full window/NIB instantiation, which cascades into a brand-new Auto Layout engine being created for a window that shouldn’t be receiving one at that moment, and that operation is what stumbles into the corrupted heap.

Why this is a framework bug, not your code

Three things point squarely at Xojo’s runtime rather than ImageTrak’s source:

  • Every frame from the destructor down through the AutoLayout crash is inside XojoFramework, AppKit, or CoreAutoLayout — none of it is your compiled ImageTrak64 code. Your app only appears at the very top of the stack, simply triggering “Quit” from the menu.

  • A destructor (TooltipImpCocoa::~TooltipImpCocoa) should never instantiate a new window/NIB and engage a fresh Auto Layout engine — that’s an internal lifecycle-ordering defect in how Xojo’s Cocoa Listbox/Tooltip implementation tears down.

  • Most importantly, you’ve now empirically shown the bug vanishes when compiled with Xojo 2025r2.1. Since your app’s source hasn’t changed, this proves the defect lives in the Xojo IDE/framework version you were previously compiling with, and Xojo apparently altered the Tooltip/Listbox teardown or Cocoa nib-loading logic in that later release.

I can’t help you for the crash, sorry, but I can mention you can turn off the feature where Xojo catches the crash by going to “Project”→“Break on fatal error”. This brings back the usual system crash dialog.

Have you reported it to Xojo.
https://tracker.xojo.com/xojoinc/xojo/-/issues

sure but it won’t help because it’s a new framework bug.

Hi Ian, i expected someone to ask this but honestly, so few of my reports get any attention that i’ve given up filing them. If xojo feels this is important enough they’ll do something. And I know what you’re going to say next “if you don’t file it won’t get fixed”. Going back to 2025r2.1 is my fix (along with the TextArea margin bug that i reported and is still there, etc etc).

Now if the forum had a button “Send as new bug report” then I’d press it of course. I already made the effort to alert the community.

Any report you don’t file will get even less attention than those you do. :slight_smile:

Really reports of hard crashes usually get attention fairly quickly, at least that has been my experience. Do you have beta access, r2.1 is coming soon and solves some of these.

The Anatomy of the Crash

If you read the stack trace from the bottom up, here is the exact chain of events causing the crash:

  1. The Trigger: You click “Quit” in your menu (ApplicationQuit).
  2. The Teardown: Xojo starts closing windows and destroying controls to free up memory (UnifiedCloseRuntimeListbox::~RuntimeListbox()).
  3. The Culprit: The Listbox destructor tears down its macOS backend tooltip implementation (TooltipImpCocoa::~TooltipImpCocoa()).
  4. The Bizarre Behavior: Inside the tooltip’s destructor, Xojo calls an internal function that requests the .window property of an Apple NSWindowController.
  5. The Trap: Because the application is shutting down, this window either doesn’t exist or has already been unlinked. Under the hood, macOS attempts to lazily load a new window from a NIB template (nibInstantiatesetContentViewaddSubview).
  6. The Crash: Instantiating UI elements and spinning up the Auto Layout engine (CoreAutoLayout) in the middle of application memory teardown causes a critical conflict. The system memory manager (libsystem_malloc) detects that the heap/freelist is in an invalid state for new allocations, throws a zone error, and forces an immediate abort (pthread_kill).

Why 2026r2 and not 2025r2.1?

The crash you are seeing is a classic order-of-operations / lifecycle bug introduced in the framework of Xojo 2026r2.

Xojo probably changed how HelpTags (tooltips) or control destruction lifecycles are handled on macOS in 2026r2. The framework is inadvertently triggering a lazy-load of a window controller during a destructor phase where creating new UI objects is strictly forbidden by the OS.

no, i do not

i’m facing the same problem.

Are you using Listbox or DesktopListbox ? Seems related to a Xojo bug handling a tooltip in this control.during a destruction cycle.

all Listboxes, but which one exactly is impossible to know, i have scores of them throughout my app, likely with many of them “open” but on not visible windows at quit time.

Such crash bugs are looked at immediately. “Alerting the community” doesn’t get bugs fixed. The bug is a bit different than https://tracker.xojo.com/xojoinc/xojo/-/issues/81616 because of the tooltip. But checking out the beta is a good idea.

You can ask to join the testers group email hello@xojo.com. If you wish.

Yes, like I said. I was responding to the fact that you thought the crash was untraceable while debugging.

2026r2 introduced a bug on Windows where an active timer in a container will crash the app in a weird way when the container/window is closed. It’s fixed in 2026r2.1 coming out early Aug.

https://tracker.xojo.com/xojoinc/xojo/-/issues/81705