AAudio-related crash

[Daniel D-G]

Hey all,

I'm working on building an AAudio based synthesizer app. I've gotten everything up and running, with one exception (in the figurative sense, lower-case "e"): every time I run the app and then close it (i.e. Activity OnStop()), I get a strange segmentation fault somewhere in system code (the stacktrace of which is attached). This occurs after my cleanup code runs in OnStop(); this code performs the tasks needed to close the audio stream, including calling AAudioStream_close on the stream I opened in the Activity OnStart().

As verified through debugging, everything works properly through the end of user code (AAudio reports that the stream closed successfully), but then soon after, the app crashes in the background. This is likely at the point where the process is being shut down by the system to free RAM. It appears libbinder.so is attempting to access a null pointer, but I have no idea what it might be looking for; in the entire stacktrace, there is no reference to any of my code. Interestingly, the crash doesn't seem to occur on the emulator, but always occurs on my device (a Motorola Moto Z Play).

Any idea what might be causing this? I want to be sure it's a bug before filing a GitHub ticket; perhaps something is wrong with my code.

[Phil Burk]

Hello Daniel,

Note that AudioStream_close() frees the memory associated with the stream so that pointer should no longer be used.

You might be hitting a problem related to PlayerBase reference counting that was introduced just before the 8.0 release. This fix is in 8.1.  The bug involves garbage collection and background processes, so it can seem sort of random. It also seems to happen more on some devices than others.

You can read more about it here:

https://github.com/google/oboe/issues/40

Note that we are recommending that app developers write to the Oboe API instead of directly to AAudio. Oboe is a thin C++ wrapper over AAudio. On devices where AAudio is unavailable, or has issues like the one above, then it automatically falls back to using OpenSL ES.

Phil Burk

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/97e8e492-f106-4a38-8058-e2827356fff5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel D-G]

Hey Phil,

Thanks for that explanation! That does indeed look like the bug I'm experiencing. I am creating a new stream after closing the old one, so that's not the issue.

I'm familiar with Oboe (I watched your I/O 2017 talk about it), but have not been using it as I understand it to be in beta. It looks like a highly useful library though; this would allow me to move my minimum supported version back to Marshmallow (my app needs MIDI support).

However, given your endorsement here, I think I'll try swapping out my AAudio code with Oboe instead! Out of curiosity, will it be moved into the NDK when it is stable, or will it continue to exist as a GitHub repo?

-- Daniel

[Phil Burk]

Hello Daniel,

On Tue, Jun 12, 2018 at 12:51 PM Daniel D-G <dadu...@gmail.com> wrote:

I'm familiar with Oboe (I watched your I/O 2017 talk about it), but have not been using it as I understand it to be in beta.

 

Oboe is in Developer Preview mode. The API is even changing slightly as we progress towards a production release.

But there is less risk using a source code package like Oboe because you can find and fix bugs yourself then re-release your app.

 

Out of curiosity, will [Oboe] be moved into the NDK when it is stable, or will it continue to exist as a GitHub repo?

Oboe will stay open source. I think it is better to keep as much code as possible outside the framework. That is because

• framework code is tied to annual release cycles, so it take a long time to release bug fixes
  
• external source like Oboe can be used on old versions of Android
• third party developers can modify Oboe if needed, or contribute improvements

So I am trying to minimize the amount of code in the framework and put all the extra stuff in Oboe.

Phil Burk