Total Phase UI Apps crashing with a bus error on Sonoma Build

The info has also bee uploaded via macOS Feedback Assistant with ref Case ID FB13260830

Total Phase Applications crash with bus error upon execution on macOS Sonoma:

Are you the developer of these apps?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

FYI, if you reply in the comments I’m not notified. See tip 5 in Quinn’s Top Ten DevForums Tips.

Do you have a list of changes between Monterey and Sonoma in IOKit?

No. In any given major OS release there are so many changes that building such a list is infeasible. Some of the most important things get highlighted in the macOS Release Notes.

They are compiled for Intel x86_64.

Is it crashing on Apple silicon? Or Intel? Or on both?

Can you post an example crash report? See Posting a Crash Report for advice on how to do that.

IMPORTANT Ideally that’d be a crash report from an Intel machine. That cuts Rosetta out of the equation.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi Quinn, thanks for your help with this. We'll send you an email with the logs.

Consider this:

Application Specific Information:
CoreFoundation: CF objects must have a non-zero isa

You get this crash when you pass something that’s not a CF object to a CF routine that’s expecting a CF object. The backtrace of your crash looks like this:

0 com.apple.CoreFoundation  0x7ff80c885f70 CF_IS_OBJC.cold.1 + 14 …
1 com.apple.CoreFoundation  0x7ff80c7f99b4 CF_IS_OBJC + 60 …
2 com.apple.CoreFoundation  0x7ff80c6c15a8 _CFStringGetCStringPtrInternal + 80 …
3 com.apple.framework.IOKit 0x7ff80fbd30f0 IORegistryEntrySearchCFProperty + 76 …
4                             0x10240ff71

Your code, in frame 4, has called IORegistryEntrySearchCFProperty which is trying to render one of the supplied parameters, probably key, to a C string. That parameter isn’t a CFString and so you’ve crashed.

Consider this deliberately bogus test program:

@import Foundation;
@import IOKit;

int main(int argc, char **argv) {
    CFStringRef key = (CFStringRef) calloc(1, 1024);
    io_registry_entry_t root = IORegistryGetRootEntry(kIOMainPortDefault);
    CFTypeRef result = IORegistryEntrySearchCFProperty(
        root,
        kIOServicePlane,
        key,
        NULL,
        0
    );
    NSLog(@"result: %@", result);
    return EXIT_SUCCESS;
}

On macOS 13 it prints nothing. On macOS 14 it crashes, with a crash report that exactly matches frames 3 through 0 of your crash report. This change of behaviour was deliberate. We added extra hardening to Core Foundation in macOS 14 to catch programming errors like this one.

The lack of symbolication in your crash report makes it hard to tell why your program is passing a bogus object to IORegistryEntrySearchCFProperty. However, the path forward here is clear: You need to uncover the identity of the code in frame 4 and fix it.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi @eskimo,

Thank you for your time and elaboration on this ticket. Your investigations have helped us move forward.

The shared cfstring_isa.c code (below) shows the working and crashing behavior on both x86_64 and ARM64.

We are working on applying the updates suggested to our UI code, to make them compatible with Sonoma. Once again a big thanks for all the effort put in from your end.

//
// Compile with:
//
// clang --target=x86_64-darwin-macos11 -o cfstring_isa_x86 cfstring_isa.c -framework CoreFoundation
// clang --target=arm64-darwin-macos11  -o cfstring_isa_arm cfstring_isa.c -framework CoreFoundation
//

#include <stdint.h>
#include <stdio.h>
#include <CoreFoundation/CFString.h>

struct ConstString
{
    void    *isa;
    int32_t  value;
    int32_t  unused;
    char    *asciiz;
    size_t   length;
} __attribute__((packed));

void ClassReference() asm("___CFConstantStringClassReference");

const struct ConstString Hello = {
    .isa    = ClassReference,
    .value  = 1992,
    .unused = 0,
    .asciiz = "Hello",
    .length = 5,
};

const struct ConstString World = {
    .isa    = 0,
    .value  = 1992,
    .unused = 0,
    .asciiz = "World",
    .length = 5,
};

int main (int argc, char *argv[]) {
    CFStringRef hello = (void *)&Hello;
    CFStringRef world = (void *)&World;

    printf("Works on Sonoma:\n");
    printf("%s\n", CFStringGetCStringPtr(hello, kCFStringEncodingMacRoman));

    printf("\n");

    printf("Works on Ventura, crashes on Sonoma:\n");
    printf("%s\n", CFStringGetCStringPtr(world, kCFStringEncodingMacRoman));

    printf("\n");

    return 0;
}

I’m not surprised this is crashing. You can’t construct constant CFString values in this way. These structures are implementation details of CF, not API.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi @eskimo ,

The posted code is only an example to illustrate the behavior. We are not writing code like this by hand. These low-level binary structures come from a compiler in our toolchain.

Clang generates structures that are identical to "Hello" through the built-in function _builtin__CFStringMakeConstantString(), referenced from the CFSTR() macro. The CFString structure must be a stable ABI since compiled binaries are compatible with any version of CoreFoundation.

Since macOS versions prior to Sonoma accepted a 0 value in the isa field, we had no indication that the structure was different than Clang's output. We have resolved this and will be releasing updated software.

Thanks again for your help in identifying the issue.

These low-level binary structures come from a compiler in our toolchain.

An Apple compiler? Or a compiler you built for yourself?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi @eskimo

It's a compiler that we built for our toolchain. We fixed it and released updated versions of our apps.