High memory usage on wikipedia.org



8 years ago
2 months ago


(Reporter: de.techno, Unassigned)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [MemShrink:P2])



8 years ago
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?

Comment 2

8 years ago

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:

Comment 4

8 years ago
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

Comment 5

8 years ago
And yes, CPU usage depends on the processor and it's configuration.
Version: unspecified → Trunk

Comment 6

8 years ago
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.

Comment 7

8 years ago
 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?

Comment 8

8 years ago
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.

Comment 9

8 years ago
Just to confirm are you all testing using x86_64?

Comment 10

8 years ago
(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?

Comment 13

8 years ago
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.

Comment 14

8 years ago
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: 

(Of the 5 empty-cache plugins I found, this was the only one to actually
clear images/content/*.)

Comment 15

8 years ago
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 :(

Comment 16

8 years ago
update: following hints in other bug reports, this finally fixed _MY_ variant of the memory issue (despite using noscript/adblockplus/greasemonkey on linux 64bit): 


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?

Comment 18

8 years ago
@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

Comment 21

8 years ago
I'll try the hacks and rebuild tonight.

Comment 22

8 years ago
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?

Comment 23

8 years ago
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: 659855
Keywords: footprint
Summary: Extreme memory leaks still persists. → High memory usage on wikipedia.org
Whiteboard: [MemShrink:P2]

Comment 26

8 years ago
Ok, I'll compile this tonight.

Comment 27

8 years ago
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

Comment 28

8 years ago
 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?

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.
Last Resolved: 8 years ago
Resolution: --- → INCOMPLETE

Comment 30

8 years ago
This issues got fixed with FF 6.


2 months ago
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.