Xojo and Apple Crash Dumps

I have a question about Xojo capabilities; basically, are they able to read and interpret Apple Crash Dumps?

I found today that with a new install of my App, I can reliably cause a crash when the app is terminated, and that there is a “user-workaround” or I can comment out two statements upon either of which the crash doesn’t occur. Of course, if I do the latter, the app doesn’t really work properly.

Essentially, the relevant bit is that at startup, the app populates two menus. Various user actions may require the menus to be remade. I do this by recursively removing menu items until the menus are empty and then remaking them. If this is the first thing the user does, the app then crashes (segmentation fault) when quit. If the user does something with the menu first, even just like opening it, why - then no crash.

Sad to say, making a tiny test app which replicates the create/remove/remake menus steps described, exhibits no crash behaviour. So, is there any point in submitting a feedback, as the first thing they are going to ask for is is such an app.

OTOH, are they capable of looking at the crash dump and saying well xyz was happening at the crash moment, so were you doing any xyz? Then perhaps I can look elsewhere for the problem and make some progress.

curious, what if instead of removing specific menu items, what would happen if you always cleared out the menu completely and create from scratch? do you get same results on File Quit?

They keep all the required symbol files from building everything and should be able to use those to put symbols back into a dump and see what is crashing

I did also file a recent bug report about using close in enable menu items
Its absolutely reproducible
And the fix I’m not really happy with but :frowning:

If you can’t reproduce the crash don’t bother. The bug report will rot in limbo.

1 Like

Not sure I follow here. This is what I do to clear out a menu (each menu item has an icon either as a file or a directory):

Public Sub removeMenus(menuPtr as MenuItem)

  Var  i, numItems As Integer, ptr As MenuItem
  numItems = menuPtr.Count () - 1
  for  i=0 to numItems
    ptr = menuPtr.MenuAt (0)
    if  (ptr.icon=directory)  then removeMenus (ptr)
    menuPtr.RemoveMenuAt (0)
End Sub

The menu is then empty and I recreate it using the same method that created it in the first place.

Well I seem unable to recreate it with a small project. I could give them my entire app I suppose. :disappointed_relieved:

OK. I’ll send in a Feedback and see how it goes.

Edit: forgot to add that whatever’s behind this crash is present in 2019r1.1 through to latest test build

If you only have a tiny little bug then it’s not very likely that your bug is going to be fixed. Especially, when the Xojo people have to look at your whole app. They might do that in extreme circumstances.

http://feedback.xojo.com/case/59891: Debugger hard crashes
http://feedback.xojo.com/case/58879: Hard crash in date constructor. Without Christian my app would have been dead.

The first one is really an obscure problem. The encoding of a string was missing. But the second one is a really bad one. What is happening with the 2 reports? Absolutely nothing.

ha! In my new job I was doing research on a bug and came across Feedback Report 5827 I submitted in 2009! Having this one event would solve a BUNCH of issues in the products for our company. There was a subsequent issue (11665) that’s gotten more traction. This one seems like such an easy win for Xojo…

But yes, Feedback certainly seems to be where good ideas and serious bugs go to die.

1 Like

My thought process is to try to step through the menu before it gets manipulated. Example, do you get the same behavior if you populate the menu without removing anything. If that works, what happens if you redim the menu and populate from scratch, does that produce same behavior.

another example that I a curious about, looks like you are assigning the menuitem count prior to looping through, what I am not sure about is if you remove one menuitem and then proceed to iterate through the loop, doesnt the menuitem count change but the numItems is not updated from the original assignment? example, lets say you have 20 menuitems and you assign 20 to numItems. Now, as you are looping through the twenty the code finds that menuitem 5 needs to be remove. Once this is done, doesnt the index of menuPtr change? so with menuitem 5 gone does menuitem 6 become 5, menuitem 7 become 6, etc…

