macOS: cubeb_enumerate_devices seems to crash when airpods are "disconnected"

[Megamouse]

A user reported that the application crashes when they takes off their airpods while the device is selected as default device. I tracked this down to cubeb_enumerate_devices.

In particular, we try to reconnect a new default device in the device_collection_changed_cb. EDIT: the default device is connected and a stream is open before the airpods are taken off

So here's a snippet:

void MyClass::init()
{
    if (int err = cubeb_init(&m_context, "MyContext", nullptr))
    {
        printf("Error in cubeb_init\n");
        return;
    }

    if (int err = cubeb_register_device_collection_changed(m_context, CUBEB_DEVICE_TYPE_OUTPUT, device_collection_changed_cb, this))
    {
        printf("Error in cubeb_register_device_collection_changed\n");
        return;
    }
}

void MyClass::device_collection_changed_cb(cubeb* context, void* user_ptr)
{
    if (context == nullptr) return;

    cubeb_device_collection collection{};

    printf("Begin enumeration\n"); // THIS WAS THE LAST LOG MESSAGE

    int err = cubeb_enumerate_devices(context, CUBEB_DEVICE_TYPE_OUTPUT, &collection);

    // THIS IS NEVER REACHED

    if (err != CUBEB_OK)
    {
        printf("Error in cubeb_enumerate_devices\n");
        return;
    }

    // Do other cool stuff
}

[padenot]

I can't reproduce this. Here's what I tried:

• Put the airpods in the ears, it's the default audio output device of the machine
• Open an output-only cubeb stream, with a device collection changed handler registered, and a cubeb_enumerate_devices(...) call in this callback (very much like in the snippet).
• While the stream is playing, remove the airpods from the ears. This does not trigger the device collection changed, but the audio now plays on the speakers.
• Put them in the case, this disconnects the airpods, the device collection changed callback is called, cubeb_enumerate_devices(...); is called.

This works as it should here on macOS 12.5. Maybe it would be possible to get stacks so we can figure out what's going on?

[mygizli04]

Hi, I'm the user which has the issue in the original post. I tested again on macOS 12.5.1 and the issue only occurs on macOS 13.0 beta. I'm not sure how to provide stacks, should I reproduce the crash on macOS 13 and post the "error report" here?

[padenot]

If you can attach a debugger, and reproduce the crash, it would be amazing, as I don't have macOS 13 beta yet on a machine. It would go like this:

• Get an rpcs build with symbols. Maybe @Megamouse knows what's the best way to get one, or can provide one (short of building it yourself)
• Open a terminal, ensure you have lldb. If not, you probably need to install xcode or xcode's additional tools (here I think: https://developer.apple.com/download/all/)
• When everything is running and you have the airpods in your ears with sound, find the PID of rpcs (probably pgrep rpcs or ps -ef | grep rpcs, second number from the left), and do the following: lldb -p <pid> where <pid> is the PID of rpcs
• Remove the airpods, put them in their case so that they're disconnected, normally at this moment the crash will occur, lldb will return to a command prompt
• Type bt all, attach here all the text that's output

[kinetiknz]

Invoking the cubeb APIs from within a cubeb callback is not safe in general, unfortunately. Some combinations of calls/backends may happen to work, but I'd recommend using the device_collection_changed_cb to signal some other thread to re-enumerate and handle any other stream configuration you need to do.