1.14 KB, application/x-zip-compressed
773.71 KB, image/png
162.10 KB, image/png
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150129030202 Steps to reproduce: Will attach test case shortly (1) Download and unpack .zip file in a temporary folder (2) Open test.html using a clean profile but with popups enabled. (3) Check the memory size of the firefox processes. (4) Choose 1000 repetitions or 2000 or 3000 if you want the effect to be more obvious. Press the "go" button. (5) You should see tabs opening and closing. Wait for this to stop - will take a number if minutes depending on how many repetitions you chose. (6) Check the memory size of the firefox processes. Compare with (4). (7) Restart the browser with e10s disabled and repeat steps 2 to 6. Actual results: With e10s enabled the "plugin container" process gradually got larger, evnetually reaching about 1G after 3000 repetitions. With e10s disabled the single firefox process showed no progressive growth in size, remaining under 300M. Expected results: The memory size with e10s enabled should be of the same order as with them disabled and there should be no progressive growth in memory used.
Created attachment 8556788 [details] Screenshot of the windows task manager after 300 repetitions with E10s DISABLED
Created attachment 8556789 [details] Screenshot of the windows task manager after 300 repetitions with E10s ENABLED
The test case also ran much more slowly with E10s enabled but this may be a consequence of the higher memory use. The screenshots I attached show the timings as well as the memory sizes in the windows task manager.
ni? myself to try to reproduce
Sorry that the test case is rather unwieldy, you need to let it run for a good few minutes. The memory creeps up with E10s enabled. I did try to demonstrate the effect with fewer repetitions by allocating big objects in the tabs that open and close but I was not successful. The process grew more rapidly of course but virtually all the growth was reclaimed by GC. So it has to be a lot of repetitions to see the progressive effect.
Comments 2 and 3 should say 3000 repetitions, not 300
Thanks for the great bug report Duncan. I tried reproducing it in Linux and I wasn't able to. Then I tried it using a nightly build from January 29th, and I was able to reproduce it. We've fixed a couple e10s-specific memory leaks recently, and I think this might have been one of them. Please re-open the bug if you still experience problems.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
Yes, problem is completely cured in version 39.0a1 (2015-03-01). After 3000 repetitions the memory didn't increase at all.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.