Closed
Bug 95810
Opened 23 years ago
Closed 17 years ago
runaway memory consumption
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 143046
Future
People
(Reporter: paul, Unassigned)
References
()
Details
(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.
Comment 1•23 years ago
|
||
Confirming on Win2k 2001081303. Yikes! OS -> All.
Status: UNCONFIRMED → NEW
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
Comment 3•23 years ago
|
||
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
Comment 4•23 years ago
|
||
confirming on win2k - bulid 2001110103 any clues so far?
Keywords: hang,
mozilla0.9.7
Comment 6•23 years ago
|
||
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.
Updated•23 years ago
|
Target Milestone: --- → Future
Keywords: mozilla0.9.9
Comment 7•23 years ago
|
||
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)
Updated•23 years ago
|
Keywords: mozilla0.9.7
Comment 8•23 years ago
|
||
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.
Comment 10•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
alot@rogers.com: 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•19 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
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•18 years ago
|
||
Alfred, should we go ahead and dupe this to bug 143046
Assignee: pavlov → nobody
QA Contact: tpreston → imagelib
Updated•18 years ago
|
Assignee: nobody → pavlov
Updated•18 years ago
|
Assignee: pavlov → nobody
Comment 17•17 years ago
|
||
Fine by me
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•