onAudioReady with invalid arguments

[taemincho]

Android version(s): 9, 10, 11, 12
Android device(s): Samsung, Xiaomi, LGE, and others but no Pixel
Oboe version: 1.6-stable
App name used for testing:
(Please try to reproduce the issue using the OboeTester or an Oboe sample.)

Short description
(Please only report one bug per Issue. Do not combine multiple bugs.)

Steps to reproduce

Expected behavior

Actual behavior

Device

Any additional context

Last year, we found that a segfault occurred during onAudioReady of the output stream, so we've added
the code below at the very beginning of onAudioReady to detect what caused the segfault.

oboe::DataCallbackResult onAudioReady(oboe::AudioStream *oboeStream, void *audioData, int32_t numFrames) {
    auto audioFormat = oboeStream->getFormat();  // SIGSEGV 0x0000000000000028 at here
    int numOutCh = oboeStream->getChannelCount();
    int outSampleBytes = audioFormat == oboe::AudioFormat::I16 ? sizeof(short) : sizeof(float);
    memset(audioData, 0, outSampleBytes * numOutCh * numFrames);  // or SIGSEGV at here

And we found that SIGSEGV occurs at oboeStream->getFormat() or the memset statements.
In other words, oboeStream or audioData or both were invalidated somehow.

We could see that the audio route was changed before crashing.

FYI:
This is our 2nd most common crash from Oboe, the most common crash has been reported in #1484

[philburk]

@taemincho - Thanks for reporting this. It looks like the oboeStream parameter is NULL but it is passed as "this" in AudioStream::fireDataCallback(). And we check for nullptr in oboe_aaudio_data_callback_proc. So this is very puzzling.

Are you able to duplicate this in your office? Or is it only in the field?

Do you have a more complete stack trace? or a bugreport?

Do you know if these devices are using OpenSL ES, or MMAP / Legacy AAudio?

[taemincho]

@philburk

Are you able to duplicate this in your office? Or is it only in the field?

No, unfortunately, this is our second most common crash from Oboe but actually, it's quite rare.

Do you have a more complete stack trace? or a bugreport?

Not much information from stack traces. Below are stack traces we've got from Crashlytics

Crashed: Thread :  SIGSEGV  0x0000007ce60387b8
#00 pc 0x4bf84 libc.so 
#01 pc 0x2c6aec libbandlab_audio_engine.so (AudioOutputDevice_Oboe::onAudioReady(oboe::AudioStream*, void*, int) [string.h:153])
#02 pc 0x36074c libbandlab_audio_engine.so (oboe::AudioStream::fireDataCallback(void*, int) [AudioStream.cpp:63])
#03 pc 0x35f2b8 libbandlab_audio_engine.so (oboe::AudioStreamAAudio::callOnAudioReady(AAudioStreamStruct*, void*, int) [AudioStreamAAudio.cpp:374])
#04 pc 0x22330 libaaudio_internal.so 
#05 pc 0x24858 libaaudio_internal.so 
#06 pc 0x24dec libaaudio_internal.so 
#07 pc 0x8b1dc libaudioclient.so 
#08 pc 0x8a4e8 libaudioclient.so 
#09 pc 0x12304 libutils.so 
#10 pc 0xbb59c libandroid_runtime.so 
#11 pc 0x11acc libutils.so 
#12 pc 0xb3458 libc.so 
#13 pc 0x517c8 libc.so 

Crashed: Thread :  SIGSEGV  0x0000000000000028
#00 pc 0x1fd3e8 libbandlab_audio_engine.so (AudioOutputDevice_Oboe::onAudioReady(oboe::AudioStream*, void*, int) [AudioStreamBase.h:78])
#01 pc 0xbb25a libc.so 

Do you know if these devices are using OpenSL ES, or MMAP / Legacy AAudio?

AAudio,
We didn't log MMAP, so don't know about other devices, but we disabled MMAP on all the Samsung devices.

[philburk]

We have made changes in AudioTrack.cpp to try to prevent callbacks from running while the track is being closed.
We think this may be the source of these corrupt pointers.

All I can recommend at the moment is to lengthen a sleep between stop and close, which is controlled by this constant.

oboe/src/aaudio/AudioStreamAAudio.h

Line 122 in 8ff99cc

static constexpr int kDelayBeforeCloseMillis = 10;

We have an Issue, #1500, to make this controllable through the API.

[philburk]

We are closing because there is nothing more we can offer on this bug. If you have more information, please let us know.