oboe
oboe copied to clipboard
google
SIGSEGV at AudioStreamOpenSLES.cpp - Line 295
Android version(s): Android 6 and Android 7 Android device(s): HUAWEI P9 lite, Y5 2017, P9, and other HUAWEI phones Oboe version: 1.6.1 App name used for testing: (Please try to reproduce the issue using the OboeTester or an Oboe sample.)
Short description Recently, we updated Oboe from 1.5.1 to 1.6.1, and we started to get a non-trivial number of crash reports from Firebase.
Crashed: Thread : SIGSEGV 0x0000007f5f6c0234
#00 pc 0x1db58 libwilhelm.so
#01 pc 0x1dc64 libwilhelm.so
#02 pc 0x1dc64 libwilhelm.so
#03 pc 0x34b5f8 libbandlab_audio_engine.so (oboe::AudioStreamOpenSLES::enqueueCallbackBuffer(SLAndroidSimpleBufferQueueItf_ const* const*) [AudioStreamOpenSLES.cpp:295])
#04 pc 0xad88 libwilhelm.so
#05 pc 0x76c4c libmedia.so
#06 pc 0x773e0 libmedia.so
#07 pc 0x163ac libutils.so
#08 pc 0x15bfc libutils.so
#09 pc 0x67508 libc.so
#10 pc 0x1ed84 libc.so
Steps to reproduce
Expected behavior
Actual behavior
Device All the crashes reported from 100% HUAWEI devices:
6% P9
6% HUAWEI MediaPad T3 10
5% HUWEI MediaPad T3
4% P9 lite
3% P9 lite
3% Y5 2017
3% Y5 2017
3% honor 6x
3% HUAWEI MediaPad T3 10
2% GT3
2% HUAWEI MediaPad T3 10
2% Y5 2017
2% honor 6C Pro
2% HUAWEI GR5 2017
2% HUAWEI GR5 2017
2% Honor 5C
2% HUAWEI Y6 2017
2% P9 lite
2% HUAWEI MediaPad M3 Lite
1% HUWEI MediaPad T3
1% P9 lite
1% Mate 8
1% nova
1% d-01J
1% P9 Plus
1% Honor 8
1% P10 lite
1% P10
1% Y7
1% Y6 2017
1% Honor 6X
1% honor 6x
1% HUAWEI Mate 9 lite
1% P10 lite
1% P10
1% P9 Plus
1% HUAWEI P9 lite mini
1% HUAWEI G Elite Plus
1% HUAWEI P9 lite mini
<1% P8 lite 2017
<1% Honor 5C
<1% Honor 5C
<1% Y5 2017
<1% 荣耀畅玩6
<1% MediaPad T3 7
<1% 荣耀畅享7 Plus
<1% Y7
<1% 荣耀畅享7 Plus
<1% nova 2i
<1% Mate 10 lite
<1% nova lite
<1% P8 lite 2017
<1% 荣耀畅玩5C
<1% Y5 2017
<1% Mate 8
<1% GT3
<1% nova plus
<1% nova plus
<1% nova
<1% Honor 8
<1% FRD-L02
<1% honor 6A Pro
<1% Honor 6A
<1% M3
<1% MediaPad T2 7.0
<1% MediaPad M3 Lite 10
<1% MediaPad M3 Lite 10
Any additional context
If applicable, please attach a few seconds of an uncompressed recording of the sound in a WAV or AIFF file.
Recently, we updated Oboe from 1.5.1 to 1.6.1,
Are you using the 1.6.1 release? Or are you using the most recent code on GitHub? Unfortunately we have not bumped the version so it is also 1.6.1. We should bump the patch number after a release.
There have not been many changes in the OpenSL ES support. There was this change after the official 1.6.1 release. https://github.com/google/oboe/pull/1245 It modified enqueueCallbackBuffer() but it seems OK.
Do you know what Android versions these Huawei phones are using? Normally OpenSL ES is only used before Android 8.1. Do you use AAudio on more recent phones or are you forcing the use of OpenSL ES?
The P10 started at at 7.0 and was upgradable to 9.0. https://www.gsmarena.com/huawei_p10-8514.php
We use the most recent code on 1.6-stable branch
> git status
On branch 1.6-stable
Your branch is up to date with 'origin/1.6-stable'.
> git log
commit 06ec23e4f6bc00ba7eea9b84e299f9200a598838 (HEAD -> 1.6-stable, origin/1.6-stable)
Author: Don Turner <[email protected]>
Date: Thu Jul 22 19:35:45 2021 +0100
Bump version to 1.6.1
commit 911a3e9a1e5b5b368eab5520c93bc1374b7bbab7
Author: Phil Burk <[email protected]>
Date: Thu Jul 22 11:05:49 2021 -0700
oboe: remove include of ndk-version.h
This is to prevent a merge conflict with Android /external/oboe.
It does not seem necessary. __NDK_MAJOR__ is getting defined somewhere else.
Fixes #1358
commit 8ff99cc59f3d59f60b7d50c8bba16fca1850804c
Author: Phil Burk <[email protected]>
Date: Wed Jul 21 11:23:38 2021 -0700
oboe: improve DataCallbackResult::Stop handling (#1351)
We don't force to use OpenSL ES, we always set oboe::AudioApi::Unspecified for opening both input and output streams as:
builder.setAudioApi(oboe::AudioApi::Unspecified);
The Android versions of the HUAWEI devices are
65% Android 7
35% Android 6
The diff between the two releases for OpenSL ES only has two changes in the src/opensles folder. This is simply a change in types and should not affect anything as 24 bit and 32 bit audio should not be the default. This only removes a function and changes Oboe to c++17.
@taemincho Is this still a problem?
I went through every commit between the two releases and I don't see anything suspicious. @taemincho Can you check that there's no changes on your end that could have caused this between the two releases?
Also, the next release, whenever it comes out, should contain #1245, which adds stability to our OpenSL ES code.
The diff between the two releases for OpenSL ES only has two changes in the src/opensles folder.
Oboe has code in common for AAudio and OpenSL ES. A change in that code might trigger an OpenSL ES crash.
Here are some interesting changes between 1.5.1 and 1.6.1
oboe: fix possible race on close (https://github.com/google/oboe/pull/1200) https://github.com/google/oboe/commit/ff689eaaf2389b5a7ea316ad7336b1bc772561df Do you use a shared_ptr for the Oboe stream?
oboe: improve DataCallbackResult::Stop handling (https://github.com/google/oboe/pull/1351) https://github.com/google/oboe/commit/8ff99cc59f3d59f60b7d50c8bba16fca1850804c
I got the same issue while runing auto test on our product, oboe version: use master code with latest commit is 5ca07db3475e025608ed9b260b35dc928fe8b873.
@philburk @robertwu1 hi, we catch this crash today second times, could you analyze it?
@xzhan96 can you try a more recent commit? Perhaps #1570 fixes this.
@robertwu1 I will try this fix, but I find an important info in the log, it seems deadlock happens, can the #1570 also this?
Seems like there is a race condition where some code is waiting for something else to finish to grab the lock.
@philburk Do you know whether there are compile flags to help determine which functions are involved in this race condition?
Seems like there is a race condition where some code is waiting for something else to finish to grab the lock.
@philburk Do you know whether there are compile flags to help determine which functions are involved in this race condition?
@robertwu1 in addition, this crash happens in AudioInputStreamOpenSLES.cpp, but #1570 is AudioOutputStreamOpenSLES.cpp
I got the same issue while runing auto test on our product, oboe version: use master code with latest commit is 5ca07db.
This may be related to a similar issue we saw recently for Output. #1567 We have a fix for Output. A similar fix may work for Input.
@xzhan96 can you help verify whether #1621 solves your issue?
This seems fixed my issue, no new report recently. thanks.