Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff8d13df06 __pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff8ae054ec pthread_kill + 90
2 libsystem_c.dylib 0x00007fff92cd86df abort + 129
3 libsystem_malloc.dylib 0x00007fff8ea29396 szone_error + 626
4 libsystem_malloc.dylib 0x00007fff8ea1f5f4 tiny_free_list_remove_ptr + 289
5 libsystem_malloc.dylib 0x00007fff8ea1d946 szone_free_definite_size + 1480
6 com.xojo.XojoFramework 0x000000010eccc554 checkBoxDestructor + 78
7 com.XXX.XXX 0x00000001090aeba4 CheckBox.__Exit%%o<CheckBox> + 36
8 com.xojo.XojoFramework 0x000000010ed46c83 RuntimeUnlockObject + 815
9 com.xojo.XojoFramework 0x000000010ec4e2b8 RuntimePaneDelegate::~RuntimePaneDelegate() + 28
10 com.xojo.XojoFramework 0x000000010ec4e2da RuntimePaneDelegate::~RuntimePaneDelegate() + 14
11 com.xojo.XojoFramework 0x000000010ec4e413 RuntimePaneDelegate::PaneClosing(Pane*) + 71
12 com.xojo.XojoFramework 0x000000010ed81731 SubPane::Close() + 173
13 com.xojo.XojoFramework 0x000000010ed817ed SubPane::Unlock() + 143
14 com.xojo.XojoFramework 0x000000010ec4de52 RuntimeView::UnifiedClose(bool) + 574
15 com.xojo.XojoFramework 0x000000010ed43b95 RuntimeCloseWindow + 16
16 com.XXX.XXX 0x000000010900ffa4 Window.Close%%o<Window> + 36
17 com.XXX.XXX 0x0000000109ece19c WINDOW1.WINDOW1.redefaultsettings%%o<WINDOW1.WINDOW1> + 14364
18 com.XXX.XXX 0x000000010973fdd6 WINDOW1.WINDOW1.TabPanel1_Change%%o<WINDOW1.WINDOW1>o<PagePanel> + 1798
19 com.XXX.XXX 0x0000000109fa43e4 Delegate.IM_Invoke%%o<PagePanel> + 52
20 com.XXX.XXX 0x0000000109577a14 AddHandler.Stub.15%% + 52
21 com.XXX.XXX 0x00000001090bf011 PagePanel.Value.Set%%o<PagePanel>i4i8 + 49
22 com.XXX.XXX 0x000000010996716e WINDOW1.WINDOW1.Canvas48_Change%%o<WINDOW1.WINDOW1>o<TabControlCanvas> + 894
23 com.XXX.XXX 0x0000000109fa5f04 Delegate.IM_Invoke%%o<TabControlCanvas> + 52
24 com.XXX.XXX 0x0000000109fa4b54 AddHandler.Stub.26%% + 52
25 com.XXX.XXX 0x000000010cb9f154 TabControlCanvas.Event_MouseUp%%o<TabControlCanvas>i8i8 + 4388
26 com.xojo.XojoFramework 0x000000010ec42fde RuntimeCanvas::HandleMouseUp(xojo::Value<xojo::Points>, xojo::Value<xojo::Points>) + 106
27 com.xojo.XojoFramework 0x000000010ebd35f6 0x10eaea000 + 955894
28 com.xojo.XojoFramework 0x000000010ebce83b 0x10eaea000 + 935995
29 com.apple.AppKit 0x00007fff988f2713 -[NSWindow _handleMouseUpEvent:isDelayedEvent:] + 119
30 com.apple.AppKit 0x00007fff988f33ad -[NSWindow _reallySendEvent:isDelayedEvent:] + 212
31 com.apple.AppKit 0x00007fff98332539 -[NSWindow sendEvent:] + 517
32 com.xojo.XojoFramework 0x000000010ebcf861 0x10eaea000 + 940129
33 com.apple.AppKit 0x00007fff982b2a38 -[NSApplication sendEvent:] + 2540
34 com.xojo.XojoFramework 0x000000010ebbf267 0x10eaea000 + 873063
35 com.XXX.XXX 0x000000010906a3a5 Application._CallFunctionWithExceptionHandling%%o<Application>p + 181
36 com.xojo.XojoFramework 0x000000010ed444db CallFunctionWithExceptionHandling(void (*)()) + 262
37 com.xojo.XojoFramework 0x000000010ebbf1e2 0x10eaea000 + 872930
38 com.apple.AppKit 0x00007fff98119df2 -[NSApplication run] + 796
39 com.xojo.XojoFramework 0x000000010ed4284d RuntimeRun + 42
40 com.XXX.XXX 0x000000010915d5c3 REALbasic._RuntimeRun + 19
41 com.XXX.XXX 0x000000010db72d08 _Main + 536
42 com.XXX.XXX 0x000000010db69c83 main + 19
43 libdyld.dylib 0x00007fff8d0f15ad start + 1
Ok look at frame #17 where is has redefaultsettings
That calls Windows.Close in frame 16
And eventually that gets to checkbox destructor and evetually crashes
This seems like a case where your closing a Windows out from under controls and then trying to use those same controls in other code that gets called
I’d go hunting for that sort of thing going in
Effectively, it’s not ListBox but PopupMenu, I write a comment on the other thread Random crashes in Yosemite with Xojo2019 .
@Norman Palardy For the second crash report, that makes sense. It does look like something in application code, and I will investigate. As for the first one, there are really no application level calls…
@Thomas ROBISSON some of the crashes that I am seeing are not in windows that have PopupMenus.
This does seem to be Yosemite specific though
Sine I added the code to remove all rows in PopupMenu I don’t have crash and I’m running El Capitan. But maybe there is another control which cause the crash?
[quote=438416:@erin jamroz]@Norman Palardy For the second crash report, that makes sense. It does look like something in application code, and I will investigate. As for the first one, there are really no application level calls…
[/quote]
The first one almost looks like its occurring when the app is quitting
I had originally opened a separate thread as I didnt think my crash reports looked like the ones you were posting here. However after more looking at it I believe it could be the same problem. At least all the windows that caused the app to crash when closed did have popup menus on them. My latest crash report from testing this morning is here:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libobjc.A.dylib 0x00007fff7631c31c objc_release + 28
1 libobjc.A.dylib 0x00007fff7631d11a (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 710
2 com.apple.CoreFoundation 0x00007fff4bafc32e _CFAutoreleasePoolPop + 22
3 com.apple.Foundation 0x00007fff4ddc3c82 -[NSAutoreleasePool drain] + 144
4 com.apple.AppKit 0x00007fff4919a8ab -[NSApplication run] + 810
5 com.xojo.XojoFramework 0x0000000102ff882d RuntimeRun + 42
6 com.shed.xtension 0x0000000100937d23 REALbasic._RuntimeRun + 19
7 com.shed.xtension 0x0000000102359498 _Main + 536
8 com.shed.xtension 0x0000000102347223 main + 19
9 libdyld.dylib 0x00007fff77aed3d5 start + 1
in my case they always look identical to this and never specifically reference a popup menu or any other code at all which is why I thought that my problem had to do with the changing of the window release structure on MacOS a couple of versions ago. I can duplicate it fairly easily now that I know to test with windows with popup menus, probably every 3rd or 4th window close will crash the app.
Does anyone know how many Xojo versions I have to go back in order to be able to do a hot fix release that doesnt have this problem? I need to get a version to my users that doesnt do this even if the memory leak from the listbox cell draw issue comes back.
By way of testing I implemented Richards fix that he posted above, and I can no longer crash the app while it does this either. Im calling that a better work around than going back to an earlier Xojo version and might help the Xojo folks narrow down where the problem is in the framework. Of course I havent tested it extensively but my banging on it like I just did would have caused several crashes by now and so far Ive got nothing.
This is excellent Richard, thank you!
[quote=438285:@Richard Nicolella]As a workaround, I created a method to clear the popups:
Function ClearAllPopups extends w as window
for i as integer = 0 to w.ControlCount-1
dim c as Control = w.Control(i)
if c isa PopupMenu then
PopupMenu©.DeleteAllRows
end if
next
End Function
Then on any window with popupmenus, I call ClearAllPopups at the end of the window’s close event.
Haven’t had a crash since.[/quote]
To be honest: I haven’t tested if this works in this situation (or if this crash related issue has to be called from the Window itself).
I just can recommend to use your own subclasses of Controls, as it’s usually the easiest way to implement “Xojo Version specific workarounds *” that get applied to where-ever you’re using your own subclasses
so for this issue I would try this in my projects:
If you’re using your own Subclasses of Controls:
- Class
MyPopupMenu: Add Event Definition: Close
- Class
MyPopupMenu: Implement Event Close with code:
#if (XojoVersion >= 2019.01) then 'or whatever version this issue has been introduced
me.DeleteAllRows
#endif
Close
And while using your own MyPopupMenu (instead of the generic PopupMenu), all your PopupMenu’s will always empty themselves when closing. No need to think of it any more when creating a new window,
And in case you haven’t done so - search&replace (PopupMenu → MyPopupMenu) and replace the super’s to use your subclass.
*) once fixed, you can get rid of the workaround (but leaving it in place for affected Xojo Versions, should you need to still use them in some situation/projects):
#if (XojoVersion >= 2019.01) and (XojoVersion < 2019.03) then
me.DeleteAllRows
#endif
Close
unfortunately my app just crashed while I was using it and not even trying to make it crash. Same error as before. So im no longer 100% convinced that this is the solution. I might have missed a window but I dont think so…
Its not an answer all our crash problems, but it is an answer to some of them. Thankfully, my apps are crash free for now.
I will say this - in my opinion, any developers releasing desktops apps for Mac that are built with Xojo2019 r1 or 1.1 and use popupmenus, will need to address this issue in some form. We know that at least Yosemite and ElCap are affected, maybe more. Unless we are willing to write off users of these OS versions, we can be sure that those apps will be unstable.
FWIW, here is a chunk of the crash log for my app:
[code]Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fb792a00000
VM Regions Near 0x7fb792a00000:
MALLOC_TINY 00007fb792800000-00007fb792a00000 [ 2048K] rw-/rwx SM=PRV
–>
STACK GUARD 00007fff55889000-00007fff59089000 [ 56.0M] —/rwx SM=NUL stack guard for thread 0
Application Specific Information:
Performing @selector(performClick:) from sender XOJButton 0x608000342e10
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 com.apple.CoreGraphics 0x00007fff93d52fd3 shape_union + 564
1 com.apple.CoreGraphics 0x00007fff93d52d80 shape_union_with_bounds + 119
2 com.apple.CoreGraphics 0x00007fff93d52bbf CGRegionCreateUnionWithRect + 145
3 com.apple.CoreGraphics 0x00007fff93d52b22 CGSUnionRegionWithRect + 29
4 com.apple.AppKit 0x00007fff9bee5088 -[NSRegion addRect:] + 383
5 com.apple.AppKit 0x00007fff9bee4de4 -[NSWindow _setNeedsDisplayInRect:] + 425
6 com.apple.AppKit 0x00007fff9bedfcb6 -[NSView(NSInternal) _setWindowNeedsDisplayInViewsDrawableRect] + 378
7 com.apple.AppKit 0x00007fff9bf09791 -[NSView _removeSubview:] + 368
8 com.apple.AppKit 0x00007fff9bedd52c -[NSView _setSuperview:] + 951
9 com.apple.AppKit 0x00007fff9bf08f7f -[NSView removeFromSuperview] + 435
10 com.xojo.XojoFramework 0x0000000108391bf8 0x1082aa000 + 949240
11 com.xojo.XojoFramework 0x0000000108358f77 CocoaPaneDelegate::~CocoaPaneDelegate() + 37
12 com.xojo.XojoFramework 0x0000000108358fd2 CocoaPaneDelegate::~CocoaPaneDelegate() + 14
13 com.xojo.XojoFramework 0x00000001084741bf Pane::~Pane() + 69
14 com.xojo.XojoFramework 0x0000000108359e94 CocoaPopupMenu::~CocoaPopupMenu() + 130
15 com.xojo.XojoFramework 0x0000000108359f2d non-virtual thunk to CocoaPopupMenu::~CocoaPopupMenu() + 21
16 com.xojo.XojoFramework 0x0000000108541854 SubPane::Unlock() + 278
17 com.xojo.XojoFramework 0x00000001085417cd SubPane::Unlock() + 143
18 com.xojo.XojoFramework 0x000000010840de02 RuntimeView::UnifiedClose(bool) + 574
19 com.xojo.XojoFramework 0x0000000108503b75 RuntimeCloseWindow + 16[/code]
I have run into this same issue of app crashing when a document window with popupmenus is closed. Sometimes it takes 15 or more closures for it to crash. I created a simple test case and video. I am running under MacOS Majave and Xojo 2019r2. I don’t think this problem was in Xojo 2015-2018 versions and I think it only happens in code generated 32-bit and not 64-bit. I hope that Xojo can fix this as it is a nasty bug.
<https://xojo.com/issue/57961>
Why are you still testing for 32bit? That’s dead. The chance of getting a 32bit bug fixed is vanishingly small.
I had to stop developing for health reasons 4 yrs ago and just now returning to convert to 64-bit, retina, etc. Lots of work to do. I was getting to a stable starting point of recompiling old code in 32-bit with new compiler before debugging 64-bit. That is when I found this bug that appears to be in 2019 releases of Xojo. I agree that time is short to get all code 64-bit.
removeFromSuperview should be removeFromSuperviewWithoutNeedingDisplay on destruction.
Is there somewhere I can call that? Or is this a suggestion for Xojo to have a look at their framework for how they are closing the things?
It’s a suggestion for Xojo if they haven’t already made this change with a newer version. As the name suggests, the replacement will not ask for the window to be updated when the control is removed.
If you manually call this on a Xojo control, it will most likely create a crash later on when Xojo winds the window down.
It’s also my understanding that this doesn’t actually need to called on destruction, because releasing the window, should in theory also release the views (it can be a more complicated than that). But because I don’t know exactly what Xojo are doing, there may be a perfectly valid reason for releasing each view.