Ventura 13.2 (a) (22D7750270d) crashes Xojo

In the past the function Gestalt() was used to get the system version, I may have some legacy code using it here. But such function was tied to the Carbon Framework. Apple marked it to be removed. Probably it is removed by now and using it will break old apps. Xojo should be using some legacy code needing update too and now Apple removed the bridge Xojo was using. Once broken, Xojo updated it… but just the iOS part, maybe.

The current way uses APIs found here: Apple Developer Documentation

That by the way already have its portion of deprecations:

func operatingSystem() -> Int

Returns a constant to indicate the operating system on which the process is executing.

Deprecated

func operatingSystemName() -> String

Returns a string containing the name of the operating system on which the process is executing.

Deprecated

Could someone who’s having the crash try the following code and see what the value of versString is?

Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As ptr
Declare Function processInfo Lib "Foundation" Selector "processInfo" (obj As ptr) As ptr
Declare Function operatingSystemVersionString Lib "Foundation" Selector "operatingSystemVersionString" (obj As ptr) As CFStringRef

Dim NSProcInfo As ptr = processInfo(NSClassFromString("NSProcessInfo"))

Dim versString As String = operatingSystemVersionString(NSProcInfo)

Break
3 Likes

I hope Xojo is not trying to do what Apple said “don’t do it”.

2 Likes

To read the version parts I see:



image

Norman said as much on the other board, I don’t think it’s a great idea to push Greg away because he has rare insight as to how things were actually built. I appreciate that he shared the code the framework uses.

1 Like

You take things too personally. I’m not saying one word involving Greg. And still want his experiment being tested, and he also did not say his experiment is the code the framework uses, maybe he is curious to see what it returns, as I am too.

But… there’s no gain to the community if I stay quiet without sharing important information too.

2 Likes

I have an insight. After the security patch the Ventura 13.2.0 gains an “(a)”, maybe such string now have 2 contents in parenthesis, that (a) and the build (number), and if Xojo is trying to parse it, there’s some confusion with those 2 sets. I’m also afraid that as this string is localized, those dots, or worse, the numbers, may also be changed to another equivalent chars for such language.

Well, I’ve fixed my own apps, if not Xojo itself.

To get the system information on Mac, in my projects, for some time I have been running “sw_vers” in a shell. For years it has returned this, with the only difference being that, pre-Big Sur, it would report “Mac OS X” instead of “macOS”:

ProductName: macOS
ProductVersion: 13.1
BuildVersion: 22C65

In 13.2, after the security update, we get:

ProductName: macOS
ProductVersion: 13.2
ProductVersionExtra: (a)
BuildVersion: 22D7750270d

We have the new “ProductVersionExtra” line. And this is where I threw my out-of-bounds. My code was doing Array.Split on these lines, using colon+tab (“:”+chr(9)) as the separator, then reading the (1) element of the array. I guess there is no tab in this line. Anyway, changing the separator to a simple colon got me back in business. As for whitespace (the reason I’d included the tab in the separator way back when), since Ventura I’d had to trim the strings anyway.

Hopefully it’s this easy for Xojo.

1 Like

As you have access to the problem, can you run Greg’s test?

Declare Function NSClassFromString Lib "Foundation" (name As CFStringRef) As ptr
Declare Function processInfo Lib "Foundation" Selector "processInfo" (obj As ptr) As ptr
Declare Function operatingSystemVersionString Lib "Foundation" Selector "operatingSystemVersionString" (obj As ptr) As CFStringRef

Dim NSProcInfo As ptr = processInfo(NSClassFromString("NSProcessInfo"))

Dim versString As String = operatingSystemVersionString(NSProcInfo)

// show us versString content, please

Break

Indeed I can, and just did. I presume this is a good result. :slight_smile:

Version 13.2 (a) (Build 22D7750270d)

2 Likes

So System.VersionData should read and cache the operatingSystemVersion 3 integers and set System.VersionData.BuildVersion = 0 as MacOS only have the major, minor and patch numbers, and also read and cache the string operatingSystemVersionString as is, and the System.Version.ToString() should return that cached value without trying to parse it, let the user take care of the contents as Apple intended.

That’s a nice idea except that what we’ve found here is that when Apple does their new security updates there’s a new “a” version. And the Build version (in this case 22D7750270d) is very helpful in figuring out whether a user is using a particular buggy version of macOS as well.

Look guys we can debate this all you want, but the reality is that there is a bug here and I think we’ve given the engineers enough information to track down the problem and fix it. It’s the weekend right now though and I’m sure they’ll look at it.

5 Likes

