1778237 - Firefox eats up memory and hangs on the certain page. (Seems to be fixed by gpu-canvas)

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect, P1)

Description

[Alice0775 White]

Steps to reproduce:

1. Open https://isekai-yakkyoku.jp/ and wait for page loading
2. Click playback button

Actual results:
Firefox102.0.0 and Nightly104.0a1 eats up memory and Hangs. OS also becomes unresponsive.
Chrome works as expected and has low memory consumption.
Firefox 91.11.0 play video sometimes normally but peak memory usage is very large, almost 100% of physical memory.
No problem when playing the original embedded video on youtube site.

Expected results:
Playback correctly

Comment 1

[Mayank Bansal]

This is a Canvas2d bug.

I can repro with Nightly. The RAM use in the GPU process increases continuously till OOM. But if I enable accelerated Canvas, the bug doesnt repro.

So this bug is essentially "fixed by gpu-canvas"

Comment 2

[Alice0775 White]

Attachment: about:support

Comment 3

[Alice0775 White]

Attachment: memory-report.json.gz

Comment 4

[Alice0775 White]

(In reply to Mayank Bansal from comment #1)

This is a Canvas2d bug.

I can repro with Nightly. The RAM use in the GPU process increases continuously till OOM. But if I enable accelerated Canvas, the bug doesnt repro.

So this bug is essentially "fixed by gpu-canvas"

Yes, the animation of some Canvas elements, not the video playback, is causing this problem.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:aosmond, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 6

[Kelsey Gilbert [:jgilbert]]

@lsalzman: What do you think here? S3?

Comment 7

[Lee Salzman [:lsalzman]]

On Windows without accelerated canvas enabled, we would be using Direct2D. The bug doesn't repro on Linux at least with accelerated canvas on or off, which further points at Direct2D being the issue at hand.

I don't see anything in the attached memory report that super strange, though the gpu-committed stat using 5GB in the GPU process is maybe a bit suspicious. I would suspect we're creating a lot of D3D textures to present the canvas frames, and those are not getting recycled nicely or leaking somehow? Sotaro, any thoughts here?

Comment 8

[Sotaro Ikeda [:sotaro]]

Attachment: add log

With the patch, I conformed that more than 6000 SourceSurfaceD2D1 with Size(1284, 711) were created by DrawTargetD2D1::OptimizeSourceSurface(). And when original DataSourceSurface was returned instead of creating a new one, memory increase did not happen.

Then dc->CreateBitmap() in DrawTargetD2D1::OptimizeSourceSurface() seemed to consume memory.

Comment 9

[Sotaro Ikeda [:sotaro]]

:bobowen, can you comment to the bug?

Comment 10

[Bob Owen (:bobowen)]

First thing I've tried is turning off remote canvas (have to turn off win32k lockdown as well to still use acceleration).
Seems to give very similar problem, but just in the content process.
I'll investigate further.

Comment 11

[Bob Owen (:bobowen)]

Attachment: Bug 1778237: Hold weak reference to optimized surfaces in DrawTargetRecording, to allow reuse. r=lsalzman!

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/11cf9f3daba8
Hold weak reference to optimized surfaces in DrawTargetRecording, to allow reuse. r=lsalzman

Comment 13

[Serban Stanca [:SerbanS]]

Backed out for causing multiple failures with ThreadSafeWeakReference.

• Backout link
• Push with failures
• Failure Log
• Failure lines: TEST-UNEXPECTED-FAIL | layout/reftests/canvas/text-no-frame-test.html | application terminated with exit code 245
  REFTEST PROCESS-CRASH | layout/reftests/canvas/text-no-frame-test.html | application crashed [@ RefPtr<mozilla::detail::ThreadSafeWeakReference>::assign_assuming_AddRef(mozilla::detail::ThreadSafeWeakReference*)]

Comment 14

[Bob Owen (:bobowen)]

The problem on autoland is because this check has always been wrong, because other surface classes can return RECORDING type (at least SourceSurfaceCanvasRecording, it happens to work for that class on 64-bit).
We can use HasStoredObject instead as long as we do the user data check first, otherwise we would incorrectly return RECORDING surfaces from another recorder that we had already optimized and therefore stored in our recorder.

Comment 15

[Bob Owen (:bobowen)]

https://treeherder.mozilla.org/jobs?repo=try&revision=4ed390d393be8064ff675972bdaa1bdcd48a3563

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c712aa232d79
Hold weak reference to optimized surfaces in DrawTargetRecording, to allow reuse. r=lsalzman

Comment 17

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/c712aa232d79

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:bobowen, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox107 to wontfix.

For more information, please visit auto_nag documentation.

Comment 19

[Bob Owen (:bobowen)]

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #18)

The patch landed in nightly and beta is affected.
:bobowen, is this bug important enough to require an uplift?

Given that this has been in release for a while, it seems reasonable to assume that things triggering the issue are rare.
The fix is not totally trivial and it bounced on landing due to a previous bug, so I'd be inclined to let this just ride the trains.

Alice - do you have any idea as to whether this is a more widespread problem, that might justify an uplift?

Comment 20

[Alice0775 White]

It appears to be an issue only with this site and the 108 release is coming soon.
Also, I doubt that many ESR users will visit this site.
Therefore, I do not think there is a need for uplift.

Comment 21

[Bob Owen (:bobowen)]

Thanks

Comment 22

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! Reproduced the issue with Firefox 104.0a1 (2022-07-15) on Windows 10x64. After loading the page and scrolling it a bit the RAM memory increases very rapidly to the maximum for the Firefox process.
Using Firefox 108.0b2 on Windows 10x64, macOS 11, and Ubuntu 20.04 and visiting the webpage from comment 0 will keep the memory usage stable while scrolling the webpage and the video is playing.