Open dfandrich opened 1 year ago
Sure enough, it is related to audio. A few other apps run around the same time of these crashes failed to play their audio, indicating that something was wrong with Android/Linux' audio subsystem. After running a few apps to try to test the audio, audio just suddenly started working fine, and Open Golf then started running.
I'm guessing that the root problem is that Open Golf is not checking an error code while initializing audio somewhere and is then crashing on a bad pointer.
The call to saudio_setup() in golf_audio_init() is not followed by a call to saudio_isvalid(), to check that audio is actually available, however, the documentation says missing that call shouldn't hurt. It would be handy to have a log message if !saudio_isvalid(). Also, the crash is happening before saudio_setup() even returns. I don't see any obvious NULL pointer references in saudio_setup() but maybe the compiler has inlined some other functions. Is the program simply failing a SOKOL_ASSERT? I would expect a cleaner exit in that case, though.
I found some suspicious code in _saudio_backend_init(), though. Most of the OpenSLES calls have their return codes checked, but the ones starting in the / setup player / section to the end of the function do not. If (*_saudio.backend.engine)->CreateAudioPlayer fails, then _saudio.backend.player_obj would remain NULL and the subsequent calls would dereference a NULL pointer. I suspect this is the issue.
Launching the app (the 1.0 version from F-Droid) on an armv7l LineageOS 14.1 (Android 7.1.2) device results in an immediate SIGSEGV with only the Android crash dialog being displayed. The backtrace implies it might be some kind of audio issue.