-
Notifications
You must be signed in to change notification settings - Fork 554
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
crash report on abort in AudioStreamAAudio::onErrorInThread #519
Comments
Yes, this can happen if the stream is already closed. @philburk Could we do something better than use an assert here: oboe/src/aaudio/AudioStreamAAudio.cpp Line 270 in f4c4f4e
|
Hi Phil, I realize that when the stream is closed due to an error like unplugging the device, that the app has to take action ( close the audio handling , give a message maybe even switch to another audio device ). |
Yes, at:
It should not call close because it has already been closed. |
I was about to report the issue which I believe could be the same as this one.
An example of last log lines we see in these reports:
These are messages we added in our error callbacks to be get some more info. We will have more crash reports soon and more logs - so hopefully that should provide better picture on what's happening. I tried analysing the code and maybe - the use case when this crash may happen could be the one I described in the following comment: #524 (comment) |
Are you restarting the stream from the onErrorAfterClose call back?
In that call back are you deleting the old stream? If so that could be a
problem because you're being called from that stream.
|
We restart the stream in
Maybe I am missing something - apologies if that's the case. Also having in mind async nature of error handling - when is a good time to delete oboe stream if needed after step 2 mentioned above - and how we could be sure that stream we are deleting isn't used by oboe error handling logic i.e in step 4? |
Could |
The issue b/63087953 involving two onError callbacks occurring was supposedly fixed in 8.1. But it still may be happening. That could account for this error: A - AAudio calls error callback launches handling thread "C" I will prevent that race by blocking the handling of the second callback B. |
There was a race that could be caused by multiple onErrorCallbacks. There should only be one callback. We now check to make sure that only the first callback is handled. Fixes #519
I have noticed a crash report on our App from google play store, that reports an abort in
AudioStreamAAudio::onErrorInThread. ( Huawei HUAWEI Y9 2019 (HWJKM-H), Android 8.1)
due to the
assert(stream == mAAudioStream.load());
I suppose this is due to some Thread timing or not locked issue ( stream already closed before..) ?
but isn't there a none crashing way to deal with this in the mean time ?
The text was updated successfully, but these errors were encountered: