Closed Bug 1551195 Opened 7 months ago Closed 6 months ago

Fennec Beta 68 x86 crash when sharing the microphone

Categories

(Firefox for Android :: Audio/Video, defect, P1)

Firefox 68
x86
Android
defect

Tracking

()

RESOLVED FIXED
Firefox 68
Tracking Status
firefox66 --- unaffected
firefox67 --- unaffected
firefox67.0.1 --- unaffected
firefox68 --- fixed

People

(Reporter: stefan.deiac, Assigned: padenot)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [bcs:p1])

Crash Data

Attachments

(2 files)

Environment:
Device: Lenovo Yoga Tablet 2 (Android 4.4.2) - x86;
Build: Nightly 68.0a1 (2019-05-07) and Beta 68.0b1 ESR builds;

Steps to reproduce:

  1. Go to: https://goo.gl/8fOcQf;
  2. Share your video/microphone;

Expected result:
A video starts playing from the camera;

Actual result:
The app crash immediately after sharing the video/microphone

Notes:

Does this only reproduce with the Try builds?

Flags: needinfo?(stefan.deiac)

I tested with the official builds Beta 67.0b18 and Nightly 68.0a1 (2019-05-13) but I can't reproduce the problem.

Flags: needinfo?(stefan.deiac)
Summary: Crash on x86 after sharing your camera and microphone → [ESR builds]Crash on x86 after sharing your camera and microphone

I had Stefan try out a 68-as-Beta simulation build from April 30, which predates any of our Fennec ESR patches landing and the issue is still reproducible. So that's pointing to this being a general issue with Beta68. Any thoughts on this, Dan? I've also given Stefan some pointers for trying to narrow down the regression window a bit, but that may be a time-consuming endeavor and I'm not sure how narrow of a window will be possible.

No longer blocks: ESR-Fennec
Flags: needinfo?(dminor)
Summary: [ESR builds]Crash on x86 after sharing your camera and microphone → Fennec Beta 68 x86 crash when sharing the camera and microphone

Hi Stefan, I see cubeb on the crash stack which is the library we use to interface with the operating system audio libraries. Can you please retest with with only the microphone shared to see if this reproduces without video? That would help narrow things down. Thank you!

(Visiting this page: https://mozilla.github.io/webrtc-landing/gum_test.html and selecting audio should work)

Flags: needinfo?(dminor) → needinfo?(stefan.deiac)
Crash Signature: [@ libmedia.so@0x60d96]

Hello, I tried to reproduce this issue using the link from comment 4 and my findings are:

  • When I share both of them (microphone and camera) - the application crash;
  • When I share only the microphone - the application crash;
  • When I share only the camera - the application doesn't crash;

Additionally, I tried with appr.tc and talky.io and the issue is still reproducible.

Flags: needinfo?(stefan.deiac)
Hardware: ARM → x86
Whiteboard: [bcs:p1]
Priority: -- → P1

Alex, do you mind having a look at this? From the crash stack, it looks like it might be cubeb related.

Flags: needinfo?(achronop)

I need the line number in the stack frame 32 in the crash report above. I can also do with the exact libxul.so from a build that crashes, maybe, but it'd be easier with a good crash report.

Flags: needinfo?(stefan.deiac)

Stefan, can you try a debug build in case we get a better stack. If it does not reproduce in Beta 67.0b18 can we find which commit broke this?

Flags: needinfo?(achronop)
Summary: Fennec Beta 68 x86 crash when sharing the camera and microphone → Fennec Beta 68 x86 crash when sharing the microphone

Hello, I tried to debug all versions from simulation builds and those are my findings:

Flags: needinfo?(stefan.deiac)

Yes, we need the line it crashes, the commit that broke it is my patch set in bug 1531833.

I think this is related to non-standard behaviour of audio methods on some devices.

Flags: needinfo?(stefan.deiac)
Attached file Logcatx86crash.txt

Hello, there is the logcat of the crash.

Flags: needinfo?(stefan.deiac)

Stefan, can you repro on the device with this build, which has additional logging, and provide the logcat ? Thanks.

Flags: needinfo?(stefan.deiac)
Attached file logcat.txt

Hello, I tried to reproduce the issue using your build from comment 12. Anyway, I'll attach a logcat with my findings. Hope it helps.

Flags: needinfo?(stefan.deiac)

You mean that it works with this build? Indeed this log seem to be of something that works and does not crash.

Flags: needinfo?(stefan.deiac)

Yeah, the crash doesn't occur anymore with this build.

Flags: needinfo?(stefan.deiac)

That's annoying, it only changes logging. Alex, do you know what could happen here, have you seen this? Probably a subtle race?

Flags: needinfo?(achronop)

From a chat with Stefan last week, the issue seemed only to reproduce up to May 7th: https://treeherder.mozilla.org/#/jobs?repo=try&resultStatus=testfailed%2Cbusted%2Cexception&revision=7845efee95bebe266d76844c198cf70bb14916

Also had hacked together a debug build with which Stefan was able to reproduce:
Can you try with https://treeherder.mozilla.org/#/jobs?repo=try&revision=077c9a9040f257e9e953d5ab5214c6aa0af7b836 ? That's a debug build based on the same code like the last failing opt one.

(In reply to Sebastian Hengst [:aryx] (needinfo on intermittent or backout) from comment #17)

Also had hacked together a debug build with which Stefan was able to reproduce:
Can you try with https://treeherder.mozilla.org/#/jobs?repo=try&revision=077c9a9040f257e9e953d5ab5214c6aa0af7b836 ? That's a debug build based on the same code like the last failing opt one.

Can you please open the about:crashes page of that debug build and provide the crash-ids listed there. I hope that a crash report from a debug build will provide some extra information. Right now the report is vague. Not sure where we crash.

Flags: needinfo?(achronop) → needinfo?(aryx.bugmail)
Flags: needinfo?(aryx.bugmail) → needinfo?(stefan.deiac)

Thanks to :willkg for the explanation why the a resymbolification of the crash stack didn't make it more readable. The libmedia.so is from Android and the symbol upload job provides the symbols for Fennec. Are crashes in system files on Android 4.2 x86 in general?

If it does not repro after May 7th, can we try to find what fixed it? There was quite some changes there, if I have a range I can have a look and find what fixed it.

Flags: needinfo?(aryx.bugmail)

Pushlog last bad to first good: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fd64908d113d7cdf085be1e2858e10dd69643e3&tochange=65a693623cee0837b4ad0d23241c84cd3ea23e3a
Let me know if more builds are needed for bisection.

Stefan also mentioned "it seems that from 03-29 to 04-16 the issue disappears and from 03-24 to 03-28 is it reproducible".

Flags: needinfo?(aryx.bugmail)

Most likely Bug 1549699 fixed it.

If there are no recent crashes, can we close this one out?

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #24)

If there are no recent crashes, can we close this one out?

I see only 8 reports in Fennec 68.0b5 and none from Fennec 69 Nightly. We can probably close this bug as fixed by bug 1549699.

Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Assignee: nobody → padenot
Depends on: 1549699
Target Milestone: --- → Firefox 68
You need to log in before you can comment on or make changes to this bug.