Rob Zeglen Reporter
	Description • 24 years ago

IHAC who pointed this one out to me.  This was a long standing problem in our
old client 4.x base and I see it on NT and Unix platforms.  If you take a simple  
page that uses frames and keep hitting a button to load the frame again, we see 
the memory and VM creep up and up and never be freed.  I am guessing this will 
eventually cause crashes.... I tried it on M17, Buildid 2000080712 hoping to see
it fixed and I see the same problem.  I can email someone a very simple example 
to see this behavior.  Just let me know who to send it to, or I can put the 
stuff up on my home server and you can see it there.

-Rob

	Asa Dotzler [:asa]
	Comment 1 • 24 years ago

please attach any simplified testcase directly to this bug.  Over to HTML Frames.

	Rob Zeglen Reporter
	Comment 2 • 24 years ago

I have setup a test case.  Point your client to:

http://zeglens.yi.org/frames

You will need to login first (user: elmer   password: elmer will work)
Keep hitting the "Load frame above" button and see the memory usage go up.  It 
is never freed.

	Rob Zeglen Reporter
	Comment 4 • 24 years ago

No longer need to login to zeglens.yi.org to see bug.

	Michael La Guardia
	Comment 5 • 24 years ago

Cc'ing Judson.  Jud, this may be of interest to you in your embedding work.

	Michael La Guardia
	Comment 6 • 24 years ago

Rob, I notice that the build you are using is exceedingly old.  You can test
daily builds that you can download off of mozilla or you can get commercial
builds off of sweetlou.

	Rob Zeglen Reporter
	Comment 7 • 24 years ago

Michael,

Last night I grabbed the nightly build (2000092508) and saw the same problem.
I loaded my test page and tracked memory usage after ever 50 loads of the frame
and saw memusage go up by about 250K for every 50 clicks to load the sample
frame.   It never appears to be freed even after browsing elsewhere and
eventually returning.  Virtual Memory also continues to climb and never be
freed. The customer here is GE Medical Systems and they are trying to use our
browser to drive some of their medical imaging products.

	Rob Zeglen Reporter
	Comment 8 • 24 years ago

Any updates on the status of this bug?
thanks...

	Eric Pollmann
	Comment 9 • 24 years ago

Playing with today's FreeBSD build, I was able to reproduce this leak, but only
when I clicked on the "load a frame above" button repeatedly very quickly in
succession so that the page was interrupted mid-load.  I've loaded the frame
over 400 times now and memory usage went up almost 2 megs.

However, no matter how many times I click the button, if I wait for the page to
fully load each time, there is no increase in memory usage.  I'd say that a 5K
leak each time page load is interupted is somewhat, but not extremely serious. 
Since we're focusing on crashers and major usability issues from here on out for
rtm, I don't think a fix for this will make it in to N6.  :[

CC'ing Rick Potts - are you looking at this kind of leak?

	Kevin McCluskey (gone)
	Comment 10 • 24 years ago

Set milestone to mozilla0.9

	Eric Pollmann
	Comment 11 • 24 years ago

Due to acrobatics needed to reproduce the leak, moving off one milestone.

	Amarendra Hanumanula
	Comment 12 • 24 years ago

QA Contact update

	Asa Dotzler [:asa]
	Comment 13 • 24 years ago

Is this still a useful report? If it is can someone please remove the Netscape
Confidential flag or if there is real proprietary info I'll be glad to file a
clean version so we can resolve this Netscape Confidential bug as invalid. 

	Rob Zeglen Reporter
	Comment 14 • 24 years ago

Removed Netscape Confidential flag.

	Kevin McCluskey (gone)
	Comment 15 • 23 years ago

Bulk reassignin HTML FRAME/IFRAME bugs to Eric.

	Asa Dotzler [:asa]
	Comment 16 • 23 years ago

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

	Kevin McCluskey (gone)
	Comment 17 • 23 years ago

Bulk re-assigning all of Eric's HTMLFrame bugs to John.

	Chris Sutton
	Comment 18 • 22 years ago

We have some internal systems which run in frames and on both linux and Windows
we are still seeing this problem and are running v1.1.

For one of our users who clicks around in these frames all day long, their
virutual memory climbs into the 250mb range and then swaping starts and then it
all goes to hell.  Doesn't crash, but things get really slow.

	Mathias Rufer
	Comment 19 • 22 years ago

I may add that opening and closing many tabs also causes a huge memory usage,
even when all tabs are closed again.
Example: I open topographic maps in PNG format, each one is 32M big
uncompressed. If I open 10 tabs with maps, I get a memory usage of >1G Mozilla
only!!
If I close all tabs, Mozilla still uses 300-600MB.
I have to close Mozilla completely to get some memory again :-|

Mozilla 1.2.1, Win2k SP3

	John Beranek
	Comment 20 • 21 years ago

Just to confirm this with a current Mozilla:

Mozilla 1.4
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624

I can use Mozilla heavily for a few days or so, opening and closing lots of
tabs, and the memory usage of Mozilla just climbs and climbs.

Even when all Mozilla windows are closed, apart from something like an
about:blank page, memory usage is still at the 120MB mark.

	Vedran Miletic
	Comment 21 • 21 years ago

retargeting

	desktopa
	Comment 22 • 21 years ago

This bug may block development of a stable Web application development 
environment. Memory used by Mozilla in general is very alarming if not used for 
web surfing or simple form based web applications.

	Kelly Price
	Comment 23 • 21 years ago

I can report on Mozilla 1.6 Gecko/20040117 (build for Slackware-current), that
the leak still happens.  Right now, it's using abour 49 megs of RAM.

12 hours later (before I restarted it, I had brought it up around 11am, and it's
like 11pm now) it was using 150 megs of RAM as RSS.  This was with a "chat
window" which is a refreshing-every-minute Tagboard chatroom off of
http://www.masterzdm.com .  It's also had several runs of the VCL Seive
(http://vclart.net) over the course, as well as about ten invokations of MailNews.

Those figures are taken from "top" on Linux.

Sort of as a side effect, after 12 hours, it slows down considerably between pages.

	Pavel Cvrcek [:JasnaPaka]
	Comment 24 • 21 years ago

Maybe same problem:

http://www.ms.mff.cuni.cz/~marel2am/MozillaMem/1.htm

	Ben Hollis
	Comment 25 • 21 years ago

I'm seeing this in Firefox .8 on WinXP/SP1 - I have a page with an IFRAME in it
that loads a webcam page every 5 seconds... after leaving the browser on that
page for a few hours, memory has inflated by over 50MB and the browser has
gotten sluggish.

	godsfantasy
	Comment 26 • 19 years ago

http://java.sun.com/j2se/1.5.0/docs/api/index.html

Above is a less severe example.  The Java 5 API spec. page with frames.

	Kelly Price
	Comment 27 • 18 years ago

Do we still have word about this in being fixed in the current codebase, even in Firefox?

	godsfantasy
	Comment 28 • 17 years ago

This problem does not appear to present itself with the 2.0.0.5

Could someone verify this as well?  Many of the links no longer works.

	Wayne Mery (:wsmwk)
	Comment 29 • 17 years ago

for anyone who can test ... attachment 14998 [details] and http://java.sun.com/j2se/1.5.0/docs/api/index.html (from comment 26) can be checked 
(Rob's testcase URL http://zeglens.yi.org/frames is gone)

You might test them with https://addons.mozilla.org/en-US/firefox/addon/2490

	Steve Chapel
	Comment 30 • 17 years ago

After reloading <http://java.sun.com/j2se/1.5.0/docs/api/index.html> hundreds of times using Firefox 3 beta 1 on Windows XP, it looks like each reload causes Firefox to use about 30 K more memory. It's not much per reload, but I can seem to get memory use to go arbitrarily high by simply continuing to reload the same page. The number of GDI objects also seems to climb very high, and was over 4000 by the time I was done. leak-gauge.pl reports 0 leaks. about:cache shows that the memory cache is not exceeding its maximum storage size.

	Damon Sicore (:damons)
	Comment 31 • 17 years ago

+'ing and marking as a P4.  Can someone please dig into this?

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 32 • 17 years ago

Tomcat, can you see if this show any trace-refcnt leaks?

	Carsten Book [:Tomcat]
	Comment 33 • 17 years ago

(In reply to comment #32)
> Tomcat, can you see if this show any trace-refcnt leaks?
> 

Used the Steps to reproduce (the url from comment #26), but have not found a memory leak so far. The Statistics of my testruns looks normal:

nsTraceRefcntImpl::DumpStatistics: 770 entries
nsStringStats
 => mAllocCount:          79737
 => mReallocCount:         4990
 => mFreeCount:           79737
 => mShareCount:          58374
 => mAdoptCount:           4593
 => mAdoptFreeCount:       4593




nsTraceRefcntImpl::DumpStatistics: 734 entries
nsStringStats
 => mAllocCount:          85801
 => mReallocCount:         4004
 => mFreeCount:           85801
 => mShareCount:          57282
 => mAdoptCount:           4022
 => mAdoptFreeCount:       4022

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 34 • 17 years ago

Lets resolve this as WORKSFORME. It's very unlikely that the problem that existed when this bug was originally filed still exists given how much different all this stuff works these days.

However, if someone can reproduce this with a Firefox 3 beta 2, or newer feel free to reopen or preferably file a new bug.

	Steve Chapel
	Comment 35 • 17 years ago

I've opened followup bug 412065 on the issue.