-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Mac OS] SDL2 applications crash if USB joystick attached (Speedlink Competition Pro) #12255
Comments
Are you able to git bisect it on the SDL2 branch? |
I guess I would need to keep trying different releases first to find out when it broke. So far all I've tried is 2.30.10, 2.32.0 and 2.0.20. I don't have time to look tonight but can try next week if nobody has tracked it down by then. |
Thanks! |
After trying various releases 2.26.5 is the last one that works so the bug seems to have been introduced in 2.27.1 |
@slouken I've managed to do a debug build using Xcode on the latest SDL2 branch. Does the following stack trace provide any clues? At least there are some line numbers now!
|
That crash is in Apple code, but I don't see any meaningful changes in the SDL GCController support between 2.26.5 and 2.28.0, so I'm not sure why the new code is crashing. Is this the controller you have? |
Yes, that's the controller. Thanks for looking. I guess it's some sort of memory corruption as occasionally my test app exits without crashing. |
Can you use address sanitizer to track it down? |
Thanks, I'll try and do that at the weekend. I normally develop on Linux so haven't done much debugging on a Mac. It looks similar to Valgrind. |
Address Sanitizer has found has found heap use after free which is probably the cause:
|
@slouken while obviously not the correct solution commenting out the following line in SDL_config_macosx.h does fix the problem for my joystick: #define SDL_JOYSTICK_HIDAPI 1 Building a release build with this config also stops MAME from crashing. Do you have any idea why the IOKIT driver is trying to use a pointer allocated and freed by the HIDAPI driver? |
SDL is registering a report callback for opened devices, and passing it a newly allocated Apparently what's happening is that a report is still queued somewhere and the unregistered callback gets called with the freed buffer anyway. I think this is a bug in Apple's framework, but I'm not sure. |
Out of curiosity, does this happen with SDL3 as well? Here's the SDL3 version of your example: #include <SDL3/SDL.h>
int main()
{
int num_joysticks;
std::cout << "Calling SDL_init\n";
if (!SDL_Init(SDL_INIT_JOYSTICK))
{
std::cout << "Could not initialize\n";
return 1;
}
else
{
std::cout << "init OK\n";
}
SDL_free(SDL_GetJoysticks(&num_joysticks));
if (num_joysticks == 0)
{
std::cout << "No joysticks found\n";
return 1;
}
std::cout << num_joysticks << " joysticks found" << std::endl;
return 0;
} |
I got the Speedlink Pro joystick and am able to reproduce this, and confirmed that it doesn't happen with SDL3. |
That's interesting, hopefully you can find some sort of work around now that you can reproduce it yourself. I'm away at the moment so didn't get a chance to try SDL3 myself. I did come to the same conclusion about the callback after stepping through with the debugger. |
Merged upstream fix for macOS: libusb/hidapi@cdc473d In one of the early versions of macOS, when you try to close the device with IOHIDDeviceClose() that is being physically disconnected. Starting with some version of macOS, this crash bug was fixed, and starting with macSO 10.15 the opposite effect took place: in some environments crash happens if IOHIDDeviceClose() is _not_ called. This patch is to keep a workaround for old versions of macOS, and don't have a leak in new/tested environments. Fixes #12255
Merged upstream fix for macOS: libusb/hidapi@cdc473d In one of the early versions of macOS, when you try to close the device with IOHIDDeviceClose() that is being physically disconnected. Starting with some version of macOS, this crash bug was fixed, and starting with macSO 10.15 the opposite effect took place: in some environments crash happens if IOHIDDeviceClose() is _not_ called. This patch is to keep a workaround for old versions of macOS, and don't have a leak in new/tested environments. Fixes #12255 (cherry picked from commit 5925c27)
Okay, it looks like this was fixed upstream, and I've merged that change to the SDL2 branch and cherry-picked it for the next release. Thanks for the excellent report! Please let me know if this doesn't resolve it for you. |
That's great news, thank you. I will check the next release. |
Merged upstream fix for macOS: libusb/hidapi@cdc473d In one of the early versions of macOS, when you try to close the device with IOHIDDeviceClose() that is being physically disconnected. Starting with some version of macOS, this crash bug was fixed, and starting with macSO 10.15 the opposite effect took place: in some environments crash happens if IOHIDDeviceClose() is _not_ called. This patch is to keep a workaround for old versions of macOS, and don't have a leak in new/tested environments. Fixes libsdl-org#12255 (cherry picked from commit 5925c27)
After upgrading to a new Mac Mini M4 I encountered segmentation faults running MAME with my Speedlink Competition Pro joystick attached. The same joystick worked fine with my Fedora Linux machine and old Intel Mac.
After some investigation I've pinned this down to SDL and the following simple test application exhibits the same behaviour using SDL2 version 2.32.0:
With the joystick attached it crashes inside SDL_Init() due to what looks like memory corruption.
I also found that the Amiga emulator FS-UAE works fine. As this is bundled with a much older framework I tried using SDL2 version 2.0.20. With this old version both my test application and MAME work fine. Therefore, this looks like a possible regression error, but I don't know when it was introduced.
Please see original MAME issue report from 2023:
mamedev/mame#11568
Here is my test application stack trace in case that helps:
The text was updated successfully, but these errors were encountered: