1376218 - [Linux] Audio playback crashes content process (and entire browser when e10s is off) (gstreamer update?)

Status: RESOLVED DUPLICATE of bug 1376000

(Core :: Audio/Video, defect)

Description

[Nazar Mokrynskyi]

Nightly tabs are crashing on Ubuntu 17.10 x64 always when E10S is enabled and if disabled it crashes the entire browser on audio playback (mp3 on website, youtube video). By tab I don't mean about:*, but regular websites.

It doesn't crash in Windows 8.1 x64 and doesn't happen in Ubuntu 16.10 Live CD (both in VMs). But it does happen in latest daily build of Ubuntu 17.10 x64 (2017-06-20) on physical machine.

I think it is related to the recent GStreamer update in 17.10 from 1.12.0 to 1.12.1, there was also minor libc6 update with security fixes, but don't think it is related here.

With Firefox 54 stable nothing crashes.

The crash output is not very descriptive:
firefox terminated by signal SIGSEGV (Address boundary error)

Comment 1

[u569373]

I have pretty much the exact same problem, all tabs are crashing with e10S actived except about:preferences, and with e10s disabled I can't watch any videos.
firefox nightly 2017-06-25
archlinux - nvidia proprietary drivers

Comment 2

[:Gijs (out for now; he/him)]

Does the tab crash (with e10s enabled) show up in about:crashes and can you get a crash report link from there?

Comment 3

[Nazar Mokrynskyi]

It gets even more interesting. I didn't update my system (0 packages updated since bug was reported) and on my primary machine it doesn't crash anymore under any of the mentioned circumstances.

However, it does still crash when booted from Live CD (had to reboot my physical machine) as it was before.
about:crashes says no crashes even though all of the tabs crashed, ~/.mozilla/firefox/Crash Reports also do not contain anything besides InstallTime* files.

Comment 4

[:Gijs (out for now; he/him)]

(In reply to Nazar Mokrynskyi from comment #3)
> However, it does still crash when booted from Live CD (had to reboot my
> physical machine) as it was before.

I'm confused about reconciling this with:

(In reply to Nazar Mokrynskyi from comment #0)
> It doesn't crash in Windows 8.1 x64 and doesn't happen in Ubuntu 16.10 Live
> CD (both in VMs). But it does happen in latest daily build of Ubuntu 17.10
> x64 (2017-06-20) on physical machine.

Are these different live cds?

Separately, is this maybe caused by a security sandbox issue? You can (temporarily...) lower the security sandbox pref to see if that works around the issue. See https://wiki.mozilla.org/Security/Sandbox - but essentially, I expect you'd want to set security.sandbox.content.level to 0.

Alternatively, maybe a debug build produces more informative output when run under gdb/lldb/rr ?

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Adding MOZ_SANDBOX_LOGGING=1 will give more info if sandboxing is suspected.

If you start Firefox from a console (instead of the menu) you should see debug output there (even without the above flag). Sandbox related crashes will have specific warnings/errors.

Comment 6

[Nazar Mokrynskyi]

Attachment: fresh-sandbox0-sandbox0backtrace.log

Comment 7

[Nazar Mokrynskyi]

> Are these different live cds?

No, one 17.10 x64 is my primary machine (not Live CD) and another is indeed Live CD I'm using to reproduce an issue in clean environment.

I've added a log file with output from 3 executions of the Nightly:
1) Fresh profile from read-only Live CD (all tabs crashed immediately)
2) Restart after security.sandbox.content.level set to 0 and opened youtube video to cause crashing (tabs didn't crash immediately this time)
3) Same as 2) with recommended (by previous output) backtrace

Comment 8

[:Gijs (out for now; he/him)]

The rust panic reason ("SinkInfo contains invalid flags") is the same as stated in bug 1376000 and bug 1375873, which just merged to mozilla-central. Does a build from this push: https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=da4ac701aae7e6c070af65dc8f07cec22c1598d5

ie

https://queue.taskcluster.net/v1/task/JQKqTXy6Sq6WggXTMbUD9Q/runs/0/artifacts/public/build/target.tar.bz2

(x64 pgo-optimized build)

resolve the issue? If so, I should think tomorrow's nightly should be OK again.

Comment 9

[Nazar Mokrynskyi]

Yes, it fixes the issue