below is what I am referring to where the menu item index changes and when you remove one the index of remaining menu items changes.

    // Add some items
    base.AddMenu( New MenuItem("Test 1"))
    base.AddMenu( New MenuItem("Test 2"))
    base.AddMenu( New MenuItem("Test 3"))

    // Add a Separator
    base.AddMenu( New MenuItem(MenuItem.TextSeparator))

    // Add a sub menu
    Var submenu As New MenuItem("SubMenu")
    submenu.AddMenu( New MenuItem("SubMenu Test 1"))
    submenu.AddMenu( New MenuItem("SubMenu Test 2"))
    submenu.AddMenu( New MenuItem("SubMenu Test 3"))

    // Add a Separator
    base.AddMenu(New MenuItem(MenuItem.TextSeparator))

    MessageBox base.MenuAt(1).Value
    MessageBox base.MenuAt(1).Value

    Return True

A menu and the item indexes is like an array
If you remove one from the middle the ones after it “move up” to take over those spots
More or less

If I do that, no crash, but the menu then has everything in it twice.

How do you redim a menu? It’s not an array :grin:

I remove the zeroth element each time. If there are 20 items I need to do that 20 times.

I’ve just written a custom container control that has a separate control for the headers that lets me do whatever I want with the headers
I have a couple glitches to fix but so far it works as a drop in replacement for a listbox - sort indicators, icons, font, colors, different size etc

Do you handle column resizing?

How do you handle coloring the background X-platform so it looks at home with native list boxes?

That is something that made me hesitant to write my own.

If I were to do my own I would consider making it be multi-row because I often use headers and sub headers (2 line headers) in tables:

|          Main Category       |
|  Sub Cat1    |    Sub Cat2   |
|    Data      |     Data      |

Not all headers need to be two rows. The ones with no sub headers would just have their entry centered vertically.

BTW the approach I thought of was using the paint events to always paint the the top row(s) as the header and override all the methods that take a row/Cell index to adjust them for the offset. For multi-Row headers is where my mergeable listbox code would come in handy so I could still use the standard listbox borders.

column resizing yes
I try and stick to the OS theme
It has adjustable heights and such for the headers
Doesnt permit stacked headers like you show

as norm stated, its like an array. In your current code, I see you do this first

then you start your loop

the problem I see with this is, once you remove an item, the index of the menu items change; however, your loop doesn’t account for the change of index. What I am curious is if the issue is referencing an index item that used to exist an index x and then try to reference it, its possible you might be facing a OutOfBoundsException error.

Rich, you’re not reading my code. I’m not referencing an item at index x, I’m referencing the zeroth item, and removing the zeroth item. If I have 20 items and I keep removing item zero, then when the loop finishes the menu will be exactly empty. If I were removing the i’th item then you’d have a point. But I’m not.

The crash is a hard crash reported to me by macOS, not an error reported to me by Xojo in the form of an OOBE error.

There are some things I would try. In no particular order:

  1. From your initial post I gather that the crash happens, if the user calls a menu by shortcut instead of “opening” it with the mouse, right?
    If that’s true, call the global EnableMenuItems methods right before the user has the first chance to call the menu. So maybe at the very end of the App.Open event, or, if you have a main window, at the end of that window’s Open event. This may have the same effect as the user clicking the menu with the mouse.

  2. How do you initially populate the menu? Do you initially set it up in the menu editor in the IDE or via code? If it’s in the menu editor, try to do it completely in code.

  3. Inside the for loop test if ptr is nil.

  4. I’m not sure about the if (ptr.icon=directory) then ... part. Try if (ptr.count > 0) then ... instead. In my experience accessing the Icon property of a menu item can be a bit fragile, if it is nil. But then again I’m still using Xojo 2017, so that problem may have been solved.
    And maybe you don’t even need to remove the menu items recursively. What happens if you just remove the parent item? Does the crash still happen? Are the sub-menus properly closed, or are they kept in memory?