Open Bug 1405336 Opened 7 years ago Updated 2 years ago

Memory useage doesn't clear with browser refresh

Categories

(Core :: DOM: Core & HTML, defect, P2)

56 Branch
defect

Tracking

()

UNCONFIRMED
Tracking Status
firefox57 --- fix-optional

People

(Reporter: kanemason, Unassigned)

Details

(Whiteboard: [MemShrink:P3])

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce:

We develop online games and noticed with the Firefox 56 upgrade, upon refreshing the game, the memory useage in the task manager didn't drop off and start to climb from where it was before the refresh. 


Actual results:

The memory useage stayed at what is was previously, and the memory climbed from that point to effectively double. The issue is recursive and the memory will climb the more you refresh and eventually the game is un-playable due to the performance impact of high memory useage


Expected results:

Upon refresh, firefox should release memory it is holding for the current page, and build up memory from fresh as the page loads.
Whiteboard: [MemShrink]
Hi Kanemason,

Could you please provide a link to one of these games so we can try to reproduce the issue you are experiencing? 

Also, could you please try to reproduce the issue with a new clean Firefox profile (https://goo.gl/AWo6h8), maybe even safe mode (https://goo.gl/AR5o9d), to eliminate custom settings as a possible cause.
Flags: needinfo?(kanemason)
Hi,

Here is a link to one of our customers lobbies. Please play Jurassic World on "Demo Play". Once loaded into the game, refresh and repeat. Notice memory climbs, and climbs.

32red.co.uk 

We are also experiencing webGL errors where the animations are pitch black with the following warning in the console 

Error: WebGL warning: drawElements: Active texture 0 for target 0x0de1 is 'incomplete', and will be rendered as RGBA(0,0,0,1), as per the GLES 2.0.24 $3.8.2: The dimensions of `level_base` are not all positive.
Flags: needinfo?(kanemason)
[bugday-20171009]

Great! (sarcasm) Access to this website is blocked in my country.
(In reply to Paul Graphonium from comment #3)
> [bugday-20171009]
> 
> Great! (sarcasm) Access to this website is blocked in my country.

Which country are you in? I can try find you a local link
Flags: needinfo?(paul-petrovka)
Attached file memory-report.json.gz
Thanks for the link Kanemason.

I was able to reproduce the issue on the latest Nightly 58.0a1 on Windows 10 x64, Arch Linux x64 and Mac 10.12.

After the game is loaded, memory usage stays at ~600MB, after a refresh it reaches 900MB, it does go down after a while, but refreshing again will make the memory usage reach ~900MB.
I took a gecko profile: https://perfht.ml/2wKMBkL
I also attached a memory report taken from about:memory.

Mike, could you please look over the reports and help me find a suitable component for the issue?
Flags: needinfo?(mconley)
Russia.
Flags: needinfo?(paul-petrovka)
Yep, I see some detached ("ghost"?) windows in the about:memory report.

As per usual though, my abilities to read about:memory reports aren't super-sharp, so I'm going to see if erahm is able to draw anything actionable out of this.
Flags: needinfo?(mconley) → needinfo?(erahm)
Andrew can you look at this? It sounds like this might be cycle collector related but it's hard to tell.
Component: Untriaged → DOM
Flags: needinfo?(erahm) → needinfo?(continuation)
Product: Firefox → Core
Priority: -- → P2
Whiteboard: [MemShrink] → [MemShrink:P3]
Sorry, I have been unable to prioritize this enough to look at it.
Flags: needinfo?(continuation)
Component: DOM → DOM: Core & HTML
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: