Closed Bug 378401 Opened 18 years ago Closed 17 years ago

Unusual Memory Demand when Browser is open for extended time

Categories

(Firefox :: General, defect)

2.0 Branch
x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: isedc, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

I use firefox on a daily basis and recently noticed with the v2.0.0.3 that the amount of memory used increases abnormally.  This happens on both of my computers and is noticable after firefox has been running for over an hour.  I use multiple tabs during browsing of which some of them I login to secure websites.  After about an hour or so, the browser starts slowing down in every aspect, such as open new tab, load page, etc.  I open the task manager to see that firefox is using well over 300 MB of ram.  Screenshot available upon request.  This happens under normal browsing usage and I am unable to determine why the amount of memory increases like so.  When I terminate the browser, it takes about 15 seconds for firefox.exe to be removed from task manager, unless I force it.  When I restart the browser, the memory usage is back to normal but again after extended use, the memory usage jumps way up again.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox
2. Browser random sites for an hour with multiple tabs and without closing the browser completely.
3. Open task manager to see its current memory usage.
Actual Results:  
Memory usage jumped to over 300 MB of RAM.  Browser performance dramatically decreases.  The only remedy so far is to terminate the browser, wait until it is cleared from task manager and reopen.

Expected Results:  
Not demand so much memory and slow down dramatically.

After searching current bugs, the only thing close to this report is other reports of memory leaks, but in unrelated matters.  I was unable to match this report with any known issues.  The browser does not crash, but it slows down to the point where it almost freezes, but is barely responsive.
without one URL it's impossible to say.

if the issue is flash player then it may be bug 340566. workaround is install flashblock extension. what version of flash is reported by
http://www.macromedia.com/software/flash/about/ 
Version: unspecified → 2.0 Branch
I am positive it isn't flash even though that is a good point.  Loading flash files and not clearing the memory afterwards makes sense.  However, this happened to me when I did not view any pages with flash.  Actually, I was in the middle of web development and in constant contact with my server via web admin.  After an hour or so of refreshing the web pages and updating material, the problem showed.  After noticing the slow down, that's when I opened task manager to reveal firefox using 318 MB of memory.  The pages I was mainly using were my website pages and cpanel and phpmyadmin pages during my development.
Clear, reproducible steps are needed for your problem(s) to be addressed. See https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html about specificity, one problem per bug, and other issues. If your URLs and test scenarios are not available to the outside world then a set of testecases attached to each bug is needed.

You will want to have narrowed the possible causes by eliminating extensions (by running in safe mode), flash (by running flashblock) and java (there are good, existing java bugs)

A reproducible set of steps accompanied by a leak detector log
http://kb.mozillazine.org/Reducing_memory_usage_(Firefox)
would be great. 

It might be more useful to have these bug report to be based on trunk http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ 
marking incomplete, if you can add testacase as requested please reopen this
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.