1bsyl
commented
1 year ago @AntTheAlchemist are you also seeing this one ?
Closed 1bsyl closed 1 year ago
1bsyl
commented
1 year ago @AntTheAlchemist are you also seeing this one ?
1bsyl
commented
1 year ago not to destroy the mutex, seems the easiest fix! other solution, we would to double protect SDL_JoystickLock() and Unlock(), with also locking Android_ActivityMutex ...
slouken
commented
1 year ago We should be protected against the case where the mutex is currently being held. It's supposed to destroy itself on the last unlock. Please back out your last change and let's figure out why this is happening?
1bsyl
commented
1 year ago yes, maybe:
void SDL_LockJoysticks(void)
{
SDL_LockMutex(SDL_joystick_lock);
++SDL_joysticks_locked;should be
void SDL_LockJoysticks(void)
{
++SDL_joysticks_locked;
SDL_LockMutex(SDL_joystick_lock);and also for Unlock
void SDL_UnlockJoysticks(void)
{
SDL_UnlockMutex(SDL_joystick_lock);
--SDL_joysticks_locked;but there still could be a lock done just before SDL_DestroyMutex() ... so don't know
slouken
commented
1 year ago Yeah, there's a huge set of race conditions here. Hmm...
slouken
commented
1 year ago Okay, I have a fix that should work. It's not 100% perfect, but it minimizes the window where it could happen to a task switch between exactly two instructions.
AntTheAlchemist
commented
1 year ago @1bsyl As a crash, no. I've had 1 Joystick related crash in the last 60 days, on a phone: [split_config.arm64_v8a.apk!libSDL3.so] HIDAPI_JoystickClose. My app will exit on PadUp(), though. All actions happen on a button release.
I am getting hundreds of SDL_LockMutex ANRs though, did you mean ANRs or crashes? There are many variations. Here's a few samples of this type of ANR which is specifically happening on TV devices (interesting to note that Google Play Console reports most of these happening with background visibility):
[split_config.armeabi_v7a.apk!libSDL3.so] SDL_LockMutex
AntTheAlchemist
commented
1 year ago The collapsible blocks didn't come out at all well, sorry. I added backticks and it made it worse, how can I add summery text with code content?
slouken
commented
1 year ago @AntTheAlchemist, can you create a new issue for these, so they don't get lost in the closed bug report?
madebr
commented
1 year ago The collapsible blocks didn't come out at all well, sorry. I added backticks and it made it worse, how can I add summery text with code content?
You need to add an empty line after </summary> and before the final </details>.
It's a quirk of GitHub's markdown parser, I guess.
AntTheAlchemist
commented
1 year ago You need to add an empty line after
</summary>and before the final</details>.
@madebr thank-you, that's good to know. Thanks for fixing my post.
@AntTheAlchemist, can you create a new issue for these, so they don't get lost in the closed bug report?
@slouken Yes, absolutely. Let me fist try out the very latest SDL3 source in a live test to see how well the recent fixes work, so I can come back with a fresh report. @1bsyl is waiting on some fresh logs as well. I won't forget. I have a bunch of other ANRs and Crashes I'll report in new issues soon - just want to make sure I can make them as useful as possible first.
1bsyl
commented
1 year ago first log: 1/ SDLActivity seems to be waiting for the JoystickLock (in OnPadUp) Since it's waiting for the lock, it must have been created first. So SDLThread was existing. But there are no SDLThread. So did it exit without releasing the JoystickLock() ? Eg C main() quits without calling SDL_JoystickUnlock() ? check you code to see you have all the necessary SDL_JoystickUnlock() in all situations ?
second log: This crash looks strange. because there should be only 1 SDLThread. but there are tid=15 and tid=463.
SDLActivity is also waiting for the JoystickLock but in OnPadDown().
SDLThread tid=15 is waiting in UsbManager.getDeviceList() called at org.libsdl.app.HIDDeviceManager.initializeUSB (HIDDeviceManager.java:45) at org.libsdl.app.HIDDeviceManager.initialize (HIDDeviceManager.java:45)
This sounds something done at start of the app. Probably it has taken the JoystickLock somewhere for initialization, so this sounds fine that SDLActivity is waiting. But maybe UsbManager.getDeviceList() just hangs, eg android bug (IPCThreadState::talkWithDriver && waitForResponse) ? or is waiting for a permission ? So the SDLThread blocks directly at starts and then blocks the Activity.
SDLThread tid=463 no idea what it is doing :/ stack trace doesn't look like SDL. (--> I suggested to temporary append a timestamp to the SDLThread string name, just to see if we get 2 different names) Who's created it ? SDLActivity before being blocked ? can have it been re-created because SDLThread=15 was hanged ? could be a warm start, and we re-create the SDLThread, but then, why, don't we have the normal SDL stack trace starting from java.lang.Thread.run ?
I've seen this rare crash log:
This seems to happen on tv / set-top box. Possible scenario: user press a key to exit, things get terminated on key PadDown(). But the key PadUp() is also sent right after and tries to lock the joystick mutex. The un-initialization process from PadDown event unlocks and destroys the mutex (https://github.com/libsdl-org/SDL/blob/main/src/joystick/SDL_joystick.c#L155), which triggers the 'pthread_mutex_lock called on a destroyed mutex" while sending the PadUp()