Both Firefox and Thunderbird Nightlies freeze system during startup because of extreme memory demand

RESOLVED INVALID

Status

Core Graveyard
GFX: Gtk
RESOLVED INVALID
11 years ago
7 years ago

People

(Reporter: David A. Cobb, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070118 Minefield/3.0a2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070118 Minefield/3.0a2pre

NOTE: This applies to nightly builds of both Minefield and Thunderbird beginning on or before 2007-01-04.
After some strange behavior I started observing memory use (both htop and gnome-system-monitor) during program startup.  This is what I observe:

WHEN: for Minefield, once when displaying the plug-in compatibility panel, once after dismissing that and before displaying my home page;
for Thunderbird, with the summary page displayed and status "connecting to (host)".

Virtual memory starts quite reasonable and builds up from about 60MiB to 150MiB, then suddenly jumps to 2.6GiB (!!).  Everything on my computer slows to a crawl, the mouse becomes unresponsive (and once was completely disabled), I observe some network traffic but I can't isolate it to the Mozilla product.

This condition persists for about 5 or 10 minutes.  Then, equally sudden, the virtual footprint drops back to a reasonable 160MiB and thereafter behaves as usual.

QA NOTE: I think this should be categorized "Major" because of its impact on the total system.  But I can't really claim any specific product feature is broken.

Reproducible: Always

Steps to Reproduce:
1. Observe product startup with some process monitor.
2. Start Thunderbird or Minefield.
3.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070119 Minefield/3.0a2pre
I have a normal startup here. I have only windows to test, though. Can you reproduce this in Firefox's safe-mode and do you have the latest plugin versions? Flash, or maybe there is Java on your homepage? 

Comment 2

11 years ago
You could also try "ulimit -v" to limit virtual memory to say 300MiB
and then start Firefox in that shell. The core dump could give some clues.
(Reporter)

Comment 3

11 years ago
<blockquote>and do you have the latest plug-in versions? Flash, or maybe there is Java on your homepage?</blockquote>
Well, since I specified that this applies to both Firefox and Thunderbird, and Thunderbird doesn't use Flash (nor do I allow Java in e-mail), that may not be relevant.  However, yes my plug-ins  are either up-to-date or disabled.
<blockauote>You could also try "ulimit -v" to limit virtual memory to say 300MiB
and then start Firefox in that shell. The core dump could give some clues.</blockquote>
That did provide useful information, if not what we might hope.  Do do this, I had to create modified versions of the application-launching scripts.  With a ulimit imposed, the programs simply behave in a completely civilized manner: they observe the limit and run quite nicely, without any abnormal system impact.

I'm going to need to make a copy with debugging symbols embedded.  DDD does little except gripe about shared libraries it cannot find, and symbols not present.

Comment 4

11 years ago
I am also seeing this problem. Using Firefox nightly builds on Ubuntu, when I start firefox my memory, swap, cpu, and load all jump instantly to 100%, stay there for several minutes, then all drop to virtually 0% and Firefox starts and runs normally.

I'm using a trunk build right from ftp.mozilla.org: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a2pre) Gecko/20070202 Minefield/3.0a2pre

This is reproducible every time for me, even with no profile present (has to make a new one). I haven't tried safe mode but I'll report back when I do.

Comment 5

11 years ago
Created attachment 254461 [details]
backtrace in the thread eating all the memory

Comment 6

11 years ago
I think that I encoutered the same issue: it happens when using the gtk engine gtk2-engines-ubuntulooks, that means the default Ubuntu 6.10 theme labelled "Human".

Reporter: could you see if changing the Theme solves the issue for you?

I tested Gran Paradiso on 4 physical machines, and 1 vm. On two of the machine and the vm, it worked fine. On two of the machines, it ate all memory at startup. All the machines have a standard Ubuntu 6.10 with the default theme. The two machines with the issue are running the ati and nv Xorg drivers.

I also tried building my own about:buildconfig-same-as-release build, and the problem disappeared!

For this issue, Gecko may not be the one to blame. We should find out more about it and maybe forward upstream. Not sure on what component to triage this.

Comment 7

11 years ago
Most likely not a Firefox bug.  Please file a bug with Ubuntu instead.
https://bugs.launchpad.net/ubuntu/+bugs
Component: General → GFX: Gtk
Product: Firefox → Core
QA Contact: general → gtk
Version: unspecified → Trunk

Comment 8

11 years ago
I Filed bug in Launchpad: https://bugs.launchpad.net/ubuntu/+source/ubuntulooks/+bug/84221

Clearlooks behaves much more nicely at startup. In fact, total UI performance seems to be significantly better with this engine.

wtf, ubuntu? You have failed me!

Updated

11 years ago
Duplicate of this bug: 366570
(Assignee)

Updated

9 years ago
Product: Core → Core Graveyard
Seems to have been a Gtk theme problem rather than a bug in our code.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.