Closed Bug 217663 Opened 21 years ago Closed 20 years ago

Memory Leak that got worse in 1.5b

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jc, Unassigned)

References

Details

(Keywords: memory-leak, qawanted)

Attachments

(2 files)

Stack of nsDocument leak
905 bytes, text/plain
Details
Stack of a leak
1.09 KB, text/plain
Details 
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.
timeless, keeda, any chance one of you could find which objects leak?
Here is a stack of many nsDocument leaks.
Attached file Stack of a leak — 
These also show up and a single leak is 4871 bytes.
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.

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
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.
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?
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?
reporter: how much memory do you have installed on your machine?
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.
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.
Keywords: mlk
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.
Maybe the memory usage increase has something to do with bug 205893 ?
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?
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.
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 ?
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.
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
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?
Just tried nightly 2003090704 with same kind of results.
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]
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.
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.
> 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).
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.
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.
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.
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. 
*** Bug 213487 has been marked as a duplicate of this bug. ***
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
Flags: blocking1.6?
Flags: blocking1.6? → blocking1.6-
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.
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.
Flags: blocking1.7a?
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-
(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.
Could this be related to bug 98835?
Product: Browser → Seamonkey
use a program like freeram 1.4 for windows xp.

it helps with memory leaks - set it for periodic freeing


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?
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.

Attachment

General

Creator:
Created:
Updated:
Size: