User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040621 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040621 After running several days or weeks with many open tabs, Mozilla starts to use lots of memory (up to 600 MB) and grabbing an entire CPU on a SPARC machine. The browser and the machine are getting very slow. This can be seen instantly (without waiting for days) when browsing Flash animated pages. The only way to fix this is quitting and restarting Mozilla. This seems to be a Solaris specific issue cause I can't see it on MacOS or OS/2. Reproducible: Always Steps to Reproduce: 1. browse a page with Flash animations or have Mozilla running for a long time 2. 3. Actual Results: Browser and OS getting VERY slow Expected Results: none

(In reply to comment #0) > Mozilla starts to use lots of memory (up to 600 MB) Virtual memory or real memory? If real memory, similar situation can be observed on MS Windows 2000. Real memory usage increases. This is because freed real memory is usually not got back by OS until other application wants them or Mozilla is minimized. This is design of OS. If virtual memory, this can be result of Mozilla's internal mechanism. Since many of memory resources are JavaScript Object, memory area for destoryed objects does not mean freed virtual memory, and even if it can become freed virtual memory, garbage collection may not free it because memory control is usually done on memory block, and even if become really free block and will be returned to OS, it is done by garbage collector, then delay occurs. And garbage collector usually does not do compaction of memory area for JavaScript Object resources, fragmentation in memory block keeps to stay. This sometimes cause large virtusl memory size even if no memory leak. Usually, both of above are not problem on well designed OS as you say "no problem on OS/2 or Mac". (I do not care on MS Win because "Design" of MS Win :-) Are there any need of special care(special setting for large virual memory user) on Sun OS? There is other possibility of your problem - similar situation to Bug 76831. > Bug 76831 : Slow startup after long periods of inactivity (minimized window or other) OS get back real memory from inactive application(swap-out), and Mozilla's real memory requirement for normal run is larger than usual application(because of memory fragmentation and so on), and swaping-in(page-in) mechanism is not so well compared to OS/2 or Mac OS X(Fee BSD?), then swapped-out of Mozilla becomes severe problem on some OS. Is this case? There is another posibblity. Do you use Tab Browser Etentions? Old version of TBE had problem of "does not destroy object" on tab close and window close. This is already resolved. If you use TBE, what version do you use?

Does VM chew CPU on Solaris? I know VM on mac has that problem. If so this may be just a memory issue, ala bug 213534 with CPU usage as a side effect of massive memory leaks.

I replied to WADA's questions by personal mail (my fault!) - could he please copy this answer to this bug?

(In reply to comment #3) > I replied to WADA's questions by personal mail (my fault!) To whom have you sent? Wasn't copy of the mail saved?

I sent the mail to m-wada@japan.com at 12/07/2004 and I don't have a copy ...

(In reply to comment #5) > I sent the mail to m-wada@japan.com at 12/07/2004 and I don't have a copy ... Your mail doesn't arrive to my mail box yet. (I don't do Empty Trash since 2004/9/25, but I can't find your mail in Inbox, Junk nor Trash folder.) Did you sent mail to me successfuly? Please note that your mail server may reject my mail address because my mail address is one by mail transfer service and "japan.com" is not registered to DNS as a mail server. Anyway, I think you'd be better to write down your response to this bug by yourself.

I'll try to reproduce the original answer: - I was talking about VM, not real memory - I'm not able to qualify if the mentioned behavior is by Mozilla's design but evven if this is the case this design should be changes cause it's not acceptable that one application is slowing down and does the same with the entire OS; but maybe you're partly right as it seems to have cured a little since we have moved to a much more powerful machine - furthermore, there seems to be a connection to Flash animations cause the effect is much more likely to occur if a viewed page contains such stuff - regarding other OSes: 1.8a5 on MacOS seems to have a similar problem which I didn't have with earlier versions - this problem also occurs if Mozilla has not been minimized but if you have any test scenarios I'll be happy to perform them - and no, I'm not using the mentioned extension

(In reply to comment #7) > - I was talking about VM, not real memory I see. > - this problem also occurs if Mozilla has not been minimized but if you have > any test scenarios I'll be happy to perform them Do you mean "virtual storage" allocated to Mozilla decreased when minimized? Or on slow startup problem after long period of minimize (Bug 76831)? Please distinguish "continuous increase of virtual memory problem" and "slow wake up problem when large virtul(and real) memory". > - regarding other OSes: 1.8a5 on MacOS seems to have a similar problem which > I didn't have with earlier versions Which is the problem on Mac OS? (a) Large virtual storage problem itself(continues to increase) (b) Slow startup problem after long period of minimize (Bug 76831) (I think you says (b) does not occur on Mac OS X in comment #0) > - furthermore, there seems to be a connection to Flash animations cause the > effect is much more likely to occur if a viewed page contains such stuff When I found problem of "Tab Browser Extentions doesn't detsroy JavaScript object ", virtual memory always increased when Tab is newly opened, but never decreased when Tab is closed. In this problem case, vitual memory never decreased even when window close. To see whether similar situation is occuring or not, opening/closing Tab(s) with flash animation is a good test. Test scenario is ; (0) Uninstall all extentions. (1) Open a new window (Browser window only) (1-1) Tab open test (1-1-1) Open a tab with Flash animation (1-1-2) Check virtual memory and real memory (1-1-3) Minimize all windows (1-1-4) Return to normal size after a while (1-1-5) Check virtual memory and real memory (1-2) Repeat (1-1) MM times (1-3) Tab close test (1-3-1) Close a tab (1-3-2) Check virtual memory and real memory (1-3-3) Minimize all windows (1-3-4) Return to normal size after 10 to 20 seconds (1-3-5) Check virtual memory and real memory (1-4) Repeat (1-3) MM times (1-5) Repeat (1-1) to (1-4) NN times (2) Open some new windows (Browser window only) (2-1) Do (1-1) to (1-5) for each window (3) Close windows (3-1) Check virtual and real memory after each window close (4) Repeat (1) to (3) PP times

>Do you mean "virtual storage" allocated to Mozilla decreased when minimized? >Or on slow startup problem after long period of minimize (Bug 76831)? Neither nor. What I meant is that Mozilla also starts eating system resources when it's constantly running in the foreground and not being minimized. >Which is the problem on Mac OS? >(a) Large virtual storage problem itself(continues to increase) >(b) Slow startup problem after long period of minimize (Bug 76831) > (I think you says (b) does not occur on Mac OS X in comment #0) You're right, (b) fits better. But in my case, it doesn't concern minimization but rather system suspension. I didn't check memory usage here but he actual problem is that Mozilla is getting extremely slow and starts to show the colored wheel frequently.

... and I'll try to check the Flash tests soon ...

Can be closed as DUP of Bug 130157 or Bug 174604.

I wish to report the following data: I'm running Windows XP SP2 with NO virtual memory, in a system with 1GB of RAM. I'm using Mozilla 1.8b, and I'm measuring the memory usage through the "private bytes" column of Process Explorer (www.sysinternals.com). After having used Mozilla on and off for a few days for browsing and reading mail, without closing it, I closed all tabs of the browser window except one, in which I entered the URL "about:blank". I also closed the mail window and cleared the cache in the preferences. The only Mozilla window that was left was the one showing "about:blank". After this, Process Manager indicated a use of 174472 kbytes by Mozilla. Minimizing Mozilla made only a very slight change in this figure. I then closed Mozilla and started it again, and again opened "about:blank" in a single tab of a browser window. The memory usage indication given by Process Explorer was then 17588 kbytes. I think this is a clear indication of some memory management problem in Mozilla. For some special reasons, I don't use virtual memory in my system. This behavior of Mozilla means that I have to close it and restart it every few days, to prevent it from eating up too much RAM.

With Seamonkey, near latest, memory consumption has been accellerated quite a bit. I had my SeaMonkey running on a Linux PC where it usually feels snappy and initially consumed some 80MB. After running for only two (?) days, it consumed some 250MB and was hard to stop. This is my user agent string: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050914 SeaMonkey/1.1a Mnenhy/0.7.2.0

(In reply to comment #12) > I'm using Mozilla 1.8b Bug 131456 was fixed on 2005-02-23. Try trunk builds after 2005-02-23. (In reply to comment #13) bfcache(Fast back and forward) is "ON" by default for Seamonkey. Try browser.sessionhistory.max_viewers=0. See "General"/"Fast back (and forward)" of http://www.mozilla.org/projects/deerpark/new-browser-features.html

*** This bug has been confirmed by popular vote. ***

(In reply to comment #15) > *** This bug has been confirmed by popular vote. *** Matt, please see Bug 320915, and read David Baron's blog pointed by Bug 320915 Comment #28, please.

(In reply to comment #7) > - furthermore, there seems to be a connection to Flash animations cause the > effect is much more likely to occur if a viewed page contains such stuff This aspect of the bug could be caused by bug 334322.

How is your problem with SM 1.1 plus latest version 9 flash? http://labs.adobe.com/technologies/flashplayer9/ note bug 334322 comment 24

I didn't test the latest Flash version yet. We'll be upgrading the servers to new hardware and the current Solaris 10 release in the near future and then I'll certainly install Flash 9. I also never used SM but with Firefox 1.5 and 2.0, things don't seem to have become better.

Duplicate of bug 354087.

CT in comment #20: > Duplicate of bug 354087. CT please read the bugs. bug 354087 is a regression on the trunk, but this bug is on the branch, and 354087 began more than a year after this bug. Plus, this bug is marked solaris only (which might be incorrect - but you have not suggested that) Frank a) what happens if you try a trunk version of SM or FF? b) what happens if you try FF2/SM 1.1.1 with new flash beta for solaris http://labs.adobe.com/technologies/flashplayer9/ click product details to get the release notes (which I would guess doesn't necessarily list everything they tweaked) c) the beta doesn't say it supports SM+FF trunk (but that's not surprising) - what happens if you run trunk version with flash beta?

[enlisting some help from bug 372756 - perhaps these bugs are even related] do you see this problem? with firefox or seamonkey - doesn't matter. SM trunk at http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-trunk/

Concerning my latest experiences, please see comment #24 of bug #273364].

Sorry, copy/paste error. The correct reference is bug #339654, comment #24. Thanks, Wayne!

(In reply to comment #24) > the correct reference is bug #339654, comment #24. Frank, so, your testing indicates this problem is gone? If not, you could try adobe's latest flash beta http://labs.adobe.com/downloads/flashplayer9.html

It's gone for me as I unintendedly switched the platform - but it's probably not gone on the original SPARC machine. I'll try to do some testing on the old system.

Frank, when you try it out, please list your version as reported by http://www.adobe.com/products/flash/about/

i would expect this to be gone with latest version of adobe flash but can tell without someone to test and confirm, so closing this incomplete.

I'm running on Sparc with Adobe 9,0,47,0 installed, which is the latest and Xsun still grows without limit. We have a bug open with Sun on this, and they say: >The problem is that when more then one tab is >opened that uses the flash plugin it continues to create color cells. T>he Xserver has to allocate some memory for these cells. Sustaining is l>ooking into if this is flash not freeing the color cell or if the >Xserver is not freeing the cells

(In reply to comment #29) > I'm running on Sparc with Adobe 9,0,47,0 installed, which is the latest and > Xsun still grows without limit. We have a bug open with Sun on this, is there a reference number? so this is not bug in sparc, and still an open issue for adobe? sorry if I prematurely closed this. Please reopen if appropriate. I see adobe has not yet issued a version 9 beta for sparc. http://labs.adobe.com/downloads/flashplayer9.html

9, 0, 47, 0 is not a beta version. Go to http://www.adobe.com/shockwave/download/static/Solaris/ShockwaveFlash/English.html and get it.

(In reply to comment #31) > 9, 0, 47, 0 is not a beta version. > Go to > http://www.adobe.com/shockwave/download/static/Solaris/ShockwaveFlash/English.html > and get it. unless you intended your message to be for Frank, can you clarify based on the following? - 9, 0, 47, 0 is reported to have same problem (comment 29) - I think we know 9, 0, 47, 0 is not a beta - comment 30 was meant to say that solaris is not in the list of betas for other systems

Then please ignore comment 31. According to comment 29, the bug is either in flash or in Xsun, it's not in Firefox.

I believe the bug comment 29 mentioned is http://bugs.opensolaris.org/view_bug.do?bug_id=6565453 It will be addressed in Flash 9 update. (not on labs.adobe.com or adobe.com yet)