katyo/oboe-rs

Calling get_frames_written results in SIGABRT 'Pure virtual function called!'

Closed this issue · 4 comments

Here is a trace example:

A/DEBUG: signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
A/DEBUG: Abort message: 'Pure virtual function called!'
<...>
A/DEBUG: backtrace:
A/DEBUG:       #00 pc 000000000006f06c  /apex/com.android.runtime/lib64/bionic/libc.so (abort+160) (BuildId: 95e03d8a9f101c0f1d3d9458688aa085)
A/DEBUG:       #01 pc 00000000000b155c  /data/app/rust.bevyios-3cTZXjf4DUdmqU6aym2Eiw==/lib/arm64/liboboe-ext.so (abort_message+236) (BuildId: da848013f2cb20dbcb4a9521aed0064c3f825c80)
A/DEBUG:       #02 pc 00000000000af424  /data/app/rust.bevyios-3cTZXjf4DUdmqU6aym2Eiw==/lib/arm64/liboboe-ext.so (__cxa_pure_virtual+16) (BuildId: da848013f2cb20dbcb4a9521aed0064c3f825c80)
A/DEBUG:       #03 pc 000000000005894c  /data/app/rust.bevyios-3cTZXjf4DUdmqU6aym2Eiw==/lib/arm64/liboboe-ext.so (oboe::AudioStream::getFramesWritten()+24) (BuildId: da848013f2cb20dbcb4a9521aed0064c3f825c80)
A/DEBUG:       #04 pc 000000000076012c  /data/app/rust.bevyios-3cTZXjf4DUdmqU6aym2Eiw==/lib/arm64/libbevyios.so (_$LT$T$u20$as$u20$oboe..audio_stream..AudioOutputStream$GT$::get_frames_written::hb9067d42620f3f7a+24)

I assume this happens because getFramesWritten/getFramesRead are not parts of the wrapper code, like getFramesPerBurst. As a side note, it would be nice to integrate getTimestamp along with fixing this issue, as it also requires dealing with the wrapper code.

katyo commented

Hmm... It seems, this method unsupported in that context.
Can you give code sample?

I don't have a sample right now, but it occurred when invoking get_frames_written on the stream within data callback.

Interestingly, I'm having a similar problem with AAudio directly - trying to invoke AAudioStream_getTimestamp on a stream provided by AAudio in the callback results in Pure virtual function called! error. Although it should work according to the AAudio docs.

katyo commented

I double checked oboe's programming guide, it seems any stream.get*() methods is ok in that context.

It seems this was a problem in an application where I was testing these things. It called std::process::exit(0), which is not instantaneous on Android. That resulted in weird behavior, including this symptom.