Closing a PlayCanvas tab before loading leaks memory




5 years ago
3 years ago


(Reporter: andrei.eichler, Unassigned)


32 Branch

Firefox Tracking Flags

(Not tracked)




(3 attachments)



5 years ago
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 (Beta/Release)
Build ID: 20140604030202

Steps to reproduce:

Measure memory in about:memory

Close accelerally tab
Measure memory

Open accelerally in a new tab

Measure memory again

Actual results:

When one refreshs the accelerally tab the memory consumption rises.
When one closes the accelerally tab, the memory isn't freed

Expected results:

When the tab is closed, the consumed memory of that tab should be freed

Comment 1

5 years ago
Most memory goes to : window/js-compartment/objects/non-heap/elements/asm.js
Memory is not necessarily freed immediately. You might need to wait for it to be collected. You can also hit "minimize memory" in about:memory instead of waiting. I can't seem to reproduce the bug when I do that.

Comment 3

5 years ago
Another issue, but probably hardware related, the demo never loads, seems to stall the loading at ~90%.

I'm using CentOS with Mesa 9.2.

I'll try to reproduce the bug in another PC later

Comment 4

5 years ago
Created attachment 8434358 [details]
About:support info

About:support info

Comment 5

5 years ago
Tested on another machine and it works fine, the game load successfully and after closing the tab the memory is freed after a few seconds.

What can I do to help on this bug?

Linux version, dmesg log, mesa version, record a video of the bug?
Component: Untriaged → Canvas: WebGL
Product: Firefox → Core
Is this still about a memory leak, or about the demo not loading?
You're probably right, so feel free to change the component as you think.

Comment 8

5 years ago
I believe the fact the demo not loading causes the leak, seems like some compilation stalls/hangs and cause the leak.

I tried other demos like the titanfallviewer (, which completes the loading, renders correctly and doesn't eat up my memory.

What can I attach here to help triage the bug?
I would write out a very clear list of steps that you take, that let you reproduce the bug consistently on your machine (including running "minimize memory" in about:memory, and still seeing a leak afterwards). Then we can try to reproduce.

Comment 10

5 years ago
Ok, here are the step with screenshot and about:memory measures:

I always let my browser with "Never remember history" configured, don't know if that affects something.

1) Open
2) For some reason the loading stalls at that point on the screenshot
3) Measure memory
4) Close the tab, wait for ~30s and measure memory again
5) Click on minimize memory, wait a for ~30s and measure memory
6) Reopen tab and measure
7) Refresh tab and measure
8) Refresh several times and measure

Comment 11

5 years ago
Created attachment 8436878 [details]

Loading_bar.png shows the point where the loading stalls
memory-report.json.gz is the measure of the 3rd step
memory-report_after_close.json.gz is the measure of the 4th step
memory-report_after_minimize.json.gz is the measure of the 5th step
memory-report_after_open_again.json.gz is the measure of the 6th step
memory-report_after_refresh.json.gz is the measure of the 7th step
memory-report_after_several_refresh.json.gz is the measure of the 8th step
I can't reproduce the stall over here.

Do you see anything in the web console when it stalls? Can you see if on different browsers and browser versions you see the same?

Comment 13

5 years ago
Worked on Firefox 24.5 ESR
Doesn't work with add-ons disabled
Doesn't work resetting firefox

When trying debugger with "pause on exception", it crashes

Comment 14

5 years ago
Created attachment 8437787 [details]

Log of stalled demo
No stall here using current 64bit nightly build on win7

Can you still reproduce?
Flags: needinfo?(andrei.eichler)
Whiteboard: [closeme 2016-06-15]

Comment 16

3 years ago
Resolved per whiteboard
Last Resolved: 3 years ago
Flags: needinfo?(andrei.eichler)
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2016-06-15]
You need to log in before you can comment on or make changes to this bug.