Crash at DataConversionFlowGraph::write()

[rpattabi]

Android version(s): 10
Android device(s):

• Samsung Galaxy M30 (m30lte)
• Motorola Moto G Turbo Edition (merlin)

Oboe version: master (commit ee39453)
App name used for testing: Shruti Carnatic Tuner v7.0.6 (partially rolled out. The other version in production does not use oboe.)

Our app uses input stream with callback. This is working fine on devices we tested. However, we saw this crash in our google play console for the mentioned device:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)

*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
pid: 0, tid: 0 >>> org.kuyil.shruti <<<

backtrace:
 
  #00  pc 00000000000769dc  /data/app/org.kuyil.shruti-Xqlk8QdCEu44HN3T7wT2bg==/lib/arm64/libpdnativeoboe.so (oboe::DataConversionFlowGraph::write(void*, int)+20)
  #01  pc 000000000006ee7c  /data/app/org.kuyil.shruti-Xqlk8QdCEu44HN3T7wT2bg==/lib/arm64/libpdnativeoboe.so (non-virtual thunk to oboe::FilterAudioStream::onAudioReady(oboe::AudioStream*, void*, int)+40)
  #02  pc 000000000006d2c0  /data/app/org.kuyil.shruti-Xqlk8QdCEu44HN3T7wT2bg==/lib/arm64/libpdnativeoboe.so (oboe::AudioStream::fireDataCallback(void*, int)+104)
  #03  pc 00000000000753cc  /data/app/org.kuyil.shruti-Xqlk8QdCEu44HN3T7wT2bg==/lib/arm64/libpdnativeoboe.so
  #04  pc 000000000001e6b0  /system/lib64/libaaudio.so (aaudio::AudioStream::maybeCallDataCallback(void*, int)+200)
  #05  pc 0000000000025028  /system/lib64/libaaudio.so (aaudio::AudioStreamLegacy::callDataCallbackFrames(unsigned char*, int)+308)
  #06  pc 00000000000256b8  /system/lib64/libaaudio.so (aaudio::AudioStreamLegacy::processCallbackCommon(int, void*)+1016)
  #07  pc 0000000000055278  /system/lib64/libaudioclient.so (android::AudioRecord::processAudioBuffer()+1328)
  #08  pc 0000000000054a58  /system/lib64/libaudioclient.so (android::AudioRecord::AudioRecordThread::threadLoop()+264)
  #09  pc 0000000000013618  /system/lib64/libutils.so (android::Thread::_threadLoop(void*)+316)
  #10  pc 00000000000ef900  /system/lib64/libandroid_runtime.so (android::AndroidRuntime::javaThreadShell(void*)+140)
  #11  pc 00000000000e2270  /apex/com.android.runtime/lib64/bionic/libc.so (__pthread_start(void*)+36)
  #12  pc 0000000000084ba0  /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread+64)

Look here for decoded stack trace with line numbers.

As this crash is from google play console, we don't have any other information. Let us know if you need anything specific about our use of oboe.

[philburk]

Thanks for the report. There have been some recent changes in the DataConversionFlowGraph. #1011
But I would not expect it to fail in only some devices.

@rpattabi - I assume you are setting a callback size. What value are you using?

Do you know if it happens when a headset is plugged in or unplugged?

This could be related to a timing issue involved with deleting a stream too close to the time it is closed.
That can behave differently on some devices. See #1017

[rpattabi]

I assume you are setting a callback size. What value are you using?

Yes, we're setting callback size. We're interfacing oboe with puredata (pd). Pd requires block size to be a multiple of 64. We use multiple (2 to 4) of frames per burst as callback size if they are multiples of 64. Otherwise, we choose a number that is divisible by 64 which is close to twice of frames per burst.

In this crash, we don't have information about the actual callback size, except that the logic used for its calculation is above.

Do you know if it happens when a headset is plugged in or unplugged?

Again, we're not sure of the state of connectivity in this case. As per the recommendation, we do handle onErrorAfterClose() which restarts the stream in case of ErrorDisconnected (which works fine on our devices). We understand, even after the recent fixes to oboe, it is still possible to have a race. In our app, the possibility of race is only there when the user leaves the app.

--

Today we saw another crash with the same call stack on this other device:

• Motorola Moto G Turbo Edition (merlin) - Android 10

(We also updated list of devices in this issue description)

--

Just wanted to add what our app does with audio streams: We create input stream with callback. Depending on user's actions, we also create an output stream with callback. Again, depending on user's actions, we stop one stream and start another stream. At any time, only one stream is in started state, and the other stream is kept in stopped state. Stream are closed when the user leaves the app.

--

We understand, with so little information, there is nothing much can be done about this crash. We'll try if we can access any of these devices to be able to run some tests.

[robertwu1]

Closing stale bug