95810 - runaway memory consumption

Status: RESOLVED DUPLICATE of bug 143046

(Core :: Graphics: ImageLib, defect)

Description

[Paul LeMahieu]

Go to the page above with the Linux 0.9.3 version, and it starts
consuming memory like crazy, and killing Mozilla seems the only option.
I'm running a stock Linux Mandrake 7.2, but Mozilla under Windows
seems to behave pretty badly on this page as well.

Comment 1

[Ashley Bischoff (blog at handcoding.com)]

Confirming on Win2k 2001081303. Yikes!

OS -> All.

Comment 2

[RFLazaro]

i am using build 2001082608 on WinNT and i tried to load the page mentioned
mozilla's memory consumption just skyrockets

ie 5.5 -> 77M
opera 5.12 -> 32M
mozilla -> 350M

if mozilla is to be accepted by people at large someone should look into these
memory consumption problems asap

Comment 3

[Matthias Versen [:Matti]]

confirming with win2k build 20011103..

-> Imagelib (I know that stuart loves this kind of bugs)

Mozilla use more than 400MB during the load of this page !
If I disable image loading mozilla use only 16kb.

Comment 4

[Markus Hübner]

confirming on win2k - bulid 2001110103
any clues so far?

Comment 5

[Terri Preston]

Memory usage does reach 100% with win xp build 2001111603

Comment 6

[Dom Incollingo]

Confirming on Win 2K with build 2002011803.  I have 512 MB of RAM.  Trying to
load this page drove Mozilla memory consumption up to 300 MB before I terminated
Mozilla with Windows Task Manager.

Comment 7

[Gregory McLean]

Got a mozilla that was 414 megs big, page did display, memory was released on
closing window that had this page loaded (moz was still running) This is all
with Mozilla 0.9.8 on RH 7.2 (Linux)

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

can't reproduce here. memory usage is, like, 40 MB or so. Linux 2002051715.
interestingly, after the page was fully loaded, memory usage shrank by 10-20 MB.

Comment 9

[Cees T.]

Trunk build 2002060808 on WinME + cable connection:

Max 357MB(looks like all my swap space) allocated memory while loading, of which
about 157MB in memory and 20MB in use. When loading the page again (not reload),
Mozilla allocates less memory and stores more in it.

Mem usage slowly drops while scrolling and drops back to about 20 MB (allocated,
stored, and in use) after closing the window.

The page takes up to 100% CPU (PIII 900) usage while loading or scrolling and
took 74 to 51 (and dropping) seconds to load.

Comment 10

[Michael Rothwell]

I'm running Mozilla 1.0 on Redhat, and this happens all the time. I keep a 
terminal  
window open with "killall mozilla" at the ready. Even searching on google can  
cause this to happen. It looks like mozilla hangs, and starts abusing XFS  
(font server). XFS bloats up until it exhausts the machine's memory and gets  
killed. X is then hosed, of course, because there's no font server running.  
So, I restart XFS, fire up Konqueror, and try the site I was wanting to see  
again.  
  

Comment 11

[Andy]

My system spec:
T-Bird 700
256MB PC133
Asus A7V
Asus GeForce 3 Ti200 128MB
Win2k Pro SP3
Updated drivers: VIA 4in1, DirectX..etc.
Running Apps:
Mozilla 1.2.1(20021130)

I have similar problem but the memory consumed just more than reasonable to me.
 It keeps consuming 33MB to 40MB with one or more tabs opening with mostly text
based web sites.  For just a browser, I believe that it should consume around
15MB or even less except for some heavily constructed web sites.

Comment 12

[Matthias Versen [:Matti]]

[e-mail]: you post doesn't belong in this bug. This is about a special
testcase and not general high memory. (and such a bug would be invalid)

Comment 13

[Simon Strandman]

Firefox 1.5 still suffers from this problem. When first opening the link memory usage grows to about 400mb. Then it shrinks to about 300mb when scrolling the page. FYI opera uses 30mb on the same page.

Comment 14

[Alfred Kayser]

This is actually very simple. The page referred contains a number of GIF images which are 1bit deep, but enormous in width and height (upto 4000x4000 pixels).
Mozilla internally keeps images in ARGB format (for Cairo), with 32bits per pixel.

