I might actually know what the issue is. I tried the test with #296 a couple hours ago and have seen where it crashes on Windows. Attempting to put something together as a test.
Seems to have survived over 25 minutes so far, versus maybe 3 or 4 before. These are my changes: diff
The Windows crashes were happening in the keepAlive() branch of Scheduler::Run(), but the memory values of the task, t, looked like uninitialized or deinitialized memory. I then noticed the (separate) audio thread was just launching the tasks blindly, so it obviously did an Append() during a Run().
This adds a couple mutexes to address this, at least as far as the scheduler seems to be actually used. I’ll try to add some commentary in #296 as well, in the next day or two.
Update: started it and played a game while I let it run. Came back after a couple hours and it hadn’t crashed. Making a PR.
This would be amazing if a solution could be found for this bug.
I never use onComplete() yet it’s the number 1 crash I have on Android.
Update: Released an update with build 3701 and I’m still seeing crash reports due to this 
Doesn’t seem any better/worse in my case.
Edit, looking at it some more. I think my crash is slightly different. The one on GitHub mentions
signal 11 (SIGSEGV)
ALmixerSoundCompletionEvent()
My crash is with
SIGABRT
Scudo ERROR: invalid chunk state when deallocating address
PlatformALmixerPlaybackFinishedCallback()
I don’t even use any audio finished callbacks which is the weird thing. Never have. And I’ve been getting these crashes for a very long time while only using basic audio.play() stuff.
Relevant for my crash (taken from the stack trace):
/split_config.arm64_v8a.apk!libcorona.so (Rtt::BaseResourceHandle::~BaseResourceHandle()+103)
/split_config.arm64_v8a.apk!libcorona.so (Rtt::PlatformALmixerPlaybackFinishedCallback::~PlatformALmixerPlaybackFinishedCallback()+139)
/split_config.arm64_v8a.apk!libcorona.so (Rtt::PlatformOpenALPlayer::NotificationCallback(int, unsigned int, ALmixer_Data*, bool)+1101)
Hope that helps in some way for the next person that reads this thread.
Do your older crashes look the same, or are those like the GitHub one? (Since your previous post mentioned onComplete() itself.) I’ll look into PlatformALmixerPlaybackFinishedCallback().
As I also mentioned to @naveen_pcs in DMs, I’ve looked this over this afternoon.
I’m still hopeful about the onComplete fix, though I do see room for a couple improvements. As for the error mentioned above, there are some additional synchronization issues that I flushed out (that ~BaseResourceHandle one in particular), and I’ll see about listing them in the PR. It really looks like it could just use a refactor; I don’t think the offending bits even need to be there.
Update: I found a few additional synchronization issues and tried to address those as well. Test build available here and debug symbols.
It sounds like you’ve made some important changes to address stability issues. By adding mutexes to the scheduler, you’ve likely resolved the concurrency problem that was causing crashes, especially with task management and the interaction between the audio thread and the scheduler. It’s great that the system is now running for a longer duration without crashes. Adding more commentary in #296 will help provide clarity for others on the reasoning behind these changes. Keep up the good work!