A crash occurs when opening 100+ WebGL processes while Fission enabled
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
People
(Reporter: mheres, Unassigned)
References
Details
[Affected Versions]:
- Firefox Nightly 91.0a1 (Build ID: 20210711212832)
[Affected Platforms]:
- Linux Mint 20 (GPU: AMD RS780L [Radeon 3000])
- VM:
Parent PC: Windows 10 x64, 16GB Memory, CPU: Intel I5 7600k @ 3.8 GHz, GPU: Nvidia 1080TI
VM: Ubuntu Linux 20.04 x64, 8GB Memory, 4 cores, Dedicated Video Card
[Notes]:
- The issue also seems to be reproducible for non-webGL pages (e.g. https://getpocket.com/explore/item/the-king-and-his-husband-the-gay-history-of-british-royals?utm_source=pocket-newtab-intl-en).
[Prerequisites]:
- Have a user.js file that will enroll you into an experiment that sets “fission.experiment.enrollmentStatus” to “2”. The user.js used also sets “dom.ipc.processCount.webIsolated” to “260”.
- Have a profile created but not yet opened.
[Steps to reproduce]:
- Navigate to the profile folder of the profile from prerequisites.
- Copy the user.js file from prerequisites there.
- Open the profile using Firefox 91.
- Restart the browser twice.
- Open “http://webglsamples.org/halo/halo.html” in >100 new tabs (~109 for my attempt).
- Observe the behavior.
[Expected result]:
- The browser and operating system continue functioning.
[Actual result]:
- The browser and sometimes the OS freeze.
- The “about:crashes” pages displays this crash:
https://crash-stats.mozilla.org/report/index/1b12ce81-25cc-446f-93e6-fff0a0210712#details
[Notes]:
- The branch with Fission disabled displayed noticeable lag and some freezing as well, but the "about:crashes" page did not display a crash for the times attempted.
- This issue is not reproducible for all pages (e.g. "https://en.wikipedia.org" opened in 260+ tabs did not reproduce it).
Comment 1•3 years ago
|
||
Jeff, QA tested Linux semi-headless mode and Fission in Nightly 91. Would WebGL remoting (bug 1638466) or a WebGL X11 connection limit (bug 1683420) avoid these browser and OS hangs and crashes? Do you think we should fix one of those bugs before we ship Fission on Linux?
Comment 2•3 years ago
|
||
I'm downgrading this bug's priority from P1 to P2 because this crash might require Fission and might also require a non-default pref change (dom.ipc.processCount.webIsolated
= 260
) that is known to greatly increase memory usage.
Comment 3•3 years ago
|
||
This bug doesn't need to block Fission MVP. The same hangs and crashes can be reproduced without Fission if you increase the number of content processes e10s is allowed to open.
Comment 4•3 years ago
|
||
(In reply to Maria Heres, :mheres, Ecosystem QA from comment #0)
- The issue also seems to be reproducible for non-webGL pages
Pages will sometimes use WebGL in the background for fingerprinting (and my vague understanding is that at least some of that is for purposes like detecting abusive bots, rather than just ad targeting). In that case, ideally the WebGL context is used only for a short time, and once it's GCed then the X connection will be closed; I've observed this to happen with the background WebGL usage on one large site that I tested (reddit), but I don't have a good sense of how the larger Web ecosystem acts. So, opening a large number of (simulated) different sites all at once may not give the same results as a user who opens all of those tabs gradually over a period of time.
If there are 100+ distinct sites all loaded at once which are all actively using WebGL, then yes, we're going to have problems (absent solving either of the bugs mentioned in comment #1), but… does that ever happen in practice?
Comment 5•3 years ago
|
||
I don't think there are non-synthetic cases where >100 sites would load at once, much less ones that happened to have webgl.
Updated•3 years ago
|
Description
•