This code works.
Text is now “Version 13.2 (a) (Build 22D7750270d)” and probably parsing this causes an error.

Query the number properties if you need numbers and otherwise just pass through the text for a human to read. Don’t try to parse it.

Works fine with Xcode:


> var systemVersion = NSProcessInfo.processInfo().operatingSystemVersion

No crashing.

1 Like

My contribute, a fresh copy of macOS 13.2 and clean Xojo 2022r4. result in a crash at startup :

demo@iMac2-Dev ~ % /Applications/Xojo\ 2022\ Release\ 4/Xojo.app/Contents/MacOS/Xojo

objc[2691]: Class REALSearchField is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/libSearchControl.dylib (0x10cc51108) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBSearchField.xojo_plugin/RBSearchField/Build Resources/Mac Universal/libSearchControl.dylib (0x12a1e9108). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJSegmentedControl is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/GUIKitCocoa.dylib (0x10cc7c390) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBGUIKit.xojo_plugin/RBGUIKit/Build Resources/Mac Universal/GUIKitCocoa.dylib (0x12a40c390). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJGUIKit_ActionTarget is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/GUIKitCocoa.dylib (0x10cc7c408) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBGUIKit.xojo_plugin/RBGUIKit/Build Resources/Mac Universal/GUIKitCocoa.dylib (0x12a40c408). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJWebKitDelegate is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/HTMLViewerCocoa.dylib (0x10cc20c30) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBHTMLViewer.xojo_plugin/RBHTMLViewer/Build Resources/Mac Universal/HTMLViewerCocoa.dylib (0x12a74cc30). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJBevelButton is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/AppearancePakCocoa.dylib (0x11072c8f0) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBAppearancePak.xojo_plugin/RBAppearancePak/Build Resources/Mac Universal/AppearancePakCocoa.dylib (0x12a71c8f0). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJImageWell is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/AppearancePakCocoa.dylib (0x11072c940) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBAppearancePak.xojo_plugin/RBAppearancePak/Build Resources/Mac Universal/AppearancePakCocoa.dylib (0x12a71c940). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJChasingArrows is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/AppearancePakCocoa.dylib (0x11072c990) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBAppearancePak.xojo_plugin/RBAppearancePak/Build Resources/Mac Universal/AppearancePakCocoa.dylib (0x12a71c990). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJDisclosureTriangle is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/AppearancePakCocoa.dylib (0x11072c9e0) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBAppearancePak.xojo_plugin/RBAppearancePak/Build Resources/Mac Universal/AppearancePakCocoa.dylib (0x12a71c9e0). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJLittleArrows is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/AppearancePakCocoa.dylib (0x11072ca30) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBAppearancePak.xojo_plugin/RBAppearancePak/Build Resources/Mac Universal/AppearancePakCocoa.dylib (0x12a71ca30). One of the two will be used. Which one is undefined.

objc[2691]: Class XOJSeparator is implemented in both /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Frameworks/AppearancePakCocoa.dylib (0x11072ca80) and /Applications/Xojo 2022 Release 4/Xojo.app/Contents/Resources/Internal Plugins/RBAppearancePak.xojo_plugin/RBAppearancePak/Build Resources/Mac Universal/AppearancePakCocoa.dylib (0x12a71ca80). One of the two will be used. Which one is undefined.

demo@iMac2-Dev ~ %

You can ignore those warnings about duplicate classes.
That happens because a plugin is loaded twice with registering the same class in both automatically.

1 Like

Exactly as I said.

2 Likes

So, it turns out I was right: Crash is caused by stupidly written code that relies on scanning textual data (which, in fact is meant for DISPLAY to the user, not to give a program the information it wants to make decisions on - just as the documentation says, as Rick points out).

The right way would have been to use the other functions that return the version information as distinct values. That’s something a programmer working for a commercial product should understand without explaining.

StackOverflow and many other sites had given suggestions how to do that right after Gestalt stopped working (which REALbasic used to use back then): Initially by reading the SystemVersion.plist file, later by using the NSProcessInfo functions. When I googled for the problem, Google’s top result was this, with the correct answer, from 2014 (and a hidden one from 2012 about using the plist when the new function wasn’t available yet, which was clearly a stupid oversight from Apple): https://stackoverflow.com/questions/11072804

6 Likes

I agree 100%. That’s plain stupid to do if there are other (read: correct) ways to get the version.
It’s a miracle that it only breaks the code now.

Of course for Xojo Inc this could be a blessing. Everyone needs a current license to use the up comming fix release. :smirk:

1 Like

Or one could run a 2019 release. :wink: