195163 - leaking like a sieve?

Status: RESOLVED DUPLICATE of bug 198104

(SeaMonkey :: General, defect)

Description

[(not reading, please use [e-mail] instead)]

leaking like a sieve?

alecf, can you elaborate on what you were seeing?   

I want to track it and figure it out.

Comment 1

[Alec Flett]

I'm just finding that in the commercial nightly builds on windows, our VM is
going WAY up in task manager.. at times I've found it as high as 315 megs. What
usually alerts me to this is that typing in HTML compose (Specifically in AIM
and mail compose) grinds to a slow crawl... at that point I go to the task
manager and see that its taking a boatload of memory... so I quit, and start
again.. problem solved :(

It usually takes about a day of general use (AIM, e-mail, browsing, etc) to
start seeing this, and plaintext compose (such as filling out bug reports)
generally don't show the problem. I generally do a lot of AIM stuff, and send a
lot of e-mail so my only theory is that HTML compose is leaking. (and for those
of you reading this, don't think AIM is specifically the culprit just because
I've mentioned it here twice - I think that this is something in mozilla)

Comment 2

[Alec Flett]

I should add that the thing which is UNIQUE to AIM is that I usually keep 3-4
AIM windows open to the same 3-4 people for most of the day, which means that
the HTML compose sessions are left "running" that whole time. It also means that
I could have a lot of dialog entered and cleared from HTML compose.

Comment 3

[Stephen Moehle]

Here is what I am seeing.  If I go to two rather unordinary sites like
http://linuxtoday.com and http://lwn.net , and I start using the back and
forward buttons to switch between them, I seem the virtual memory used by
Mozilla increase every time I go forwards and back.  Even worse, the amount of
memory used each time increases.  The first time I lose about 48k.  At the 4th
iteration, I am losing 195k.  By the 10th, I am losing 500k each time.

After using Mozilla for about 8 hours under normal usage, the VM is up to about
120MB.  Usually it maxes out at about 55MB.  I am not using AIM, and I have seen
this with 2003-02-24-04 on Windows 2000 and 2003-02-26-10 on Windows XP.

Comment 4

[Alec Flett]

ok, for instance in between the time that I wrote that last message and this
posting, the process has grown from 99 megs to 108 megs. That's 9 megs in a
little more than an hour. One AIM session, about 5 e-mails sent, about 15 bugs
posted to. I've spent most of that time in mail and posting to bugs.

Comment 5

[Alec Flett]

ok, not much more AIM stuff but lots of sending and recieving e-mail and I'm up
to 121 megs just 2 1/2 hours later, including an hour for lunch. Time to get out
purify :)

Comment 6

[Stephen Moehle]

I am seeing this leak on Linux as well.  I have gone back and tested various
versions, and the leak seems to have been introduced between builds
2003-02-21-22 and 2003-02-22-05.

Comment 7

[(not reading, please use [e-mail] instead)]

this bad of a leak might block 1.3 final.

Comment 8

[Asa Dotzler [:asa]]

2003-02-21-22 and 2003-02-22-05 would have both been 1.4 trunk builds (post 1.3
branching) so it's very likely that this isn't a problem on the 1.3 branch. I
don't see any problems with 1.3 branch builds leaking. Are others seeing this on
the branch? What usage pattern is triggering it?

Comment 9

[Stephen Moehle]

If I do the test I described in comment 3, I see no leak at all on the 1.4
trunk.  On the 1.3 branch, I am seeing a much slower leak than I saw then.  Now,
each time I go from one page to another using history forward and back, I lose
anywhere from 40k to 80k.

Tested on Linux with 2003-03-04-15 1.4 trunk and 2003-03-10 1.3 branch.

Comment 10

[Phillip Rhodes]

I'm seeing the same behavior described in comment #3, using build 20030310,
which I believe is on the 1.3 branch.  In fact, I'm pretty sure it is, because I
don't have the debug and qa menus in this build...

However, I have Multizilla and mouse gestures installed, which may make my
observation meaningless in relation to a base Mozilla install.

Comment 11

[(not reading, please use [e-mail] instead)]

before we ship 1.4 final, we should resolve this issue

Comment 12

[Alec Flett]

so I think this is totally AIM related - at least composer-specific - my guess
is that composer is leaking huge buffers every time I send an AIM message...
something that might manifest itself when sending lots of e-mail messages.

Comment 13

[David :Bienvenu]

bug 198104 might be contributing - if you use quick search frequently, or mail
views, in large folders, you could eat up a lot of memory quickly. Please try
tomorrow's build.

Comment 14

[Alec Flett]

oh! I do do both of those things.

Comment 15

[Samir Gehani]

adt: need info.  Alec, still seeing this?

Comment 16

[Samir Gehani]

adt: nsbeta1-

Comment 17

[David :Bienvenu]

marking dup of bug 190104

*** This bug has been marked as a duplicate of 190104 ***

Comment 18

[Myk Melez [:myk] [@mykmelez]]

Presumably you meant bug 198104, not bug 190104.  Fixing (step 1).

Comment 19

[Myk Melez [:myk] [@mykmelez]]

Fixing (step 2).

*** This bug has been marked as a duplicate of 198104 ***