Reproducing 72056 "Hard crash when adding row to popup menu with AddRowAt where the index is too high"

I made a super simple ticket with one line of code:

me.AddRowAt(1, "test")

in the Open event of a popupmenu. This crashes for me for the current version of Xojo and the latest beta under Ventura and even High Sierra.

The crash does not happen for Xojo. Can anyone else reproduce the crash? The bug is easy to work around. But it’s so odd that Xojo doesn’t get the crash.

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

Downloaded your sample from the ticket: test.xojo_xml_project

Run without problems. Mac Intel, Ventura 13.2.1, just a few 3rd party plugins.

I wonder if the exception is actually happening in the date creation function here:

1 libobjc.A.dylib 0x00000001a77aaea8 objc_exception_throw + 60
2 Foundation 0x00000001a8ba3910 -[NSCalendarDate initWithCoder:] + 0

Are you running a DE system or US English or something

Edit to add: also, has Daylight Savings time started where you are at? for us in (most of) USA it has as of 12 March.

I always use German region. DST starts end of March.

No crash here either (just nothing gets added and the popup menu stays empty). Daylight saving time starts here like in Germany, so it’s not related.
On Mac OS 13.2.1.

Thanks for testing. It looks like the bug is only reproducible for me.

Maybe something to do with Crash on NSException.

Don’t forget since 10.14,.apps no longer crash by default. Instead they go funky.

It’s a hard crash on both High Sierra and Ventura.

For you, but unless the Xojo engineer has enables it system wide on his Mac, it can easily go unnoticed, especially in a sample app.

Am not at puter, but I’d the crash report includes NSException, then I’m pretty sure that’s the case and most likely is a bug with the Xojo framework.

Does it work with ApI 1.0?

As it seems isolated to her machines, maybe plugins installed are the different part of the equation if other people running Xojo 2022r3 using German/Berlin locale in a Ventura machine can’t trigger it.

I also recommend to try again using a newer version (specially some latest beta) and see if it still happens because from 2022r3 to today many things changed, including some Ventura focused fixes and some locale operations (as string compare) fixes.

1 Like

In the opening event enter this code.

me.AddRowAt(1, "blabla")

break

On this M1 Air it never reaches the break point, and when enabling “Crash on NSException” the application crashes with the same report as @Beatrix_Willius

3 Likes

With what configuration of Xojo version, locale, and macOS version?

Xojo 2021 r3.1, Venture 13.2.1 and English/Taiwan (where we have no such thing as DST).

Have you tried inserting a break point after the code and running it?

1 Like

I can try it later in an AS machine, but not in Ventura and not in an old Xojo as 2021.

I can reproduce the variation of the bug on Intel (macOS 13.2.1, latest beta of Xojo, US/English, PDT)

System.Debuglog("Foo")
me.AddRowAt(1, "blabla")
System.Debuglog("Bar")
break

the function seems to die before “bar” is logged.

image

1 Like

So with a me.AddRowAt(0, "blabla") it reaches the bar?

Something says me that an internal out of range exception is producing some kind of “early return” in this one, and a crash in the older versions.

Correct. This seems to be a manifestion of an old issue, in which a macOS Cocoa exception no longer kills the app, instead the Xojo method or function just exits early, which is very confusing. This is described here: Crash an application on NSException

For some reason on @Beatrix_Willius system, it is crashing.

1 Like

Edit: Credit to @Sam_Rowlands who beat me to it by figuring this out, over on the Issues website.

I can reproduce it with this code:

#If TargetMacOS 
  const FoundationLib = "Foundation"
  
  Declare Function standardUserDefaults Lib FoundationLib Selector "standardUserDefaults"(NSUserDefaultsClass As Ptr) As Ptr
  Declare Function NSClassFromString Lib FoundationLib(ClassName As CFStringRef) As Ptr
  
  Static standardUserDefaultsPtr As Ptr = standardUserDefaults(NSClassFromString("NSUserDefaults"))
  
  
  Declare Sub setBool Lib FoundationLib Selector "setBool:forKey:"(NSUserDefaults As Ptr, value As Boolean, Key As CFStringRef)
  setBool(standardUserDefaultsPtr, True, "NSApplicationCrashOnExceptions")
  
  
#EndIf 

