Crashes on many Android 8.0 devices #40
Comments
|
Thanks for this report. We need to resolve this. Some background: Do you have a bugreport file that we can analyze? If not, can you provide an APK that crashes so we can collect a bugreport.
This might be related to some "smart pointer" issues. There were changes between 8.0 and 8.1 in that area. That can cause seemingly random crashes. The mentions of RefBase::decStrong are a possible clue. In your code, are you stopping and restarting a stream multiple times? Are you using any of the error callback functions? Are you using the latest or a recent Oboe? |
|
Unfortunately I don't have a bug report file at this time beyond the stack traces. I tried flashing Nexus 5X back to 8.0 and can't repo. Stream is created and started with requestStart(), stream is requestPause() and requestStart() on play/pause button. Stream is requestStop() and close(), and a new one can be created quickly when the track changes. https://drive.google.com/file/d/18GKXpLnN6ooIxzhHUFNijscKiFIDScJF/view?usp=sharing Most of the code used was basically hello_oboe. Except stream is created like this: |
|
Thanks Steve. I got the APK and found an icon called "MusicSpeed". I assume that is the app. You can remove that APK from Drive now. I will run the app against 8.0. This might be related to an internal issue relating to pointer management. That can look pretty random. But I'm not sure yet. Your open code looks fine. Are you doing anything in the callback in response to errors, eg. headphone disconnects? When you try to reproduce the error, try plugging and unplugging headphones. Also try starting and stopping other sound apps or send the phone a notification. Also try starting a bunch of other apps and leaving them open so that there is memory pressure.
For the legacy data path, when using the speakers or wired headphones, on 8.0, generally yes. |
|
I started an internal bug tracker b/71758614 |
|
Tried all those things on Nexus 5X with 8.0 with Sept 5, 2017 security patch. Yes I have the error callback for disconnects, tried plug/unplug headphones rapidly, connecting/disconnecting to bluetooth speakers, other music apps and switch rapidly, ducking under notification, rapid play/pause and track switching. It's all completely solid, no crashes. Haven't tried filling up memory yet but you may be on to something. In Fabric, all the devices are listed as between 1-5% RAM free. The rate of crashing is very high, which may suggest there is something with oboe and these devices that is causing some sort of memory leak. I have other unrelated crashes with MAPERR, that I can replicate by consuming tons of memory, but these are at much lower rates on mostly old devices with low memory. |
|
The memory leak may or may not be in AAudio. I suspect not. But I suspect that low memory conditions may be causing the lowmemorykiller to kill some processes, and for the garbage collector to behave differently. That may be triggering a bug that is normally not exposed. |
|
Slowly filling a vector until it crashes doesn't reveal much, not the same stack trace. I should also mention I did release a beta with oboe for Android < 8.0 where it would use OpenSL. No crashes there either. Only thing to do seems to get ahold of one of those devices, are any accessible to you? |
|
I should be able to get my hands on some of the models which are crashing in the office today - will try to repro as soon as I'm there. |
|
Test environment Device: Sony Xperia XZ (Model: F8331) Steps to reproduce:
Expected result
Actual result
|
|
Some comments:
|
|
Thanks for capturing it. You're right of course about creating a new stream everytime, but it would be a major redesign at this point. Will post my full code later.
This happens right before crash, what is state 9? |
|
To make this bug easier to reproduce, and so you don't have to share (potentially proprietary) code I have modified the hello-oboe sample to reproduce this issue: https://github.com/googlesamples/android-audio-high-performance/tree/android-8.0-crash/oboe Steps to reproduce:
Expected result:
Actual result
|
|
@svenoaks State 9 is STOPPING. Full list of states: |
|
Thanks Don. Having an easy repro case will be a big help? Can you get it to crash on Marlin? if so then we can instrument AAudio and get a bit more info.
That is printed from the destructor for the stream in legacy mode. state 3 is starting. Something is deleting that object while it is still in use. It could be a call from the app (hopefully, easy to fix). Or it could be internal, which I suspect is the case. Feel free to move the detailed investigation to the internal bug tracker at b/71758614 |
|
Action: Change the test to open and close stream. Try the address sanitizer. |
|
Hello, is there any update on status of this bug? (I can't see internal bug tracker) Or, most importantly how to fix, aside from leaving the same stream opened. |
|
I've attempted to reproduce this error on recent (that means, what will come after 8.1) Android builds instrumented with Address Sanitizer (ASAN), and haven't seen any problems so far. It's possible that the bug was indeed fixed after Android 8.0. svenoaks@ Steve, do you see those crashes only in bugreports from 8.0, or there are also any from 8.1? If this bug is specific for 8.0, then I would suggest disabling AAudio path in Oboe if the app is running on 8.0. |
|
Yes it's in 8.0 and not 8.1
Sent via the Samsung Galaxy S8+, an AT&T 4G LTE smartphone
null
|
From #40, it seems that AAudio on Android 8.0 isn't stable enough. As a safety measure, always fall back to OpenSL ES on it.
|
Steven, you can try enabling Oboe again. On 8.0 devices it will now use OpenSL ES to avoid those AAudio crashes. |
From #40, it seems that AAudio on Android 8.0 isn't stable enough. As a safety measure, always fall back to OpenSL ES on it.
|
Are we sure 8.1 is going to be fine when it is released on third party devices? Only devices which have 8.1 are Pixel and Nexus. The crash did not occur on Pixel and Nexus on 8.0 only third party. It's a really bad bug, I hope it is actually fixed in 8.1. Now that I have device with 8.0 to repo it, it occurs any time stream closes even when disconnected headphones. |
|
I had the same problem with a stacktrace involving The problem is probably fixed by 8a8a9e5d91c8cc110b9916982f4c5242efca33e3. |
|
Seeing the same thing as reported by svenoaks - for our hearing aid (low latency) app (using AAudio and not Oboe):
362 reports for 202 impacted users are of this type:
52 reports for 39 impacted users are of this type:
Since we promise a low-latency solution - probably we will just limit the app to target Oreo 8.1 and above (thereby losing out on the 8.0 demographic). Unless there is a way to circumvent the bug, or close the app before we do a close stream (if close stream is the one causing the crash). |
|
We do not know of a way to circumvent the bug in AAudio. We believe that the bug is limited to Oreo 8.0 and was fixed for 8.1. The changes are too extensive to back-port to AOSP. It can sometime be triggered by Java garbage collector so the behavior can seem a bit random. |
|
Thanks. |
|
An app suddenly had a surge of crashes looking related to this thread. I don't think it is related to Java code change, it may related to the change of build.gradle. I am wondering if compileSdkVersion has any impact on this. |
|
Please could you provide the make, model and O/S version of the device and also confirm that you're using the latest version of Oboe. |
|
It looks like the bug is associated with |
|
@dturner No, the app is not using AAudio or Oboe directly. I just thought it might be related. Could you tell me how you told it is related to MediaCodec. The app is primarily for video streaming. Here are some examples of the devices sending the crash report: |
|
@dturner OK. I figured you told by: |
|
This bug involves reference counting, which could be triggered by a change in Java code. If your Java code changed, and this suddenly started happening, then review the Java changes. If it does not look like a bug in your app then it might be a bug in Android related to MediaCodec and libstagefright. #00 pc 000000000000d704 /system/lib64/libutils.so (_ZNK7android7RefBase9decStrongEPKv+28) Feel free to file a bug at: |
|
@philburk Thank you for the tip. I believe that I have found the culprit as indicated in the stack trace: MediaCodec.Reset(). I updated the app after excluding Android 8.0 device in executing MediaCodec.Reset(). I have not seen the crash so far. |
|
I am trying to use oboe on my android app. And I have something to ask. I am using compileSdkVersion 26. And if I import oboe on my app, I couldn't build this. So..! |
|
I see you've opened a new issue for this question - which is what I was going to recommend :) |
I recently tried Oboe in my app for sound output for Android 8.0+ (only). I had to halt rollout because probably the majority of devices with Android 8.0 (none with 8.1) have repeating crashes probably making app unusable. I can't reproduce on API 26 or 27 emulator or a Nexus 5X which I upgraded and tested on both 8.0 and 8.1. When I removed Oboe for 8.0 in new release crashes went away.
The most common crashes not directly implicate Oboe, but lesser crashes on same devices do. Perhaps relevant information is I am building Oboe with old Android.mk system and with APP_PLATFORM = android-14 (though I think it is using 21 for Arm64 anyway automatically). Clang and c++_shared. NDK latest version in SDK manager. 16.1.4479499
Thinking about buying one of these devices and trying to get more information.
The text was updated successfully, but these errors were encountered: