Closed Bug 1566206 Opened 2 months ago Closed 2 months ago

Firefox hangs up completely on svg and css combination if webrender is enabled

Categories

(Core :: Graphics: WebRender, defect, critical)

68 Branch
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla70
Tracking Status
firefox-esr60 --- unaffected
firefox-esr68 --- disabled
firefox68 + verified
firefox69 + verified
firefox70 --- verified

People

(Reporter: frozolotl, Assigned: nical)

References

(Blocks 1 open bug, Regression, )

Details

(Keywords: hang, regression)

Attachments

(2 files)

Attached file testcase

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Use the latest stable firefox (68) or latest nightly (70.0a1.20190710-1).
Set gfx.webrender.enable to true.
Open https://azgaar.github.io/Fantasy-Map-Generator/ (http://archive.fo/xmelR).
Then let the browser render the page.

Actual results:

The browser completely hangs up and the window is not redrawn.
No crash report is created by itself.
Firefox has a CPU Usage of about 100% on a single core.
The remaining CPUs all have a usage of about 1% to 15% and don't or rarely seem to be used by firefox.
I waited at least 5 minutes until stopping firefox.
Stopping firefox using SIGABRT produces no stack trace ("The application did not leave a crash dump file.", no .dmp file is created); about:crashes does not list any crash reports.

Expected results:

A map would have been displayed.

[Tracking Requested - why for this release]:

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

Component: Untriaged → Graphics: WebRender
Product: Firefox → Core

I can reproduce this issue with the following settings regarding webrender:

gfx.webrender.enabled: false
gfx.webrender.all: false

(essentially default settings; I reverted all changes to default that I tried during testing that, when I encountered it)

So the bug does indeed happen without webrender enabled.

Thanks for the report!
[Tracking Requested - why for this release]:
Confirmed on Win10/GTX1060. It completely freezes Firefox 68 and Nighty 70. Had to kill Firefox.
Does not happen with gfx.webrender.force-disabled;true.

Severity: normal → blocker
Status: UNCONFIRMED → NEW
Has STR: --- → yes
Ever confirmed: true
Keywords: hang
OS: Unspecified → All
Hardware: Unspecified → All
Severity: blocker → critical

Here's a perf perf profile: Seems like WrRenderBackend got stuck under process_api_message, but haven't debugged further: https://perfht.ml/2LTjrKp

The testcase has some very big lines in it. Perhaps we're hitting an error case that causes us to enter an infinite loop.

mozregression --good 2019-03-15 --bad 2019-05-19 --pref gfx.webrender.all:true -a https://bugzilla.mozilla.org/attachment.cgi?id=9078255

5:31.31 INFO: Last good revision: b90fc7a65c3d61bbf14c98fd2baaf28014562ff0
5:31.31 INFO: First bad revision: 902bff64318d963ea1d5505eebd0f66b11d55f28
5:31.31 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b90fc7a65c3d61bbf14c98fd2baaf28014562ff0&tochange=902bff64318d963ea1d5505eebd0f66b11d55f28

902bff64318d963ea1d5505eebd0f66b11d55f28 Nicolas Silva — Bug 1519106 - Converge towards the max number of tiles faster. r=kats
d6c9841c74cdc5cdb84becbd304afcdebf13a3cf Nicolas Silva — Bug 1519106 - Increase the maximum number of rasterized blob images per transaction. r=kats

Has Regression Range: --- → yes
Keywords: regression
Regressed by: 1519106
Assignee: nobody → nical.bugzilla
Flags: needinfo?(nical.bugzilla)
Blocks: wr-69

There are two things here:

  • overflow when the number of requested tiles is larger than i32::MAX (ouch!)
  • that we request that many tiles in the first place.

The patch fixes the former, but the latter kinda throws a wrench in my plan to simplify blob images and rasterize all blobs during scene building.
I filed bug 1566769 to follow up with that issue.

Flags: needinfo?(nical.bugzilla)
Pushed by nsilva@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e4883e59d419
Avoid overflow when limitting the number of rasterized blobs. r=jrmuizel

Comment on attachment 9078632 [details]
Bug 1566206 - Avoid overflow when limitting the number of rasterized blobs. r=jrmuizel

Beta/Release Uplift Approval Request

  • User impact if declined: Infinite loop causing the whole browser to hang in some situations (for example a very large SVG with an animated transform on it).
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Run the testcase https://bugzilla.mozilla.org/attachment.cgi?id=9078255 and see if it completely freezes the browser.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): I don't like to request uplifts before a patches has a least a day in Nightly, but the fix is very simple: just cap two numbers to ensure their product don't overflow. The actual values for these numbers aren't critical to correctness.
  • String changes made/needed:
Attachment #9078632 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9078632 [details]
Bug 1566206 - Avoid overflow when limitting the number of rasterized blobs. r=jrmuizel

Beta/Release Uplift Approval Request

  • User impact if declined: In some rare but not impossibly rare cases, the whole browser hangs because of an infinite loop.
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: Run the testcase https://bugzilla.mozilla.org/attachment.cgi?id=9078255 and see if it completely freezes the browser.
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The patch is very simple, the change only affects bad cases where the browser would be likely to hang forever. The values that are changed in this patch aren't affecting correctness.
  • String changes made/needed: None.
Attachment #9078632 - Flags: approval-mozilla-release?

Comment on attachment 9078632 [details]
Bug 1566206 - Avoid overflow when limitting the number of rasterized blobs. r=jrmuizel

webrender hang fix, approved for 69.0b7 and 68.0.1

Attachment #9078632 - Flags: approval-mozilla-release?
Attachment #9078632 - Flags: approval-mozilla-release+
Attachment #9078632 - Flags: approval-mozilla-beta?
Attachment #9078632 - Flags: approval-mozilla-beta+
Flags: in-testsuite?

(Despite bug 1558939 it seems to be possible to force-enable WebRender on ESR 68. For example, we don't know which Linux distributions will entirely exclude WebRender from their builds (bug 1563311 landed in 69) or which users will try it out on Windows. ESR 68 uplift could be desired, too.)

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70
QA Whiteboard: [qa-triaged]

I have managed to reproduce this issue using Firefox 70.0a1 (BuildId:20190715214335) on Windows 10 64bit.

This issue is verified fixed using Firefox 70.0a1 (provided in comment 16), Firefox 68.0.1 (BuildId:20190717172542) and Firefox 69.0b6 (provided in comment 17) on Windows 10 64bit, macOS 10.13.6 and Ubuntu 18.04 64bit.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.