Closed
Bug 215491
Opened 21 years ago
Closed 20 years ago
memory usage increases but never decreases
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 130157
People
(Reporter: geneh, Unassigned)
Details
(Keywords: meta, Whiteboard: INVALID)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
I've noticed this since 1.2.
As you browse pages and such, opening new windows or tabs or both and closing
them, Mozilla's memory usage according to Task Manager, (for obvious reasons)
increases but even after closing all but one window and one tab with the blank
page, the memory usage does not decrease. (I've personally had it balloon over
200MB)
It takes a while to actually quit (takes about two or so Ctrl-Q tries to do it).
Then I restart Mozilla to start the cycle over again.
It's as if the "garbage collector" is on strike (sorry, java talk....).
Reproducible: Always
Steps to Reproduce:
1. Browse some websites
2. Browse some more websites
3. Browse even more websites
4. Repeat 1-3 for a while.
5. Open new blank tab and close all other tabs.
6. Notice that the memory usage doesn't go down.
7. Go to Starbucks to grab some coffee/mocha/latte/whatever.
8. Repeat if necessary.
Actual Results:
Mozilla's memory usage balloons up and doesn't go down and you get your caffeine
fix.
Expected Results:
Memory usage should've gone down. (Caffeine fix stays)
Comment 1•21 years ago
|
||
Please look at bugs 198806 and 213391. They are both related
to memory usage and, as they are image-related, fixing them
would surely make the memory leaks less evident.
yea....it might be an image-related issue but from my experience, it can also
happen even if image loading is turned off....it just takes FOREVER to get to
that point.
Since it seems to depend on all kind of different bugs (where memory just is not
properly released to the OS), that are all factors to the permanent memory
increase and the description of this bug is not very specific (just the results
are here, the reasons for it can be found in the depending bugs), I suggest
making this one a meta bug for tracking the strange memory increase.
Keywords: meta
Comment 4•21 years ago
|
||
only drivers can set blocking flags and you shouldn't set the priority on a bug
you don't own.
and why do we need a tracking bug? what's wrong with searching for bloat and
mlk keywords? not enough spam?
Flags: blocking1.7a+
Priority: P1 → --
Updated•21 years ago
|
Whiteboard: INVALID
Comment 5•21 years ago
|
||
Well.. this bug still exists, and I think this is one of the most serious bug.
Doesn't mozilla code free memory after it allocated a dynamic memory?
Comment 6•21 years ago
|
||
Seems to be same problme as Bug 212197 ( memory balloons to over 200MB )
Comment 7•21 years ago
|
||
Unreleased virtual memory on window close is one of the causes of this problem.
Problem recreation scenario:
(1) Start "Task Manager" of MS Windows 2000(or XP) and choose "process".
Display "Memory Usage"(probably real memory) and "Virtual Memory Size".
(2) Start Mozilla ("Image Name" is mozilla.exe)
(Home Page setting : http://www.mozilla.org/start)
(3) Repeat "Open New Tab" and "Close Tab"
-> "Virtual Momory Size" increases on tab open and decreases on tab close
No problem.
(4) Repeat "File/New/Navigatio Window"(CTRL+N) and close opened window
-> "Virtual Momory Size" increases on open but doesn't decrease on close
This is the problem.
(5) Repeat step(4) again and again. Virtual storage increases constantly.
(6) Minimizing of window reduces "Memory Usage(probably used real memory)"
to several Mega Bytes order.
"Memory Usage" after re-activation is smaller than one before minimize.
This indicates Real Momory is freed successufully.
If URL of new windows is page contains large data such as image, increment of
virtual memory size in step (4) becomes very large.
Following is test result with 2004042808-trunk on Win-2K(SP4), Cerelon 500MHz,
128MB memory, HDD 10GB, Swap is set 256MB.
(0) Set HOME page to file://C|/test/testdata.bmp
testdata.bmp is Bit Map file of 3MB.
(1) Start Mozilla Browser => Virtual Memory Size = 20MB
(2-1) Open 10 new browser windows by CTRL+N => 64MB
(2-2) Close opened 10 browser windows => 62MB
(3-1) Open 10 new browser windows by CTRL+N => 95MB
(3-2) Close opened 10 browser windows => 92MB
(4-1) Open 10 new browser windows by CTRL+N => 124MB
(4-2) Close opened 10 browser windows => 122MB
(5-1) Open 10 new browser windows by CTRL+N => 154MB
(5-2) Close opened 10 browser windows => 152MB
(6-1) Open 10 new browser windows by CTRL+N => 183MB
(6-2) Close opened 10 browser windows => 181MB
(7-1) Open 10 new browser windows by CTRL+N => 217MB
(7-2) Close opened 10 browser windows => 213MB
(Stopped test because Swap area was expanded)
(8-1) Memory Usage(real momery) was 60MB at this step.
(8-2) Minimize Browser Window => Memory Usage(real momery) bocomes 2.8MB
(8-3) Re-activate Browser Window => Memory Usage(real momery) bocomes 12MB
Virtual memory is aparantly not released on window close.
2 to 4 MB reduction of virtual memory size on each 10 window close is probably
result of successuful release of 3MB of BMP data.
Comment 8•21 years ago
|
||
Testcase is in previous comment.
Why is "invalid" on status whiteboard?
Keywords: testcase
Comment 9•21 years ago
|
||
I've found that phenomenon of Comment #7 observed when extention of "Tab Browser
Extentios(TBE)" is installed.
When uninstalled TBE, pure Mozilla trunk since no other extentions, infinite
virtual storage increase did not occur on repetive window open/close.
I do not know whether cause is TBE's fault only, or cause is Mozilla's lack of
resource clean up function of resource for extentions, or both.
In addition, a Japanese user also reported at Bugzilla.jp that he experienced
virual memory increase phenomena with extention of "Auto Scroll".
To all problem reporters : Do you use some extentions? Or use pure Mozilla?
Comment 10•21 years ago
|
||
Creater of TBE and I have found that large virual storage on window open/close
descrived in Comment #7 is TBE's fault - extention did not destory objects
created by TBE on window close.
And test version of TBE resolved problem of Comment #7, although this fix is not
available yet.
Please note that current TBE does not have this type of problem on tab open/close.
In additon, Japanese user reported virual storage increase problem when another
extention is used, TBE is not used, as I mentioned before.
So some extentions fault can be one of the casuse of this bug since programer,
like me, tends to forget to free memory(destroy object in JavaScrit) which
should usulay be done on tab close or window close.
Again, do you use extentions?
If yes, remove extention and try pure Mozilla.
Too large virtual storage problem will occur on pure Mozilla?
Comment 11•21 years ago
|
||
> Testcase is in previous comment.
apparently it wasn't...
> Why is "invalid" on status whiteboard?
when I put in INVALID there (comment 4), this bug had no specific steps to
reproduce and the best suggestion at that point was to turn this into a tracking
bug, which is not useful since there are already keywords for this purpose.
General memory increases like this can be caused by bug 130157.
Keywords: testcase
Comment 12•21 years ago
|
||
For problem of Comment #7, new version of TBE(2004-05-09 version) has been
released at TBE owner's site, to which object destroy logic on window close is
added.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 13•20 years ago
|
||
*** This bug has been marked as a duplicate of 130157 ***
You need to log in
before you can comment on or make changes to this bug.
Description
•