So, this means that the compressed copy (±16K - 130K) get expanded to upto 32bits*4000*4000 = 64MB per image. This all explains the usage of around the ±350-400MB for this page.

Note that the page also resizes the images to a much smaller version.

In Mozilla the whole image is kept in original format, but only resized in display.

So, two measures possible:
1. Store 1bit images as 1bit internally
2. Store resized (shrunk) images internally only in the smaller size (resize once)

Comment 15

[Cees T.]

Comment 14: Sounds like a sibling/duplicate of bug 143046 then.

Comment 8 says that this doesn't happen on Linux. Driver issue? These are my Linux test results:

K/Ubuntu 6.10 on a Celeron with 512-64 MB RAM.
KDE 3.5.5 on Xorg's X Window System Version 7.1.1
cees@pandora:/$ fglrxinfo
display: :0.0  screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON XPRESS Series Generic
OpenGL version string: 2.0.6011 (8.28.8)

No before stats, sadly. But i think Firefox (2.0.0.2, btw) was using 223 MB RAM (not sure which).

Page loaded (opened link in new window via context menu):

top - 18:07:17 up 20 days,  3:42,  5 users,  load average: 1.54, 2.49, 1.82
Tasks: 117 total,   2 running, 115 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3%us,  0.3%sy,  0.0%ni, 95.7%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    450736k total,   444980k used,     5756k free,      824k buffers
Swap:  1132540k total,  1023488k used,   109052k free,    27680k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2241 cees      16   0  401m 193m  12m R  1.3 43.9  57:35.13 firefox-bin
 8690 root      15   0  782m  90m 3208 S  2.0 20.6 259:30.23 Xorg
 3959 cees      15   0 74932  21m 7168 S  0.0  4.8  14:52.93 kate

Scrolled to bottom:

top - 18:10:34 up 20 days,  3:46,  5 users,  load average: 1.23, 2.00, 1.76
Tasks: 117 total,   3 running, 114 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.0%us,  1.0%sy,  0.0%ni, 60.7%id, 36.0%wa,  0.3%hi,  0.0%si,  0.0%st
Mem:    450736k total,   445096k used,     5640k free,      268k buffers
Swap:  1132540k total,   983676k used,   148864k free,    22152k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 8690 root      15   0  782m 202m 3268 S  0.7 46.1 259:37.06 Xorg
 2241 cees      15   0  402m 104m 9.9m S  2.0 23.7  57:38.10 firefox-bin
 3959 cees      15   0 74932  18m 5648 S  0.0  4.3  14:53.75 kate

Closed:

top - 18:16:55 up 20 days,  3:52,  5 users,  load average: 0.82, 1.63, 1.72
Tasks: 117 total,   1 running, 116 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.3%us,  0.3%sy,  0.0%ni, 93.3%id,  2.7%wa,  0.0%hi,  0.3%si,  0.0%st
Mem:    450736k total,   445292k used,     5444k free,      368k buffers
Swap:  1132540k total,   994200k used,   138340k free,    27348k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2241 cees      15   0  405m 210m  11m S  2.0 47.9  57:47.66 firefox-bin
 8690 root      15   0  779m  96m 3352 S  1.3 21.9 259:41.62 Xorg
 3959 cees      15   0 74932  17m 5460 S  0.0  3.9  14:54.84 kate


Doesn't appear to have been improved, although i waited for the swapping and cpu usage to calm down before copying top.

Currently, not having used Firefox (only checked the window list):

top - 18:24:51 up 20 days,  4:00,  5 users,  load average: 0.40, 0.78, 1.25
Tasks: 117 total,   1 running, 116 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.7%us,  1.0%sy,  0.0%ni, 95.7%id,  0.7%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    450736k total,   439572k used,    11164k free,     2192k buffers
Swap:  1132540k total,  1013204k used,   119336k free,    45524k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2241 cees      15   0  405m 206m 9.9m S  1.7 46.9  57:56.12 firefox-bin
 8690 root      15   0  781m  79m 4016 S  1.0 18.1 259:57.22 Xorg
 3959 cees      15   0 74932  17m 5680 S  0.0  4.0  15:00.66 kate

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Alfred, should we go ahead and dupe this to bug 143046

Comment 17

[Alfred Kayser]

Fine by me