Closed Bug 95810 Opened 23 years ago Closed 17 years ago

runaway memory consumption


(Core :: Graphics: ImageLib, defect)

Not set





(Reporter: paul, Unassigned)




(Keywords: hang, memory-leak)

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.
Keywords: mlk
Confirming on Win2k 2001081303. Yikes!

OS -> All.
Ever confirmed: true
OS: Linux → All
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
Blocks: 92580
No longer blocks: 92580
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.
Assignee: asa → pavlov
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston
confirming on win2k - bulid 2001110103
any clues so far?
Keywords: hang, mozilla0.9.7
Memory usage does reach 100% with win xp build 2001111603
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.
Target Milestone: --- → Future
Keywords: mozilla0.9.9
Blocks: 51028
No longer blocks: 51028
Blocks: 124608
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)
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.
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.
I'm running Mozilla 1.0 on Redhat, and this happens all the time. I keep a 
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  
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. 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)
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.
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 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 (, 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

 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

 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


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

 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

 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
Alfred, should we go ahead and dupe this to bug 143046
Assignee: pavlov → nobody
QA Contact: tpreston → imagelib
Assignee: nobody → pavlov
Assignee: pavlov → nobody
Fine by me
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.