Crash in AudioStreamAAudio::read about oboe HOT 8 OPEN

I notice from the crash dump that the output callback is using Legacy mode and the input read() is using MMAP.
That situation may be more common on the MT6833.

There could also be timing differences that cause race conditions.

Are you using a shared_ptr for your stream variables?

That can help prevent some use-after-free bugs.

from oboe.

Do you think this could be happening when the user plugs in or unplugs a headset?

from oboe.

It is hard to tell if there is any headset connection change just with the stack trace. We used to have an old bug b/220061515 reporting a similar crash with sound amplifier on android S. It is closed due to no longer reproduced. That may be the same root cause while the issue is not really fixed. I will take a look.

from oboe.

Looking more into the code, it looks like this could be caused by the audio stream is freed when the data callback is fired. In aaudio, the audio stream is held by the clients. @sonicdebris, could you please share if you are using a shared pointer for your stream variables as Phil mentioned above? It will also be good to know if you will free the stream immediately when receiving disconnect error.

from oboe.

Hello, sorry for the delay in the response.

We are using shared pointers for the streams, and using AudioStreamBuilder::openStream to set them up.

We handle stream errors by implementing AudioStreamErrorCallback::onError(), where we stop and close the stream (and reset the pointer).

We protect all accesses to the stream with a mutex, and in the audio callback we do a try-lock, followed by a null-check on the stream pointer, so the audio callback will just do nothing in case some other function is messing with the stream or has reset the pointer.

I might add that we have the same issue reported on crashlytics, where we log when onError is called and also when audio route changes happen (we listen to such events on the jvm side by using AudioManager.registerAudioDeviceCallback), but in the logs associated to the crashes we don't see any such events related to stream errors or route changes.

from oboe.

@sonicdebris - you wrote:

We handle stream errors by implementing AudioStreamErrorCallback::onError(), where we stop and close the stream (and reset the pointer).

Do you return true from your onError() call? If you return false then Oboe might close the stream again!

from oboe.

Yes, we do return true

from oboe.

The reason you see more crashes on MTK6833 may be because Mediatek may have set compiler options that are detecting numeric overflows. Or there may be lower memory on those devices.

from oboe.