1558436 - Runaway memory in www.247mahjong.com, regression

Status: RESOLVED DUPLICATE of bug 1558100

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

Description

[Mark]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

1. Create a new Nightly profile and use Firefox against the profile to ...
2. Run http://www.247mahjong.com/
3. If advertisement page presented, click on X to get to the game.

Actual results:

After playing the game for a short while (maybe up to half of the game), one of these occurs:

• Tab Crash (usually no dump)
• Firefox crashes (usually no dump)
• The complete Windows 10 (64-bit) crashed once (was running mozregression-gui)

Also noticed during game play that the Windows Task Manager shows a steady increase in memory usage with some dips (probably garbage collection) until the tab/Firefox/Windows crashes.

Sample crashes:
https://crash-stats.mozilla.org/report/index/14f9a7c4-f16f-4f77-8f40-b71cd0190610
https://crash-stats.mozilla.org/report/index/adb1cb6f-64a2-401e-aa79-bc2d90190610
https://crash-stats.mozilla.org/report/index/8b46c21e-1bfb-4113-8ef5-db03b0190611

Expected results:

Until a few days ago, I could play a number of games at http://www.247mahjong.com/ without incident.

Comment 1

[Mark]

mozregression-gui log ends with:

2019-06-11T03:11:15: DEBUG : Found commit message:
Bug 1556340 - Make D3D11TextureData and DXGIYCbCrTextureData alive during host side usage with WebRender r=nical

By Bug 1555544 , it became clear that D3D11TextureData and DXGIYCbCrTextureData should not be deleted before calling RenderDXGITextureHostOGL::EnsureLockable() / RenderDXGITextureHostOGL::EnsureLockable().

With WebRender, the EnsureLockable()s are called on RenderThread asynchronously. Then for achieving the above, it is simpler just to keep D3D11TextureData and DXGIYCbCrTextureData alive during host side usage.

There is already a mechanism to do it. By using NotifyNotUsed, it could be done.

Differential Revision: https://phabricator.services.mozilla.com/D33469

2019-06-11T03:11:15: DEBUG : Did not find a branch, checking all integration branches
2019-06-11T03:11:15: INFO : The bisection is done.
2019-06-11T03:11:15: INFO : Stopped

The bisection information shows:

app_name: firefox
build_date: 2019-06-06 02:51:45.923000
build_file: C:\Users\Mark.mozilla\mozregression\persist\eca88f6069a7-shippable--autoland--target.zip
build_type: inbound
build_url: https://queue.taskcluster.net/v1/task/Rzh3Td0MRQOpAFARhui10g/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: eca88f6069a7859a93bf064f8274a4df919091c0
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=0d39f4b9fe604540219c755ff6d1b95c91c9a89c&tochange=eca88f6069a7859a93bf064f8274a4df919091c0
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: Rzh3Td0MRQOpAFARhui10g

Comment 2

[Mark]

Attachment: about_support_1558436.txt

about_support_1558436.txt is the about:support for the brand new profile with which I was able to reproduce the tab/firefox crashes.

This is Windows 10 Home (64-bit), version 1903, OS build 18362.145. I also updated the Intel and HP drivers before running the regression.
CPU is Intel i5-7400 (4-core) with Intel HD Graphics 630. 12GB RAM.

Comment 3

[Mark]

Additional observations:

When I turned off "hardware acceleration" the problem went away.

When demonstrating the problem, it doesn't appear to be necessary to actually play the game; without playing (but still on the game screen), Firefox appears to grab 1% of the total memory a bit faster than once a second.

A quick-and-dirty run of the Gecko Profiler, hopefully capturing something useful: https://perfht.ml/2R4tD3v

Comment 4

[Jim Jeffery not reading bug-mail 1/2/11]

Confirming setting to NEW
Win 10 build 1903 May update.

From Computer Management Console-> System
Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: firefox.exe (11516) consumed 354996224 bytes, firefox.exe (2272) consumed 178794496 bytes, and firefox.exe (4264) consumed 175439872 bytes.

Comment 5

[Sotaro Ikeda [:sotaro]]

It seems similar to bug 1558100. D3D11TextureData is created very often in CanvasClient2D::Update(). See bug 1558100 comment 2.

Comment 6

[Jessie [:jbonisteel] pls NI]

Sotaro, I will assign this to you for now to verify if the fix for bug 1558100 helps here too

Comment 7

[Mark]

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #4)

...
Win 10 build 1903 May update.
...

Problem was also happening before the 1903 May update. (I had applied Windows, HP, and Intel software maintenance to current before running mozregression.

Comment 8

[Mark]

Just tested in Nightly Build-id 20190613095633 and this Bug appears to be fixed with the fixing of Bug 1558100.

Comment 9

[Jim Jeffery not reading bug-mail 1/2/11]

Confirming, played a whole game - no crashes or abnormal memory use that I could see.

Comment 10

[Darkspirit]

Thanks for the confirmation.