Repeatedly refreshing page with svg charts makes memory usage climb




8 years ago
6 years ago


(Reporter: pedro.alves, Unassigned)



Firefox Tracking Flags

(Not tracked)




8 years ago
Env: MacOS

Browser: Minefield 4.0b8pre

Description:  Open a browser session in safe mode. Visit the page in

Keep doing refreshes on that page. Check about:memory and see the memory going up. I got it to over 1Gb, and during this bug report the memory mapped is 400Mb (in safe mode). I can see the stair-stepping-but-trending-up effect.

I tested the same in firefox 3.6.10 and I *can not* reproduce this, so appears to be minefield only.


8 years ago
Component: General → SVG
Product: Firefox → Core
QA Contact: general → general
(In reply to comment #0)
> I can see the stair-stepping-but-trending-up effect.

Just to elaborate -- by this, Pedro means (from talking to him in IRC) that his memory usage would increase gradually, and then fall off suddenly when we free a bunch of stuff -- but the baseline usage would still continue trending upwards.

Comment 2

8 years ago
At Pedro's request I tested this on my machine (Also a Mac, 10.6.4). The baseline "Memory In Use" number is definitely higher in beta 6 than in the beta3, and in beta8pre than in beta6, but it consistently clears gets released to that baseline. Memory Mapped seems to slowly raise in beta6, but grow much faster (albeit not _quite_ as fast as for Pedro) on beta8pre. We're talking about 300 megs with just two tabs (the supplied link and about:memory) open. shows how to deterine whether there really is a memory leak. If you set XPCOM_MEM_BLOAT_LOG in a shell, run the browser from that shell, display the page and then shutdown the browser does it say that there are any leaks?

Comment 4

8 years ago
I was unable to get XPCOM_MEM_BLOAT_LOG to do anything useful ( export XPCOM_MEM_BLOAT_LOG=1;/Volumes/Minefield/ yielded no output to stdout, and about:bloat didn't work), but I did try disabling hardware acceleration, which did NOT yield any changes.
I can't see any leaks with the leak tools. This seems possibly just memory churn.

There's a couple of ways to move forward if you want this confirmed as a leak.

a) simplify the test case. Is it one specific kind of content or javascript that causes the memory to not be entirely returned.

b) since 3.6.10 seems to show better memory recovery, figure out what day things changed. You can download nightly builds from here: look in the mozilla-central directories and determine the last build that shows firefox 3.6.10 behaviour and the first build that doesn't (hopefully 1 day apart).
Ever confirmed: false
The testcase is no longer there.
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.