If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Intense Yahoo Mail use leads to out-of-memory crash

RESOLVED WORKSFORME

Status

()

Core
General
--
major
RESOLVED WORKSFORME
8 years ago
6 years ago

People

(Reporter: Øyvind Yrke, Unassigned)

Tracking

1.9.1 Branch
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1

Playing through many messages in Yahoo mail client will eventually crash FF due to memory usage.
This bug was found when playing around with Bug 503384.


Reproducible: Always

Steps to Reproduce:
1. use a memory watch tool, e.g. sysinternal procexp and watch private bytes
and virtual size for firefox.
2. login to a yahoo account with many messages
3. play quicky through the messages in the inbox (i.e. press the up/down keys without waiting for the messages to appear).
4. watch the memory usage whilst pressing up/down.  I managed to get firefox to
run out of memory even in a clean session (i.e. no other tabs open).

FF will crash sooner or later, and if you have many windows/tabs open FF will crash sooner rather than later.
Actual Results:  
FF crashes.

Expected Results:  
The crash is caused by FF running out of memory. FF should not use as much memory as it dies to play through messages in yahoo mail client.


Also, when looking at the memory usage in the windows task manager, memory usage increases, then drops to initial value, increases again a bit higher and then eventually hits the 2GB limit.  I guess this is the GC kicking in. But when playing through the message list several times, the GC kicks in too late (or frees to little).

The callstacks I have on ff-3.5.1, points at the garbage collector itself running out of memory (callstack says js_GC....nsCycleCollector...).  One cass is an an unhandled std::bad_alloc exception.

Also, after I upgraded to ff-3.5.1 I have to work harder to make ff crash with yahoo.  In 3.5 it was quite easy to get ff to crash.  And in my original setup with 100+ tabs, it was in fact hard to avoid the crash once I realized yahoo was involved.  In 3.5.1 I have to keep the up/down keys pressed for a long time, sometimes playing through the entire mailbox several times to get the crash.

See also 503384.
(Reporter)

Comment 1

8 years ago
Created attachment 390926 [details]
2 callstacks

2 callstacks attached with out of memory.

Comment 2

8 years ago
the nsDeque::GrowCapacity bug is filed.

Comment 3

8 years ago
I'd rather focus on "uses GB of memory" rather than "crashes due to using GB of memory".  (The latter is bug 427099, bug 516518, bug 70821, or bug 482143.)

Unfortunately, this could be Yahoo's fault.  Does closing the Yahoo tab free most of the memory?  Does leak-gauge (one of the tools on https://wiki.mozilla.org/Performance:Leak_Tools) report any large leaks persisting through shutdown?
Summary: Intense mail browsing in Yahoo crashes Firefox → Intense Yahoo Mail use leads to out-of-memory crash
Øyvind, can you reply to comment 3?
(Reporter)

Comment 5

8 years ago
Hi, sorry about not replying before.

Note there is no permanent memory leak when using the yahoo mail client.  The issue is that when scrolling through the mail messages by keeping the up/down arrows pressed, memory usage will just grow and grow until the 2GB limit.  If ff does not crash, memory will be freed to the same level as before scrolling started (when not scrolling anymore).
(In reply to comment #5)
> issue is that when scrolling through the mail messages by keeping the up/down
> arrows pressed, memory usage will just grow and grow until the 2GB limit.  If
> ff does not crash, *memory will be freed to the same level as before* scrolling
> started (when not scrolling anymore).

Øyvind, are you able to try trunk build? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

if we are delegating the crash to the bugs jesse mentions, then severity becomes major.
Severity: critical → major
Component: General → General
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.9.1 Branch
(Reporter)

Comment 7

8 years ago
Hi, I downloaded the trunk build.  On the first day I could not reproduce the crash.  However, trying a bit more a few days later, also the trunk build crashed.

A few observations.
- both the trunk build, and version 3.6.3 are much more robust than 3.5 where the original crash is reported.
- when scrolling intensely, virtual size stays at around 2000MB (almost constantly).

Comment 8

8 years ago
do you have extensions installed? please try running in safe mode to see if that changes your memory patterns. Also please try disabling plugins in tools>addons>plugins (they are *not* disabled by using safe mode).
Øyvind
> do you have extensions installed? please try running in safe mode to see if
> that changes your memory patterns. Also please try disabling plugins in
> tools>addons>plugins (they are *not* disabled by using safe mode).

preferably with with version 4.0 beta
Whiteboard: [closeme 2011-03-01]
No response from reporter.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
(Reporter)

Comment 11

6 years ago
The crash is no longer reproducable with FF6.  Don't know if this is due to FF itself, or the yahoo client.  While browsing emails as described in the original crash report, memory footprint hardly increases, where it in the past would increase to 2GB.

To conclude, pls close the issue.
thanks for the update
Resolution: INCOMPLETE → WORKSFORME
Whiteboard: [closeme 2011-03-01]
You need to log in before you can comment on or make changes to this bug.