1488051 - Explosive 15 GB memory and CPU use in FF 61.0.2

Status: RESOLVED DUPLICATE of bug 1476032

(Core :: JavaScript: GC, defect)

Description

[User Dderss]

Attachment: memory-report.json.gz

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

Steps to reproduce:

Just some regular browsing for a prolonged time. Unfortunately, there I do not see specific events that cause it, so the bug is not easily reproducible.


Actual results:

The memory and CPU use explodes to the point of not only the browser becoming unresponsive, but, ultimately, even the OS itself.


Expected results:

Normal continuous operation.

Comment 1

[User Dderss]

Attachment: Task manager screenshot that shows huge memory and CPU usage.png

First I thought that these periodical memory/CPU issues are video playback-related, but I am not that sure any more; I did not have anything playing in this latest case. Looks like a sudden leak of garbage or something like that. Please keep or correct the product/component accordingly.

Comment 2

[User Dderss]

Attachment: At times the huge memory grab periods go away on their own without freezing FF or OS.png

Comment 3

[Steve Fink [:sfink] [:s:]]

Relevant portions of that about:memory dump:

The main process is 4GB. 1.7GB of that is js-non-window, of which 1GB is strings. 1GB is heap-unclassified. 800MB structured-clone-holder.

One 2.7GB content process, with the memory smeared all over. (370MB heap-unclassified.)

Another slightly larger 2.7GB content process, again spread around.

A 1.2GB WebExtensions process (!), mostly in a single window, and most of that in string data.

23 extensions, including some pretty sophisticated ones.

It would be great if you could figure out how to reproduce it reliably enough that you could try in safe mode (all extensions off) and see if it goes away, and if so, bisect through the extensions. Does the usage climb more when idle or when active?

Comment 4

[Steve Fink [:sfink] [:s:]]

Also, given that you have the Gecko profiler installed, it would be interesting to see what was happening when the CPU usage spikes. Are you running with the profiler active? If so, please add a profile link. Although the CPU usage might be a side effect of the enormous memory usage.

Comment 5

[User Dderss]

The issue is that when this resource grab happens it is so debilitating to the UI that I barely have time to create a new tab and enter "about:memory" there before things go VERY BAD -- this is because not only all of my physical memory gets allocated but also 50 GB swap file space on by "C:" flash memory drive. It literally killed the OS on me once when I did not expect it. After that case, I try to close the browser as fast as possible to at least avoid OS reboot.

Starting monitor in these circumstances would be all but impossible as UI freezes appear pretty quickly.

Do you guys have a key for "firefox.exe" that would allow for "Measure and save" operation to include more details from where it could be derived which script causes the leak without the necessity to run the dead-heavy monitor?

I guess no, so the only thing left is to try to use the monitor and hope I will still have the UI responsive to stop it, save it, and close FF before it is too late.

Comment 6

[Andrew McCreight [:mccr8]]

Kris, wasn't there some existing bug about web extensions and using a lot of structured clone holder memory? Could you dupe this over to that? Thanks.

Comment 8

[Kris Maglione [:kmag]]

Urgh. We really need to stop anonymizing moz-extension: URLs... It would be really helpful to know what this window in the extension process is:

│    ├──884,218,185 B (67.73%) -- top(<anonymized-10737418363>, id=10737418361)

I'd guess that that add-on is responsible for most of the issue.

Comment 9

[Andrew McCreight [:mccr8]]

Could you let us know which extension is showing a lot of memory?

Comment 10

[User Dderss]

The extension in that place is Ad Block Plus, but considering the huge number of I have it can normally take up to 1 GB. The blowing up happens somewhere else.

Comment 11

[User Dderss]

Attachment: FireFox repeatedly "forgets" to draw a half of the page.png

Do you guys see this phenomenon?

Does it mean that the rendered has begun to get tired currently?

Reloading this page (F5) has helped to restore the visuals of the lower part of the page.

Comment 12

[User Dderss]

Sorry, I skipped the word: "... but considering the huge number of TABS I have it can normally..."

Comment 13

[Andrew McCreight [:mccr8]]

That looks like a painting issue. Maybe it can happen if memory is running low? I'm not sure.

Comment 14

[User Dderss]

Attachment: Firefox 2018-09-06 18.02 profile.sps.json.gz

I managed to record a bit during a huge memory/CPU use peak.

Comment 15

[User Dderss]

I have a much bigger recording file, so if you want I can upload it too, but I guess it will be just more of the same thing.