Mailing List Archive

firefox e10s tab crashes on accessing the net (not about: however)
When I enable firefox electrolysis (aka e10s) browser-internal pages such
as about:config, about:support, and about:addons, load, but nothing
actually on the web will load -- the progress bar goes all the way across
and just as the page appears to be parsing, TAB-CRASH, with the offer to
(try to) reload the page (which fails the same way).

This is regardless of whether I'm running with all extensions (which I've
spent quite some time on weeding out and replacing the non-e10s-
compatible ones, they're all reported compatible with multiprocess now)
enabled, all disabled, in safe mode, even after a firefox refresh.

I'm running the packages direct-downloaded and user installed (as opposed
to system install or normal gentoo build and install) from Mozilla, so
it's not a build error on my end.

I've been working on this for awhile, first trying the force-enabling
back on firefox 50 or so, then trying in safe mode and "refreshed" with
51 and now 52, and only just last nite getting the last incompatible
extension removed, so now it's getting frustrating as I have to force-
DISABLE it now, because otherwise I can't browse! Earlier this morning I
tried the beta (53b6) as well -- same problem.

Firefox works fine in single-process mode, tho of course if one tab
blocks that tends to freeze the whole thing, as could be expected in
single-process mode.

I'm wondering if the problem is firefox trying to use some sort of exotic
IPC method I don't have enabled in the kernel or something, since it only
appears to be a problem with e10s, not single-process.

Running firefox from a terminal window, this is the error I get:

[Parent 8379] WARNING: pipe error (89): Connection reset by peer: file /
home/worker/workspace/build/src/ipc/chromium/src/chrome/common/
ipc_channel_posix.cc, line 346

###!!! [Parent][MessageChannel] Error:
(msgtype=0x2C0085,name=PBrowser::Msg_Destroy) Channel error: cannot send/
recv


Seeing the ipc_channel_posix.cc thing, I tried enabling
CONFIG_POSIX_MQUEUE in my kernel -- no luck.


To check to see if it's enabled, type about:support in the address bar,
then check the first section, applications basics, under multiprocess
windows. n/m where n is 0 is no, should have a reason. m appears to be
the number of windows so n/m where both numbers are equal and positive
indicates it's enabled for all windows.

Just having others confirm it's working for them, along with the firefox
version they're running and whether it's the mozilla binary or gentoo
build, would give me more info than I have now.


Meanwhile, for those who want to play with it and need further
information:

https://wiki.mozilla.org/Electrolysis

For me tho it was the browser.tabs.remote.autostart2 and force-enable
settings (the latter of which I had to create myself, not just toggle).

Be sure you've backed up your profile, tho, just in case. It should be
located in ~/.mozilla/firefox or similar. Even tho I couldn't get to the
web I could still get to about:config to reset things, but being able to
replace the broken testing config with a normal backup in case things get
too out of hand is definitely nice. =:^)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: firefox e10s tab crashes on accessing the net (not about: however) [ In reply to ]
Duncan posted on Sun, 26 Mar 2017 14:53:04 +0000 as excerpted:

> When I enable firefox electrolysis (aka e10s) browser-internal pages
> such as about:config, about:support, and about:addons, load, but nothing
> actually on the web will load -- the progress bar goes all the way
> across and just as the page appears to be parsing, TAB-CRASH, with the
> offer to (try to) reload the page (which fails the same way).
>
> This is regardless of whether I'm running with all extensions (which
> I've spent quite some time on weeding out and replacing the non-e10s-
> compatible ones, they're all reported compatible with multiprocess now)
> enabled, all disabled, in safe mode, even after a fir

Seems the problem /may/ have been due to firefox only officially
supporting pulseaudio now -- no more alsa support.

I was using the apulse library package to work around that issue so I
could get audio from the upstream firefox install, without having to
install pulseaudio, and it seems apulse breaks if e10s (multi-process
firefox) is enabled, thus breaking firefox.

FWIW, Mozilla upstream is leaving the alsa build-time feature available,
at least for now, but telling distros mozilla no longer tests alsa or
cares if it breaks, so it's up to any distros that care to keep working.

We'll see how that goes, but meanwhile, at least for now gentoo's firefox
ebuild still allows alsa (or jack) instead of pulseaudio, and apparently
enables alsa by default if USE="-jack -pulseaudio" (IOW, no separate
USE=alsa flag to set).

And once I worked thru a couple bugs (and the loonnnggg now effectively
required rust dependency build) and got the firefox ebuild actually
building again, with alsa, I could enable multi-process/e10s and
everything still worked.

Testing the mozilla-built package again, e10s was still broken as long as
apulse was installed -- and worked but of course without sound with apulse
not installed. Switching back to the ebuild-built firefox, with alsa not
pulseaudio support, I had both e10s AND audio. =:^)

So it would seem apulse breaks firefox multi-process/e10s -- but since
the upstream build only supports pulseaudio now, I have four choices,
either upstream-build with audio using apulse but no multi-process/e10s,
upstream-build without audio but with multi-process/e10s, upstream build
but finally give in and install pulseaudio proper, to get both e10s and
audio, or do the full gentoo build.

For now I'm back to doing the full gentoo build. Unfortunately, the
reason I had quit doing that in the first place is because gentoo often
takes days, sometimes weeks, to make a current build available after
upstream has updated. Which is fine for most things, but when the new
build fixes many security vulns as it normally does, and that's my
primary way of interacting with the not entirely trusted web, those extra
few days after upstream release and vuln publishing before gentoo gets an
ebuild ready could mean the difference between me getting compromised,
and not.

So I had decided to go with the upstream build in ordered to actually be
able to upgrade the day a new firefox version, along with all the vulns
it fixed, was announced.

Now I don't know /what/ I'll do in that regard, as it appears the mozilla
folks have put those of us who have chosen not to drink the pulseaudio
koolaid between a rock and a hard place.

Maybe I'll have to try chromium one of these days... That seems to be
where mozilla's headed in any case...

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman