Crash in [@ libaudioclient.so@0x5a478]
Categories
(Core :: Audio/Video: cubeb, defect, P5)
Tracking
()
People
(Reporter: RyanVM, Unassigned)
References
()
Details
(Keywords: crash, stalled)
Crash Data
This is a long-running Fenix crash. According to Socorro, the common thread I see is that it's all Samsung phones running Android 12. Not sure if there's much else to go off, though.
Crash report: https://crash-stats.mozilla.org/report/index/70d9d928-f465-401c-92fa-f6f310220607
Reason: SIGSEGV / SEGV_MAPERR
Top 10 frames of crashing thread:
0 libaudioclient.so libaudioclient.so@0x000000000005a478
1 libaudioclient.so libaudioclient.so@0x00000000000954cc
2 libaudioclient.so libaudioclient.so@0x00000000000b96f4
3 libaudioclient.so libaudioclient.so@0x00000000000b8124
4 libaudioclient.so libaudioclient.so@0x0000000000044ac0
5 libbinder.so libbinder.so@0x000000000003c880
6 libbinder.so libbinder.so@0x00000000000468cc
7 libbinder.so libbinder.so@0x00000000000463e8
8 libbinder.so libbinder.so@0x0000000000046c98
9 libbinder.so libbinder.so@0x000000000006e46c
Comment 1•2 years ago
|
||
There's several crashes happening inside libaudioclient.so. This is just the signature with the highest volume because it's with the library version that shipped with Samsung devices and those are very common. I encountered this crash myself and it shows up under a different signature but it's clearly the same issue (all the devices under that signature are Fairphone 3 and 4 devices, again because that version of the library ships with those devices). My STR was that I was playing a video (w/ audio) on Twitter and I turned off the phone while the video was playing, when I turned it on again the tab had crashed.
Comment 2•2 years ago
|
||
I remembered a detail which might help to repro: I didn't have the screen off, I received a call which I answered, then I turned the screen off because I don't like the proximity sensor accidentally turning it on while I talk. When I finished the call I turned the screen on again and then Fenix had crashed.
Updated•2 years ago
|
Comment 3•2 years ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 10 AArch64 and ARM crashes on release
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 4•2 years ago
|
||
qa testing, steps to reproduce. will file a qa ticket on this.
Comment 5•2 years ago
|
||
We'd love some help in trying to find a device we can reproduce this crash on. If we can do that, we may be able to get better symbols to understand the cause. Current theory is that this is happening in inter-process communication within the android runtime.
Comment 6•2 years ago
|
||
Up-to-date signature list, the volume is slightly higher than it appeared.
Comment 7•2 years ago
|
||
Hello, Jim! Please note that the team started looking into this issue and we will update the bug once we have more information regarding this crash.
Hi, we are currently investigating this issue, however we were only able to test this today with a Samsung Galaxy Note 8 (Android 9) device due to time constrains, and the issue was not reproducible. We will provide more details and test results on Monday, once we properly test on other Samsung devices and Android versions.
Hi, unfortunately we were not able to reproduce any crash on Samsung devices related to video/audio streaming from different webpages and locking/unlocking the screen from various instances.
Devices used: Samsung Galaxy Note10 (Android 12), Samsung Galaxy Note 8 (Android 9), Samsung Galaxy S9 (Android 8).
Builds used: Release 101.1.1. Nightly 103.0a1 (from crash reports), latest Release 106.0.1, Beta 107.0b5, Nightly 108.0a1.
Comment 10•2 years ago
|
||
I'm starting to think that the screen doesn't affect this bug, but the way Android juggles audio channels might. Could you try something like this:
- Watch some video (w/audio) on the phone
- While Fenix is playing the video call the phone w/ another one
- Take the call, wait a few seconds then hang up and go back to Fenix
Comment 11•2 years ago
•
|
||
Re-tested using the steps above. No crash occurred after hanging up the phone calls and returning to Fenix, but I will keep looking into it.
However, it is worth mentioning that on the latest Nightly 108.0a1 from 11/06 the tab crashes continuously when attempting to visit youtube.com and vimeo.com/watch due to https://github.com/mozilla-mobile/fenix/issues/27738.
Comment 12•2 years ago
|
||
(In reply to Delia Pop from comment #11)
Re-tested using the steps above. No crash occurred after hanging up the phone calls and returning to Fenix, but I will keep looking into it.
Thanks, the volume is really high here so there should be a way to reproduce this. I haven't encountered the crash on my phone lately so I wonder if it depends on the Android version on the device.
However, it is worth mentioning that on the latest Nightly 108.0a1 from 11/06 the tab crashes continuously when attempting to visit youtube.com and vimeo.com/watch due to https://github.com/mozilla-mobile/fenix/issues/27738.
This is a different crash.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 13•2 years ago
|
||
We receive about 40K of these crash reports every release cycle. Are these crashes deep in libaudioclient.so actionable by us? Can we get symbols for libaudioclient.so?
Looks like the crash volume jumped from ~10K in 100 (release date 2022-05-03) to ~46K in 101 (release date 2022-05-31). That could be a regression in Fenix or maybe a new Samsung OS update.
Top crashes by device manufacturer:
43% Samsung
24% Xiaomi
6% OPPO
5% OnePlus
... and then a long tail, so this bug is not manufacturer- or device-specific.
Fenix supports API 21+ (Android 5.0), but 100% of these crashes are from API 26+ (Android 8.0+) with newer API versions affected more than older versions.
Comment 15•2 years ago
•
|
||
We have tested with the latest Nightly 110.0a1 (2023-01-11) and with the latest RC 109.1.0 using a few more devices:
- Huawei P20 (Android 10).
- Oppo Find X5 (Android 12).
- Samsung Galaxy S22 Ultra (Android 13).
We couldn't reproduce the described crash using the steps from comment 10.
We tried reproducing the issue with call from phone, through Whatsapp and through Skype, with the same result (both video and audio calls)
Removing the qe-verify+ label.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 16•1 year ago
|
||
long shot here, Mathew spent some time on this without luck. az maybe you can take a crack at it.
Updated•1 year ago
|
Comment 17•1 year ago
|
||
I experimented with a Pixel 6a running Android 13, connecting / disconnecting bluetooth audio, muting, locking / unlocking phone, etc. but didn't have luck reproducing. I did a bit of digging to see if I could find issues related to audio stream handling that could spark some ideas. This issue could potentially be related, as could this issue, though a related patch has already landed for Android 13 / API 33.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 18•1 year ago
|
||
I hate to say it, but this bug is stalled. This bug has been open for 15 months. QA and 2 engineers have tried to repro this with no success. If there is action we can take that we haven't taken and that is likely to make a difference, let's un-stall the bug and take that action. Otherwise, I believe we're stuck waiting for more info/data (some sort of breakthrough).
Updated•1 year ago
|
Comment 19•1 year ago
|
||
Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.
For more information, please visit BugBot documentation.
Updated•9 months ago
|
Comment 20•6 months ago
|
||
Cleaning up the signatures after bug 1895527. Everything should now fall into the same signature.
Description
•