Closed
Bug 52658
Opened 24 years ago
Closed 17 years ago
Heavy Frame usage causes memory leak
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect, P4)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: rzeglen, Unassigned)
References
()
Details
(Keywords: memory-leak, testcase)
Attachments
(1 file)
(deleted),
application/octet-stream
|
Details |
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
Comment 1•24 years ago
|
||
please attach any simplified testcase directly to this bug. Over to HTML Frames.
Assignee: asa → pollmann
Component: Browser-General → HTMLFrames
QA Contact: doronr → petersen
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.
Reporter | ||
Comment 3•24 years ago
|
||
Reporter | ||
Comment 4•24 years ago
|
||
No longer need to login to zeglens.yi.org to see bug.
Keywords: mlk
Comment 5•24 years ago
|
||
Cc'ing Judson. Jud, this may be of interest to you in your embedding work.
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.
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.
Reporter | ||
Comment 8•24 years ago
|
||
Any updates on the status of this bug? thanks...
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?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
Updated•24 years ago
|
OS: Windows NT → All
Hardware: PC → All
Comment 11•24 years ago
|
||
Due to acrobatics needed to reproduce the leak, moving off one milestone.
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.9.1
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.
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Updated•24 years ago
|
Target Milestone: mozilla0.9.2 → mozilla1.0
Comment 15•23 years ago
|
||
Bulk reassignin HTML FRAME/IFRAME bugs to Eric.
Assignee: pollmann → evaughan
Status: ASSIGNED → NEW
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)
Target Milestone: mozilla1.0 → mozilla1.0.1
Comment 17•23 years ago
|
||
Bulk re-assigning all of Eric's HTMLFrame bugs to John.
Assignee: eric → jkeiser
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.
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
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.
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.
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.
Comment 24•21 years ago
|
||
Maybe same problem: http://www.ms.mff.cuni.cz/~marel2am/MozillaMem/1.htm
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.
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.
Comment 27•18 years ago
|
||
Do we still have word about this in being fixed in the current codebase, even in Firefox?
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.
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
Assignee: john → nobody
QA Contact: amar → layout.html-frames
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.
Flags: blocking1.9?
Comment 31•17 years ago
|
||
+'ing and marking as a P4. Can someone please dig into this?
Flags: blocking1.9? → blocking1.9+
Priority: P3 → P4
Tomcat, can you see if this show any trace-refcnt leaks?
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
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.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
Comment 35•17 years ago
|
||
I've opened followup bug 412065 on the issue.
Updated•6 years ago
|
Product: Core → Core Graveyard
Assignee | ||
Updated•6 years ago
|
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•