Repeatedly refreshing page with svg charts makes memory usage climb

RESOLVED INCOMPLETE

Status

()

Core
SVG
RESOLVED INCOMPLETE
7 years ago
5 years ago

People

(Reporter: Pedro Alves, Unassigned)

Tracking

Trunk
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
Env: MacOS

Browser: Minefield 4.0b8pre

Description:  Open a browser session in safe mode. Visit the page in http://www.webdetails.pt/ccc/pvcTest.html


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.
(Reporter)

Updated

7 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

7 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.
https://developer.mozilla.org/en/Debugging_memory_leaks 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

7 years ago
I was unable to get XPCOM_MEM_BLOAT_LOG to do anything useful ( export XPCOM_MEM_BLOAT_LOG=1;/Volumes/Minefield/Minefield.app/Contents/MacOS/firefox 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: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ 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).
Status: NEW → UNCONFIRMED
Ever confirmed: false
The testcase is no longer there.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.