Closed Bug 639129 Opened 14 years ago Closed 13 years ago

High memory usage on wikipedia.org

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: de.techno, Unassigned)

References

Details

(Keywords: memory-footprint, Whiteboard: [MemShrink:P2])

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110111 Gentoo Firefox/4.0b13pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110111 Gentoo Firefox/4.0b13pre Open and close a single wiki page, and it'll soon start eating 200MB. The problem is either back or not resolved. Reproducible: Always
I want to see if I can reproduce this - which wiki page did you use?
http://en.wikipedia.org./wiki/Root_nameserver. Open any page. Right now it's taking 287 mb on this page alone - de 6534 10.6 34.6 835732 331784 ? Sl 15:43 12:40 /usr/bin/firefox It's using 34.6% of ~1GB - total used free shared buffers cached Mem: 936 897 39 0 29 204
Using the mozilla.org nightly build: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre I get 74MB on that page with a fresh profile, which is almost identical to what 3.6.13 (x86-64 Ubuntu build) uses. Also, after the page is fully loaded it uses 0-1% CPU. You seem to have 10.6% CPU, is that while doing nothing after that one page is fully loaded? Can you reproduce your result using a new profile? # mkdir /tmp/newprofile # /usr/bin/firefox -no-remote -profile /tmp/newprofile What result do you get with the latest nightly build from mozilla.org: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/
I'm building from source using live ebuilds from Gentoo overlays. Yes I started FF as a fresh user to see if the problem persists, and it did. I'll rebuild tonight... I did a rebuild a few days ago; the 20110111 is deceiving, I modified it. In reality it's Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre
And yes, CPU usage depends on the processor and it's configuration.
Version: unspecified → Trunk
I recompiled, and the problem persists. Firefox consumes memory equivalent to an OS... even visualization at times takes less memory. I'm forced to quit, I've a copy installed in case the devs want info.
Mozilla/5.0 (X11; Linux i686; rv:2.0b13pre) Gecko/20110309 Firefox/4.0b13pre I am unable to reproduce the issue reported. dE, does this happen only following the instructions in Comment 2 or can you provide other steps to reproduce?
In general with every webpage. I compiled from source... there might be something wrong with my USE flags, apart form the standard, I'm using the Graphite infrastructure from GCC. So I'll try the binaries.
Just to confirm are you all testing using x86_64?
(In reply to comment #8) > In general with every webpage. > > I compiled from source... there might be something wrong with my USE flags, > apart form the standard, I'm using the Graphite infrastructure from GCC. > > So I'll try the binaries. Sorry, I meant CFLAGS. The problem does not persist with the binaries. Can someone state the CFLAGS for the binaries? I use the following - -march=native -O2 -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity
>Can someone state the CFLAGS for the binaries? Run it and enter about:buildconfig in the URL bar.
So, if you build it from scratch using the same CFLAGS as the official Mozilla build, does the problem still occur?
I didn't try that. But I did try -march=native -O2 on GCC 4.5 without any difference. Actually this problem persists with firefox-3.6.* too.
possibly unrelated and likely the wrong bug: But I stumbled about about:memory and absurdly high values for images/content/used/uncompressed and a work-around that may help to pinpoint part of the trouble. For my setup images/content/used/uncompressed seems to grow without bounds (upto several GB!), not being release even on tab-close. Looks like images data are never released in that family of caches Manual work around for me: https://addons.mozilla.org/en-us/firefox/addon/empty-cache-button/ (Of the 5 empty-cache plugins I found, this was the only one to actually clear images/content/*.)
correction to comment 14: now the memory leak visible in about:memory is in gfx/surface/image. So above extension is only half of the solution :(
update: following hints in other bug reports, this finally fixed _MY_ variant of the memory issue (despite using noscript/adblockplus/greasemonkey on linux 64bit): workaround: image.mem.decodeondraw: true # unknown if really required image.mem.min_discard_timeout_ms: 10000 # back to 10s from 120s aka "never"!? Now memory is internally released to firefox for reuse, sufficiently fast as to no longer grow without limits in images/* and gfx/surface/image (just wait 10-20s for the release and reload about:memory).
jakobi: what web page did you see this on?
@nicholas: test it e.g. against one of the mangas at mangafox.com.
jakobi, I spun your comments off into a new bug 658922.
dE, I just tried loading http://en.wikipedia.org/wiki/Root_nameserver with a Linux64 dev debug build. My about:memory output is below. It looks pretty normal to me. In comment 2, which measurement are you referring to when you say 287MB? You haven't given any evidence there's a leak, BTW. That requires at least two measurements with some time (and possibly activity) between them. Perhaps you can clarify (a) what metric you are measuring, and (b) what value you are expecting to see for that metric? Main Process Explicit Allocations 43.74 MB (100.0%) -- explicit ├──23.23 MB (53.11%) -- heap-unclassified ├──14.89 MB (34.04%) -- js │ ├───9.00 MB (20.58%) -- gc-heap │ ├───2.24 MB (05.13%) -- scripts │ ├───1.44 MB (03.29%) -- mjit-code │ ├───0.92 MB (02.11%) -- tjit-data │ │ ├──0.71 MB (01.61%) -- allocators-reserve │ │ └──0.22 MB (00.49%) -- (1 omitted) │ ├───0.46 MB (01.05%) -- object-slots │ ├───0.35 MB (00.81%) -- string-chars │ ├───0.35 MB (00.80%) -- mjit-data │ └───0.13 MB (00.29%) -- (1 omitted) ├───3.24 MB (07.42%) -- storage │ └──3.24 MB (07.42%) -- sqlite │ ├──2.19 MB (05.00%) -- places.sqlite │ │ ├──1.86 MB (04.25%) -- cache-used │ │ ├──0.25 MB (00.58%) -- stmt-used │ │ └──0.07 MB (00.17%) -- (1 omitted) │ ├──0.59 MB (01.36%) -- other │ └──0.46 MB (01.06%) -- (8 omitted) ├───1.20 MB (02.74%) -- images │ ├──1.12 MB (02.55%) -- content │ │ ├──1.11 MB (02.55%) -- used │ │ │ ├──0.99 MB (02.26%) -- uncompressed │ │ │ └──0.13 MB (00.29%) -- (1 omitted) │ │ └──0.00 MB (00.00%) -- (1 omitted) │ └──0.08 MB (00.18%) -- (1 omitted) ├───1.13 MB (02.59%) -- layout │ ├──1.13 MB (02.59%) -- all │ └──0.00 MB (00.00%) -- (1 omitted) └───0.05 MB (00.11%) -- (1 omitted) Other Measurements 596.08 MB -- vsize 93.29 MB -- resident 48.00 MB -- heap-committed 42.18 MB -- heap-used 5.82 MB -- heap-unused 2.74 MB -- heap-dirty
I'll try the hacks and rebuild tonight.
Sorry, the compiles will be delayed cause of a bug in reiser4 or the zen kernel. Do you want me to compile FF 4.0.1 or from GIT?
Sorry, mercurial.
dE: if you can compile from hg.mozilla.org/mozilla-central that'd be great. Or you could grab a nightly from http://nightly.mozilla.org/ which would be easier.
Mats, George and I all failed to reproduce this. I'm tempted to close this as WORKSFORME.
Blocks: mlk-fx4-beta
Keywords: footprint
Summary: Extreme memory leaks still persists. → High memory usage on wikipedia.org
Whiteboard: [MemShrink:P2]
Ok, I'll compile this tonight.
I'm saying again, this problem does not persists with the prebuild binaries, but when compiled from source, either with -march=native -O2 or -march=native -O2 -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity
Mozilla/5.0 (X11; Linux i686; rv:8.0a1) Gecko/20110724 Firefox/8.0a1 dE, please copy-paste everything from about:buildconfig into this bug. Also if you build using these settings, is the problem still reproducible: --enable-application=browser --enable-optimize --enable-update-channel=nightly --enable-update-packaging --disable-debug --enable-tests --enable-codesighs --enable-stdcxx-compat --enable-debug-symbols=-gdwarf-2 --with-ccache=/usr/bin/ccache And what gcc version are you using? Thanks!
Component: General → Build Config
QA Contact: general → build.config
I'm going to close this. It apparently only manifests when built with non-standard build options.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
This issues got fixed with FF 6.
Resolution: INCOMPLETE → WORKSFORME
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.