1436848 - gpu-commited memory leak in github.com pdf viewer

Status: UNCONFIRMED

(Core :: Graphics, defect, P3)

Description

[1]

Attachment: memory_reports_and_about_support.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

using i5-2410M (attached about_support.txt), in case if it is driver related.

1. Push any pdf into github repository, or use the one that I have provided with 3 typical files, of different sizes and behaviours.
https://github.com/jnk0le/firefox_memory_leak_test

2. Go to github webpanel and just open pdf through their javascript pdf viewer (do not use browser's builtin viewer)

3. Mess with this up. (refreshing, multiple "open in new tab", going back and forth, and loading more than 50 pages of long datasheets).

4. Kill "affected" tabs.


Actual results:

Enormous memory usage in all of the tested browsers with folowing differencies;

Edge: 
- always releases memory except when I use "go back" button.
- majfriend_watermarked.pdf mostly crashes (page unresponsive, memory released after killing tab)

Chropera:
-Releases memory only when I kill "affected tab".
-Leak doesn't stack while refreshing.

FF:
- Doesn't release memory automatically (especially when using 12GB out of 6GB physical memory)
- 3 to 10 minutes after killing "affected" tabs I can get back to normal usage by doing "Minimize memory usage" button in about:memory.
- also majfriend_watermarked.pdf rendering is rendered extremly long (single thread 100% usage, just scroll down to last page and wait).

attached:
memory-report_before.json.gz 
- long.pdf opened up to page 600 in one tab.

memory-report_after.json.gz 
- few minutes after closing tab.

memory-report_after_minimize_memory.json.gz
- after doing "Minimize memory usage" button in about:memory.


Expected results:

1. Memory should be released after tab kill.
2. 2 megabyte PDF should not make 2+ gigabyte of memory usage.

Comment 1

[1]

I have managed to get auto kill of leaking firefox.exe process by not opening/activating more than one tab in addition to the leaking one.

Comment 2

[1]

Starting firefox on gt520M:

- at first time, some pages were hung in a "blank page loading" state for a few minutes.
- Visible stuttering while scrolling.(absolutely random - stutters for first 5 minutes and gets normal for another 3 minutes)
- didn't fix the leak.

Comment 3

[1]

It's not about FF pdf.js

Comment 4

[1]

After updating nvidia driver from 390.65 to 390.77, I noticed that when tab playing YT videos, somehow assigned to leaking process, autoplays another video, it clears leak in this exact process.

Comment 5

[Milan Sreckovic [:milan] (needinfo for best results)]

Andrew, can you take a quick look as to where the memory is going?  If this is eventually getting released, it sounds more like caching than leaking?

Comment 6

[Sotaro Ikeda [:sotaro]]

Bug 1432086 might be similar bug.

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

On Linux it all goes to heap-unclassified, and gets freed a short period (< 30 seconds) after closing the tabs. I tested setting dom.ipc.processCount to 1 to ensure it wasn't simply just tearing down the process.

On Windows, it is all in gpu-commited memory, which is gotten via D3DKMTQueryStatistics. That API isn't documented, so it isn't clear to me what the caveats are.

Since the memory minimize has an impact, it is probably the font cache, the texture cache/pools, or the gradient cache causing the problem. The texture pools should automatically clear themselves after 5 seconds of inactivity (short of the timer failing to arm due to OOM), and I'd be surprised if the fonts took this much. So perhaps Sotaro is right, since bug 1432086 has gradient related issues.

Comment 8

[Sotaro Ikeda [:sotaro]]

The leak seems to happen with DrawTargetD2D1 backed 2d Canvas. When I changed gfx.canvas.azure.backends to "skia,cairo", I did not saw the high gpu-commited memory.

Comment 9

[Sotaro Ikeda [:sotaro]]

Ah, Bug 1432086 seems like a different bug. In Bug 1432086, memory did not decrease even with "Minimize memory usage" button in about:memory.

Comment 10

[1]

It looks like crash reports are generated when memory gets released.

Those have to be manually submitted by the way.

https://crash-stats.mozilla.com/report/index/1c88dde3-0c79-4971-b056-dc2d10180614
https://crash-stats.mozilla.com/report/index/ec893215-b922-42ef-a4bd-96b920180614
https://crash-stats.mozilla.com/report/index/8adbb29f-b4c6-41a6-b8cb-6b9ac0180614

Comment 11

[1]

Attachment: memory-report.json.gz

This time I was able to "minimize" only part of memory (and generate crashes).
The rest in this file is a hard leak.

Comment 12

[1]

Comment on attachment 8985468 [details]
memory-report.json.gz

I didn't "minimized" but closed all tabs except a one or two. It was not able to minimize anything more than 100MB.

Comment 13

[1]

And another ones when closing browser with a leak:

https://crash-stats.mozilla.com/report/index/cf1cc60d-348e-480a-8763-71b950180614
https://crash-stats.mozilla.com/report/index/b20076a5-ece7-4be7-933e-c21a70180614
https://crash-stats.mozilla.com/report/index/b58994f0-06af-4f8e-9eba-f29d40180614
https://crash-stats.mozilla.com/report/index/cb03df32-d497-4b8a-b84a-5de9e0180614
https://crash-stats.mozilla.com/report/index/e13d6cbd-19ad-4949-9205-d2dcf0180614

Comment 14

[1]

Nightly 62.0a1 seems to properly deallocate that memory.

Comment 15

[1]

(In reply to jan from comment #14)
> Nightly 62.0a1 seems to properly deallocate that memory.

Unless leak is large enough to start swapping, then it will not auto release.