System.Debuglog("Foo")
me.AddRowAt(1, "blabla")
System.Debuglog("Bar")
break

Crashed Thread:

Summary

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000001, 0x0000000000000000

Termination Reason: Namespace SIGNAL, Code 4 Illegal instruction: 4
Terminating Process: exc handler [52354]

Application Specific Backtrace 0:
0 CoreFoundation 0x00007ff81bde33eb __exceptionPreprocess + 242
1 libobjc.A.dylib 0x00007ff81b92fe25 objc_exception_throw + 48
2 Foundation 0x00007ff81cc88dc0 -[NSCalendarDate initWithCoder:] + 0
3 AppKit 0x00007ff81eead4c0 -[NSMenu insertItem:atIndex:] + 823
4 XojoFramework 0x0000000110d13f2e _ZN14CocoaPopupMenu10InsertItemEi6stringPv + 148
5 XojoFramework 0x0000000110e74265 RuntimeComboBoxInsertRow + 79
6 test.debug 0x000000010fe322b5 DesktopPopupMenu.AddRowAt%%oi8s + 53
7 test.debug 0x000000010fee93e4 Window1.Window1.PopupMenu1_Opening%%o<Window1.Window1>o + 564
8 test.debug 0x000000010feec064 Delegate.IM_Invoke%%o + 52
9 test.debug 0x000000010feec0b4 AddHandler.Stub.2%% + 52
10 XojoFramework 0x0000000110ed96cd FireWindowOpenEvents + 258
11 test.debug 0x000000010fe4905c DesktopWindow.Constructor%%o + 60
12 test.debug 0x000000010feebe1d Window1.Window1%o<Window1.Window1>% + 589
13 test.debug 0x000000010fef19ea _MakeDefaultView + 106
14 test.debug 0x000000010fef1c5f _LateStartup + 79
15 XojoFramework 0x0000000110d3e757 _Z29CocoaFinishApplicationStartupv + 199
16 XojoFramework 0x0000000110d3d3d4 _Z27PluginGetCocoaViewCallbacksv + 1025
17 CoreFoundation 0x00007ff81bd603d4 CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 137
18 CoreFoundation 0x00007ff81bdfa41a ___CFXRegistrationPost_block_invoke + 88
19 CoreFoundation 0x00007ff81bdfa369 _CFXRegistrationPost + 536
20 CoreFoundation 0x00007ff81bd338f9 _CFXNotificationPost + 735
21 Foundation 0x00007ff81cb6fabc -[NSNotificationCenter postNotificationName:object:userInfo:] + 82
22 AppKit 0x00007ff81eec1034 -[NSApplication _postDidFinishNotification] + 305
23 AppKit 0x00007ff81eec0d86 -[NSApplication _sendFinishLaunchingNotification] + 208
24 AppKit 0x00007ff81eeb96ef _DPSNextEvent + 1929
25 AppKit 0x00007ff81eeb8174 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1219
26 XojoFramework 0x0000000110d3ef96 _Z29CocoaFinishApplicationStartupv + 2310
27 XojoFramework 0x0000000110d3efda _Z29CocoaFinishApplicationStartupv + 2378
28 test.debug 0x000000010fe12af5 DesktopApplication._CallFunctionWithExceptionHandling%%op + 181
29 XojoFramework 0x0000000110ec51a3 _Z33CallFunctionWithExceptionHandlingPFvvE + 254
30 XojoFramework 0x0000000110d3ef4c _Z29CocoaFinishApplicationStartupv + 2236
31 AppKit 0x00007ff81eeaa7b7 -[NSApplication run] + 586
32 XojoFramework 0x0000000110ec3ac9 RuntimeRun + 44
33 test.debug 0x000000010fe56653 REALbasic._RuntimeRun + 19
34 test.debug 0x000000010fef200e _Main + 846
35 test.debug 0x000000010fef1433 main + 19
36 dyld

2 Likes

Well, so there’s a Xojo bug. Xojo should detect the out of range condition and raise the proper trappable exception.

1 Like

Agree, it was being masked by the change in NSApplicationCrashOnExceptions behavior.

@Beatrix_Willius : I’m guessing that because you are using a generic bundle identifier (com.mycompany.test) you accidentally had set NSApplicationCrashOnExceptions to True, perhaps in another test app using this same Bundle ID?