excessive memory usage using hushmail.com webmail

RESOLVED INVALID

Status

RESOLVED INVALID
17 years ago
8 years ago

People

(Reporter: quattro, Assigned: yuanyi21)

Tracking

({qawanted})

Trunk
x86
Windows XP
qawanted

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

17 years ago
With one browser window open and 5 navigator tabs(mail.yahoo.com, hushmail.com,
cnn.com, arstechnica.com, www.bootnetworks.net initially), memory usage hangs
around 133MB.  Thinking it might be the java servlet that hushmail uses, I
logged out of hushmail and browsed to a different page in that navigator
tab...the memory usage increased.  I then closed that tab, memory usage remained
the same.  I browsed to different pages in the remaining four tabs and memory
usage continued to increase past 135MB.  I then closed all the tabs but one, and
memory usage remained the same.

From help, about:  Mozilla 1.1

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1) Gecko/20020826
(Reporter)

Comment 1

17 years ago
Created attachment 96930 [details]
windows task manager screen capture

Here's a screen capture showing memory usage
(Reporter)

Comment 2

17 years ago
I've narrowed the problem down to hushmail, here are the steps I took to
reproduce it and the correlation memory usage for mozilla and internet exploerer:

mozilla - iexplorer in MB
open browser: 16 - 9
hushmail.com: 22-16
enter username: 39-21
enter password/load inbox:  53-37
open sent items folder: 54-31
switch to inbox folder: 61-38
switch to trash folder: 63-30
switch to inbox folder: 67-38
delete mail: 73-38
switch to sent items folder: 74-32
switch to inbox folder: 80-38
quit: 82-30
browse to cnn.com in same window: 86-36

Could be an issue with hushmail, but the browser should definitely release
memory when you browse away from hushmail.com.  Additionally, IE releases memory
when switching between folders in the hushmail servlet.  Mozilla just keeps
utilizing more memory and never gives it back.
  
Summary: excessive memory usage → excessive memory usage - hushmail.com

Comment 3

17 years ago
It is not really a bug.  What you are seeing is a virtual memory, it meant the 
combination of RAM memory and disk caching).  If the RAM is maxed out, then the 
memory is being swapped to the disk (disk caching) freeing up the RAM for more 
webpages.  It continue this way until one tab is close or the browser is 
closed.  What happen in that case is the un-needed data in the tab or the 
browser that got closed is removed, so you got some free space back.

This is not really a bug with Mozilla.  Try it with Internet Explorer and 
you'll find a similar result.  Oh that's right, IE doesn't have tabs.  

I think this bug would be closed as soon as possible.
Summary: excessive memory usage - hushmail.com → excessive memory usage
(Reporter)

Comment 4

17 years ago
IE version 6.0.2600.0000
Summary: excessive memory usage → excessive memory usage - hushmail.com

Comment 5

17 years ago
Alright, keep playing with hte hushmail and we'll find out.  Just got a mid-air 
collision.
Summary: excessive memory usage - hushmail.com → excessive memory usage
(Reporter)

Comment 6

17 years ago
Scott...it is definitely a mozilla issue, read my additional comments

And event without the additional information, there is no way 135MB memory usage
is not mozilla's bug(virtual or physical)...please use some common sense before
responding.
(Reporter)

Comment 7

17 years ago
not much more playing to be done, there's no reason for mozilla to be using that
much memory and then not release it

Comment 8

17 years ago
Caching and swapping are different things. It's simply wrong to say that it's
just virtual memory. Hogging memory is never a good thing, no matter how much
virtual memory there is. In any case, using 135 MB is too much.

John, will the memory be released if you open another browser window and close
the one you used?

Comment 9

17 years ago
I would like to report my experience with mozilla 1.1. After 7 hours of uptime,
I had reached 432Megs of memory used. This is *way* too much. Also, this problem
did not happen with 1.0 (as far as I am aware). I do not use hushmail. A pretty
typical day of surfing. A bit of google, some slashdot, cnn, salon, cnet. I'll
see if I can pinpoint the troublesome area.

Comment 10

16 years ago
This bug hasn't moved anywhere in six weeks, and the bug doesn't really identify
a particular fixable problem  ->INVALID

If you want to file bugs on excessive memory usage, please try to provide a
very-exact set of steps that cause the problem, and try to isolate it to a
particular page/java applet.  That way a developer trying to fix the problem can
isolate it for potential fixes.

As a hypothetical example:
1) in a new browser window, go to hushmail.com and log in to the java applet
2) open a new tab, go to google, and reload 20x.
3) watch memory usage climb on each reload, to 220MB.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
(Reporter)

Comment 11

16 years ago
bsmedberg,

You're an idiot, if you can't contribute something constructive, keep your 
mouth shut.

I outlined the steps clearly.  Did you even take the time to read the bug's 
content before sticking your foot in your mouth:

mozilla - iexplorer in MB
open browser: 16 - 9
hushmail.com: 22-16
enter username: 39-21
enter password/load inbox:  53-37
open sent items folder: 54-31
switch to inbox folder: 61-38
switch to trash folder: 63-30
switch to inbox folder: 67-38
delete mail: 73-38
switch to sent items folder: 74-32
switch to inbox folder: 80-38
quit: 82-30
browse to cnn.com in same window: 86-36


There's no excuse for the browser holding onto 140MB of memory after closing 
the window that was used to browse to hushmail.  Fine, the hushmail issue can't 
be fixed, but at least return the memory when the window used to browse to 
hushmail is closed.  IE does not exhibit behavior even remotely similar.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 12

16 years ago
I do a lot of bug-triaging, so I'm pretty sure I'm not an idiot.

The steps that you list cannot be reproduced, because they involve lots of
uncontrolled variables.  I suspect that you are experiencing continued memory
usage because the Java VM has not completed a garbage-collection cycle, even
after you have left the hushmail webpage; but I can't be sure, because I cannot
reproduce your problem without logging on to a hushmail account (I don't really
know how hushmail works).

Why don't you try forcing a java garbage collection using the Java console, to
see if this is really the culprit.  If this is the culprit, we might be able to
fix it by having mozilla issue a garbage-collection hint to the Java VM after an
applet is closed.
Let's at least give this bug a summary specific enough so that it's a single,
potentially fixable issue.  Otherwise there's no point in having a bug. 
Changing summary from "excessive memory usage" to "excessive memory usage using
hushmail.com webmail".

What are you using to do the memory measurements?  I hope it's not task manager,
since that isn't really showing the size of the heap, but rather just what's
paged in, or something like that.
Summary: excessive memory usage → excessive memory usage using hushmail.com webmail
->OJI (=Java)
Assignee: asa → joe.chou
Component: Browser-General → OJI
QA Contact: asa → petersen
(Reporter)

Comment 15

16 years ago
You may handle a lot of bugs, but you sure did a great job of proving my statement:

"I don't really know how hushmail works"

We're talking about something that takes less than a minute to figure out.  I
guess you're lazy too.  It's not too difficult to sign up for an account and
take a few minutes to actually try and reproduce the problem rather than add
nothing but speculation.

"The steps that you list cannot be reproduced, because they involve lots of
uncontrolled variables."

Please, point out ONE variable that is uncontrollable.  Now don't be lazy and
whine about the amount of email in each folder being uncontrollable.  That's
obvious.  But think for a minute.  First, we're talking ascii text, second, if
the email were the culprit, don't you think IE would exhibit the same or similar
behaviour?

Why even waste my time and others by posting if you can't take a few minutes to
even attempt to reproduce the problem.  Any 5 year old that has used web based
email would expect there to be an inbox, sent mail box and trash can.  These
aren't folders that I created.  Additionally, the inbox has a few mails with no
attachments and the other two are empty.  Now, again, where are these
uncontrollable variables?  All you had to do was take a few minutes, sign up for
an account, send a few mails to it and attempt to reproduce the error.

Until you do quit wasting my time.
(Reporter)

Comment 16

16 years ago
Hi David,

I used several third party memory monitoring apps as well as performance monitor
to verify my findings.

Additionally, I forced garbage collection and memory usage remained the same.

(They're good if they don't show a change when you minimize the browser.  If
that's the case, what are they (if they're free) -- I'd like to recommend them
to other people who want to monitor memory usage.)
There's more to Task Manager than the default view (View -> Select columns). The
numbers sound excessive, but I suspect IE hides parts of its memory usage in
some obscure system processes etc. 

Updated

16 years ago

Comment 19

16 years ago
"there are other memory leak bugs than these"

This bug is basically a catfight. If you don't like what the mozilla developers
say, then bitching at them in a bug is not the right place to do it. Try turning
this into a reproducable bug, and filing again.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → INVALID
This is still a valid bug.

It would be nice if someone had the time to reduce the testcase -- i.e., look at
the HTML served from hushmail.com, take a piece necessary to cause the leak (for
leak bugs it doesn't need to be simplified, but it would be much easier to have
a single page that shows the leak), and attach that HTML to the bug so that
someone can test more easily.  This makes it much easier for different people,
with different expertise, to debug the problem, without each spending 20 minutes
to set up the necessary account.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
Martijn, can you reproduce?  If so, can you make a testcase?
Keywords: qawanted
I get appr. 70MB, and it remains that way, when doing stuff in hushmail.
When closing the hushmail tab, memory remains at 70MB, but that's normal for
pages with Java applets inside, not?
(by the way, latest trunk builds crash on this page because of bug 309706)
John in comment #16
> Hi David,
> 
> I used several third party memory monitoring apps as well as performance monitor
> to verify my findings.
> 
> Additionally, I forced garbage collection and memory usage remained the same.

does this still happen for you with a current version browser?
please list your findings above with specifics: the tool(s), steps, and quantities.

can you create a testcase as suggsted in comment 20?

could also be partly due to memory leaks - there is a good memory leak tool - reference http://www.squarefree.com/2006/01/13/memory-leak-detection-tool/
and
http://plugindoc.mozdev.org/faqs/memusage.html#fixed-1.8.0.5

perhaps "Things that are not leaks" is also relevant http://plugindoc.mozdev.org/faqs/memusage.html#notleaks-usage-constant
Assignee: joe.chou → yuanyi21
QA Contact: chrispetersen → zhayupeng
closing based on comment 23. though it could perhaps be duped to one of several java bugs. If anyone still has a problem the most productive approach might be to document the results of using leak detector.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago12 years ago
Resolution: --- → INVALID

Updated

8 years ago
Component: Java: OJI → Java: OJI
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.