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
<https://developer.android.com/ndk/reference/group/audio#group___audio_1gadf9c1647e285dab77fd5dc062225bcbd>
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
<https://developer.android.com/guide/components/activities/activity-lifecycle#asem>
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' via android-ndk]

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

Post by 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
<https://developer.android.com/ndk/reference/group/audio#group___audio_1gadf9c1647e285dab77fd5dc062225bcbd>
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
<https://developer.android.com/guide/components/activities/activity-lifecycle#asem>
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.
--
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
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
<https://groups.google.com/d/msgid/android-ndk/97e8e492-f106-4a38-8058-e2827356fff5%40googlegroups.com?utm_medium=email&utm_source=footer>
.
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

Post by 'Phil Burk' via android-ndk
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.
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

Post by 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
<https://developer.android.com/ndk/reference/group/audio#group___audio_1gadf9c1647e285dab77fd5dc062225bcbd>
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
<https://developer.android.com/guide/components/activities/activity-lifecycle#asem>
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.
--
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
<javascript:>.
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
<https://groups.google.com/d/msgid/android-ndk/97e8e492-f106-4a38-8058-e2827356fff5%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.

['Phil Burk' via android-ndk]

Hello Daniel,

Post by Daniel D-G
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.

Post by Daniel D-G
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