Closed
Bug 217663
Opened 21 years ago
Closed 20 years ago
Memory Leak that got worse in 1.5b
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: jc, Unassigned)
References
Details
(Keywords: memory-leak, qawanted)
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827 Running 1.5b today saw the memory footprint grow from 28 meg to more than 78 meg with only modest browsing. It seems to add 100k to 200k with every webpage change. Reproducible: Always Steps to Reproduce: 1. Go to www.mozilla.org 2. Go to www.nytimes.com 3. Go back to www.mozilla.org Actual Results: Memory usage continues to rise with each webpage change Expected Results: Stabilized, or gone down with simpler pages.
Comment 1•21 years ago
|
||
timeless, keeda, any chance one of you could find which objects leak?
Comment 2•21 years ago
|
||
Here is a stack of many nsDocument leaks.
Comment 3•21 years ago
|
||
These also show up and a single leak is 4871 bytes.
Comment 4•21 years ago
|
||
I believe the documents are nsXMLDocuments. The stack was missing xmlextras.dll between XPTC_InvokeByIndex and nsDOMImplementation::CreateDocument and nsXMLDocument shows up in quite a few other leaks too.
Comment 5•21 years ago
|
||
read in an widely read forum ( links posted there get slashdotted! ) about this: http://www.heise.de/newsticker/foren/go.shtml?read=1&msg_id=4110979&forum_id=46794 Forum is in German Language, Extract: Load www.heise.de Reload www.heise.de, memory usage is increased 400 .. 600 kb per reload. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030827
Comment 6•21 years ago
|
||
Hmm.. if the XMLDocument leaks from XMLHttpRequest, then that's a known leak bug with a patch being worked on....
heise.de and mozilla.org homepages do not seem to use XMLHttpRequest, or any XML as far as I can see.
Comment 8•21 years ago
|
||
ccing some people who may be able to figure out what's going on.... I think we want to get a handle on this before 1.5.
Flags: blocking1.5?
Comment 9•21 years ago
|
||
Blocking 1.5 until this is at least understood, or can be dup'd against the XML document bug.
Flags: blocking1.5? → blocking1.5+
Taking to investigate.
Assignee: general → dbaron
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → mozilla1.5beta
I'm not able to reproduce any document leaks. I'd be interested in exact steps to reproduce for those who see such leaks. (By exact, I mean that you need to include whether you hit Ctrl-R or the reload button, because it could matter -- unless you observe that it happens either way.) I am able to reproduce memory growth reloading http://www.heise.de/, but it almost all seems to be: 2190349 malloc 2122599 operator new(unsigned) 2089532 operator new[](unsigned) 2089396 nsImageGTK::Init(int, int, int, nsMaskRequirements) 2089396 gfxImageFrame::Init(int, int, int, int, int, unsigned short) 1572436 nsGIFDecoder2::HaveDecodedRow(void*, unsigned char*, int, int, int) 1572436 /builds/trunk/obj/debug/dist/bin/components/libimglib2.so+2F5BA 516960 imgContainerGIF::DoComposite(gfxIImageFrame**, nsRect*, gfxIImageFrame*, gfxIImageFrame*, int) 516960 imgContainerGIF::Notify(nsITimer*) Are we putting images in the image cache when they're already there? I've thought I've seen something like that before. Or is it that we're getting different images each time? Or is this Windows-only?
Comment 12•21 years ago
|
||
reporter: how much memory do you have installed on your machine?
Comment 13•21 years ago
|
||
the heise.de memory growth is definitely image cache. see about:cache (reload, check, reload, check...) and about:cache?device=memory. The 3 animated ads seem to be the culprits. In cache, they show up as something like: http://www.heise.de/RealMedia/ads/adstream_lx.ads/www.heise.de/Homepage/1770833100/Left/137-eigen-he-1/137-eigen-he-1_4/3136352e3234372e3132382e313630 different copies of the image in cache have different numbers here ^^^^^ but if you actually try to view that image, you get redirected to: http://www.heise.de/qc/emedia/bookshop/02_09/7405_assembler.gif with http://www.nytimes.com/, reloading the first few times increased memory cache, but after a while (10 reloads?), it stopped growing. they've probably got a wider variety of ads Mozilla was caching.
Comment 14•21 years ago
|
||
hmm... this leak could also be caused by someone holding onto the imgIRequest longer than necessary since it in turn owns a nsICacheEntryDescriptor, which if kept alive prevents the corresponding cache entry and the gfxIImageFrame owned by the cache from being destroyed.
Reporter | ||
Comment 15•21 years ago
|
||
Darin: my (the reporter) machine has 256 meg. As of this writing, the mozilla.exe process is already up to 52 meg and it's just been running 20 minutes.
Comment 16•21 years ago
|
||
Maybe the memory usage increase has something to do with bug 205893 ?
Comment 17•21 years ago
|
||
See bug 105344 -- at 256MB total ram, the ram cache will be 14mb or so. How big is your Mozilla when you just start it? How big is your RAM cache when you hit 52mb?
Reporter | ||
Comment 18•21 years ago
|
||
It starts up with both browser and email active at about 28 meg. It continues to grow through the day to about 84 meg. Right now it's 58 meg. I have no idea how to tell the ram cache size, but if you tell me how I will be happy to check it. Also, I'll be happy to check a daily when there is a bug fix to try.
Comment 19•21 years ago
|
||
You can find that data on about:cache (memory cache, top part of the page). Also, does it improve when you close the current window (on a pc, open a new empty window before you close the old one) and wait a few seconds ?
Reporter | ||
Comment 20•21 years ago
|
||
OK, at the moment mozilla is at 48 meg. about:cache reports Number of entries: 147 Maximum storage size: 16384 k Storage in use: 2257 k Inactive Storage: 1228 k So - I think we're just seeing a leak.
Reporter | ||
Comment 21•21 years ago
|
||
Another test. Starting at 48 meg footpring, I opened a ten of NY times and similar pages, running the footprint up to 78 meg. I then closed them and it dropped down to only 68 meg. about:cache reports 358 Maximum storage size: 16384 k Storage in use: 11405 k Inactive Storage: 10235 k
Reporter | ||
Comment 22•21 years ago
|
||
Forgot to add to the above - at 68 meg foot print it shows 360 gdi objects, while the only page open is this one. I would think mozilla should be releasing gdi objects?
Reporter | ||
Comment 23•21 years ago
|
||
Just tried nightly 2003090704 with same kind of results.
Comment 24•21 years ago
|
||
ok, i was reading mkaply's purify log and it showed us leaking an entire toplevelwindow [I] Starting Purify'd mozilla.exe at 09/09/2003 10:48:35 [W] MLK: Memory leak of 168 bytes from 1 block allocated in nsAppShellService::JustCreateTopWindow(nsIXULWindow *,nsIURI *,int,int,UINT,int,int,int,nsIXULWindow * *) [appshell.dll] nsAppShellService::JustCreateTopWindow(nsIXULWindow *,nsIURI *,int,int,UINT,int,int,int,nsIXULWindow * *) [nsAppShellService.cpp:727] *aResult = nsnull; intrinsicallySized = PR_FALSE; => window = new nsWebShellWindow(); Specifically the first window. The rest of the log is almost unusable because everything tied to the webshell leaked. I didn't ask mkaply for a build id but i'm fairly certain it satisfies the conditions for this bug. Does someone want mkaply's log? [i'm using his log to file some bugs against nsView and w32printing]
Comment 25•21 years ago
|
||
Fixing those one-timers would make it so much easier to find the other ones. I found it pretty difficult, too, to find other leaks because of those polluting the results.
I didn't see any such leak on Windows. Then again, I didn't try printing. If someone gives steps to reproduce a leak, that would be helpful. (I'll try to remember to try printing today.) Note that leaks can depend on practically anything -- what you mouse over, whether you use menus or keyboard shortcuts, which of the many mechanisms to close a window you use -- so unless you've tested that the leak occurs either way, it's better to be detailed.
Reporter | ||
Comment 27•21 years ago
|
||
David - it is VERY easy to reproduce - simply open task manager - link to a number of pages, go back and forth, open pages, close them - you'll notice the footprint rising and rising. In my first very entry I gave a clear series of steps. Read the notes here - there are plenty of reproducible examples.
Comment 28•21 years ago
|
||
> link to a number of pages, go back and forth, open pages, close them - you'll > notice the footprint rising and rising. This is *not* a good way to verify a leak. Memory usage can easily rise during normal browsing without being a leak. To identify a leak, you need to perform the *same* task repeatedly and see memory usage continually rise, even after 10 times. And note comment 13, which describes steps which grow memory continually (even doing the same thing repeatedly) without being a leak.
In comment 26 I was referring specifically to the leak in comment 24. In any case, I probably won't have access to a Windows build for a while unless I borrow yet another machine (since the one I was borrowing is now moved into another building).
Reporter | ||
Comment 30•21 years ago
|
||
1) There is undoubtedly a leak in windows. When you get to the end of the day and the only window open is a text message in mail, and the footprint has risen to 80 megs, there is a leak. 2) I can get it to consistent rise by repeatedly opening and closing any webpage with graphics, even simple ones like www.thp.org/prize/. Going through and deleting the contents of each morning's junk-mail folder to empty will slowly add about 10 meg.
> 1) There is undoubtedly a leak in windows. When you get to the end of the day
> and the only window open is a text message in mail, and the footprint has risen
> to 80 megs, there is a leak.
Yes, but what actions cause that leak? From the sound of it, you've been using
both browser and mail all day -- and probably many features of both. Suppose
the leak is caused by the standalone message window, and I read all my mail
using the three-pane window. How am I supposed to figure out that that's what
you're doing if you don't say exactly what you're doing when the leak occurs?
Reassigning to default owner.
Assignee: dbaron → general
And note that opening web pages with graphics fills up the memory cache. Though the junk mail thing is something worth testing, except I can't do it any more.
Reporter | ||
Comment 33•21 years ago
|
||
This is still a problem in 1.5RC1 under w2k. It may even be worse than 1.5b. Just going back and forth between 2 pages (a simple test file with a link to www.nytimes.com) ran the footprint up to 70 meg in under an hour. The cache limit is 16meg and is full, but the footprint of 1.5rc1 just keeps on growing.
Reporter | ||
Comment 34•21 years ago
|
||
Maybe part of what I said above is wrong. I did more playing around. I now think that the 16meg max on about:cache doesn't actually fill up all the way until I hit a 72.5meg footprint. Memory usage beyond that point seems to properly go up and down with the number of open and closed windows (ie, 12 windows open took it up to 85 meg, closing them dropped it back down to 72.5 meg). This would indicate to me that the leak (if there is one) might be associated only with the allocation of cache items - since adding 16 meg of cache seems to add just a bit more than twice that much to the footprint.
Reporter | ||
Comment 35•21 years ago
|
||
Update on 1.5rc2 - there seems to be an improvement. Now, running the cache up to 16 meg (max on my machine) increases the footprint to 62 meg instead of 72 meg.
Comment 36•21 years ago
|
||
*** Bug 213487 has been marked as a duplicate of this bug. ***
Comment 37•21 years ago
|
||
This bug also seems to be on 1.5 and 1.6b (Windows tested only). My daily Usage of 6 to 8 hours of browser and mailnews brings up the memory usage to 150MB! And I can't remember this on 1.4. On large memory usage, Mozilla won't react on textinputs in MailNews (extremely annoying) or mouseclicks e.g. for changing a window. The whole lizard sleeps for 3 or 4 seconds. If you minimize all mozilla-windows, the mem usage goes down to less than 2 (yes, "two") MB! If you reopen all windows, the mem usage goes up to ca. 20 MB and is rising fast again. These are my observations. HTH
Updated•21 years ago
|
Flags: blocking1.6?
Updated•21 years ago
|
Flags: blocking1.6? → blocking1.6-
Comment 38•21 years ago
|
||
in mozilla 1.6 under windows xp pro i still noticed the leak. i was only browsing for a few minutes, and i had the browser jumping up as much as 2mb per page change, and just continue to climb.
Comment 39•21 years ago
|
||
in mozilla 1.6 under windows xp pro i still noticed the leak. i was only browsing for a few minutes, and i had the browser jumping up as much as 2mb per page change, and just continue to climb.
Updated•21 years ago
|
Flags: blocking1.7a?
Comment 40•21 years ago
|
||
FYI: I filled some time ago bug for the cache filling issue on heise.de. => bug 229839 See also bug 81446 comment 80
I've fixed a bunch of leaks in 1.7alpha already. If people are still seeing problems, then somebody should describe what causes the leak. Without a good description of what the problem is, this bug can't be fixed (which makes it invalid), and it certainly can't block a release. And please try not to confuse the memory cache filling up with a leak.
Flags: blocking1.7a? → blocking1.7a-
Comment 42•21 years ago
|
||
(In reply to comment #41) > And please try not to confuse the memory cache filling up with a leak. it has been a source of confusion in this bug... see comment 5 and comment 11.
Comment 43•20 years ago
|
||
Could this be related to bug 98835?
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 44•20 years ago
|
||
use a program like freeram 1.4 for windows xp. it helps with memory leaks - set it for periodic freeing
Comment 45•20 years ago
|
||
Should this title and target milestone be changed since 1.5b is long gone and the milestone was missed? Also, how about a "helpwanted" key word?
Comment 46•20 years ago
|
||
helpwanted isn't really appropriate - this doesn't need coding assistance, it needs more diagnosis (in fact, it needs more diagnosis to even make it a valid bug, as dbaron said). Resetting milestone and stuff, but really this should probably be marked invalid and a new bug filed when someone has a description of something reproducable with a current version.
Keywords: qawanted
Priority: P1 → --
Summary: Memory Leak much worse in 1.5b → Memory Leak that got worse in 1.5b
Target Milestone: mozilla1.5beta → ---
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•