222660 - Firefox 0.8: All instances crash. Memory leaks.

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Michael Jennings]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

Windows XP, all patches current. This problem much less in Firebird 0.61. When
opening several instances and several tabs in each instance, the response would
become slow in Firebird 0.61. Soon after all instances would crash. In Firebird
0.7, this crashing happens sooner. 

It would be great if instances were completely separate from each other. 

It seems sensible to increase the stack space to allow 40 instances with 10 tabs
each.

I am often asked to research numerous subjects. Each subject becomes a Firebird
instance. Each tab is some information found on the subject. The number of
subjects can easily reach 40 before I have finished some and can close them.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Michael Jennings]

User Agent for this problem:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Also, Mozilla Mail 1.5 is running. Some instances of Mozilla Browser 1.5 may be
running when the problem occurs.

Comment 2

[Jason Barnabe (np)]

What happens if you look at the amount of RAM these 40 instances take up?

Comment 3

[Christian :Biesinger (don't email me, ping me on IRC)]

-> firebird

Comment 4

[Jeff Walden [:Waldo]]

Is this still a problem in Firefox 0.8 with a clean profile?

Comment 5

[Michael Jennings]

Answering the Questions:

FireFox 0.8 Crashes All Instances. -- About 20 instances with an average of 5
tabs each just crashed while downloading a file, at 70%. Important work was
lost. In one of the instances, I had been building a list of Knoppix tools to
bookmark, from a Slashdot story. That was the most important instance, but
others represented considerable time loss, also.

The 20 instances had been using about about 167 Megabytes, if I remember
correctly. I had checked the memory before the crash.

Opening FireFox 0.8 Instances Consumes Large Amounts of Memory -- I opened ONE
instance of FireFox with ONE tab, the Home page of Slashdot.org. This consumes
41 Megabytes, with a peak memory usage of 54 Megabytes.

I notice that when memory use is large, memory use GROWS when tabs are closed.

In my opinion these are very serious problems that FireFox developers should
test for themselves. This problem has remained unchanged since early versions of
Mozilla, at least.

Conditions -- Intel 815EEA2 motherboard. Intel PIII processor. Windows XP, all
critical patches applied. Very stable machine. I tested earlier versions on a
P4, under Knoppix and Windows XP. No FireFox extensions, or extensions of any kind.

Clean Profile -- I don't know how to create a clean profile for FireFox. I
deleted the entire FireBird 0.7 folder. I noticed that some of the settings were
retained. I keep the history for 90 days and allow 50 Megabytes for cache.

Installation Notes -- Mozilla's installation and uninstallation notes are not
complete. This creates problems for developers because bugs are reported from
faulty installations. It also creates problems and loss of time for millions of
users.

Summary -- Nothing has changed. If anything, Firefox 0.8 is worse than Firebird
0.7 in its memory usage and instability.

Comment 6

[Melissa M. Strader]

System specs:Win XP,1G RAM,AMD Athalon XP 1800+,fresh install of Firefox 0.8. 

Opening 20 windows with 5 tabs each did not yield any problems, nor did 40
windows with 10 tabs each. I kept opening new windows and adding tabs, to see
what would happen. At 52 windows with 10 tabs each, a failure occurred. The font
of the browser changed, and some of the images on the home page of the browser
windows loaded in a distorted format. Most of the images failed to load. The
browser buttons disappeared and became visible only when the mouse cursor
hovered over them. Shortly after these symptoms, all of the browser windows
became unresponsive and I had to close the process through Windows Task Manager.
At the point of ending the process through the task manager, the memory usage of
the process was 156 megs. 

If this is a memory leak issue as the reporter suggested, it could affect users
with low RAM using less than 20+ browser windows. The minimum RAM required for
Firefox is documented as 64 megs, with 128 megs recommended.  It might be worth
testing the browser/tab capability on a machine with 64 and 128 megs of RAM if
someone hasn't tried this already.

Comment 7

[Sabrina Fay]

Steps to Reproduce:
1. Open Firebird
2. Open 10 tabs within firebird
3. Open a new window 
4. Repeat steps 2 and 3 until system crashes. Recorded system resources at 5
window intervals (see fay resources attachment).

I attempted to replicate this bug under the following configurations:

Window Machine's Configuration
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Microsoft Windows XP, Tablet PC Edition, Version 2002, Service Pack 1
PIII 866 MHz, 256 MB RAM

Linux Machine's Configuration
Mozilla/5.0 (x11; U; Linux i686; en-US; rv1.6) Gecko/20040207 Firefox/0.8
3.1-10 Red Hat, Linux 2.4.20-8
AMD 1MHz, 768 MB RAM

During the Windows replication, I was able to successfully open 24 new windows.
On the 25th window, Firefox crashed and closed the last five windows. I tried to
re-open the four windows again. On the 25th window, I received a “Virtual Memory
Minimum Too Low” warning box. I was then able to selectively close windows until
restoring system stability. I did not have to kill FireFox or restart windows.

During the Linux replication, I was able to successfully open 67 new windows
(although there was significant system degradation beginning after the 44th
window). On the 68th window, Firefox hung. Firefox then proceeded to close all
the windows. I had to reboot the machine in order to restore system stability. 

Sabrina Fay, 2/26/2004

Comment 8

[Sabrina Fay]

Attachment: Shows the system resources at 5 window intervals for comment #7

Comment 9

[Jason Barnabe (np)]

(In reply to comment #7)
> 4. Repeat steps 2 and 3 until system crashes. Recorded system resources at 5
> window intervals (see fay resources attachment).

OK, so how is Firefox's behaviour different than any other app? Every app is
going to cause a crash if it's opened enough times.

There seems to be a hodgepodge of valid bugs in here. One is that Firefox leaks
memory. Another is the Firefox's memory isn't reclaimed after a crash. Another
is that Firefox's minimum requirements may be too low. But "Opening Firefox an
ungodly number of times crashes it" is not one of them.

Comment 10

[Michael Jennings]

Quoting from comment #9: "There seems to be a hodgepodge of valid bugs in here.
One is that Firefox leaks memory. Another is the Firefox's memory isn't
reclaimed after a crash. Another is that Firefox's minimum requirements may be
too low. But 'Opening Firefox an ungodly number of times crashes it' is not one
of them."

I'm glad you have brought god into this discussion, because that raises the
level of seriousness of the discussion, and serious consideration is what is
needed. <grin>

I agree that there seem to be several memory management bugs. That has been my
impression, also. There also seems to be some problem with the way FireFox does
event handling, because FireFox is often slow to respond before the crash. Also,
Windows XP SP1 seems to have a memory management problem at the point the system
runs out of memory and begins using virtual memory. When FireFox crashes,
Windows XP SP1 becomes unusable and must be rebooted. (Linux continues after a
FireFox/Firebird/Mozilla crash with no problem.) Part of the problem with
FireFox seems to be associated with opening the Adobe Acrobat plug-in. Windows
XP SP1 has problems coming out of hibernation, apparently, also.

The most important issue you have raised is one that I think many Mozilla and
FireFox developers often misunderstand. To a large and increasing degree,
FireFox is, literally, the way people communicate with the world. This is not an
exaggeration. Microsoft's Internet Explorer is so buggy that it is dangerous to
use it; there have been 60 vulnerabilities in 2 years. 

The world needs a fast, excellent browser. What is ungodly is that, even though
FireFox is not a finished work, and even though it has extremely severe bugs in
which something that goes wrong in one instance and one tab can crash all
instances and all tabs, it is still the best browser the world has. That raises
questions of how well we humans take care of ourselves, which, in the case of
browsers, seems to be not well enough. That may not quite be an issue of
religion, but it is at least philosophical.

The tests run by Melissa and Sabrina are valuable in showing that the problems
are not dependent on one system or OS; the problems are easily replicated.
However, it is likely that those tests don't reproduce actual use. I have found
that, if I'm just running a quick test, crashing FireFox/FireBird/Mozilla
requires opening a lot more windows that it does during actual use. In actual
use, tabs and instances are closed in random order, for example. As was
mentioned, the problems seem to be associated with event handling; possibly they
are made much worse by the normal visiting and re-visiting and loading and
reloading of web pages.

Example of Normal Use

That raises the question: What is a "godly" pattern of use? Consider an actual
example of FireFox use.

Recently, I discovered that hardware firewalls have become much cheaper. I want
to replace some Cisco 675 modem/firewalls, which Cisco has stopped supporting.
(We use a hardware firewall for each local LAN and a software firewall for each
machine.) Linksys (now owned by Cisco), NetGear, Airlink Plus, and D-Link make
these firewalls. I open the home page of each of them, each in a separate
instance of FireFox. Their web sites are all poorly designed and I must hunt for
the product that would be appropriate. Sometimes I open a page, close it and
then re-open it, drawing the page from the FireFox cache. I open the PDF manuals
of several products of each of them. I look at the driver page of each of them.
After a while, the three four each have 10 or more tabs. Sure, if there were not
so much product confusion, I would only need 5 tabs each, but that's not the
real world.

Now that I have some idea of the hardware firewalls being offered, I want to see
how much they cost. I open new instances of FireFox, one for each product, and
load froogle.google.com to try to find the best prices. This is not an easy
task, some firewalls are $40, and some are $275, and there is no mention of the
price range on the manufacturer's web site. If there are four products from each
manufacturer, I have, at this point, 20 instances of FireFox open. There are
many sham sellers on the internet, so it is necessary to investigate each
hardware seller recommended by Froogle by opening several pages in several tabs.

At this point, I'm tired. I decide to take a rest, and read Slashdot.org. I find
a story there about databases. I open numerous links recommended in the story in
a new instance of FireFox. I research each link by opening several tabs.

Then I remember that I need to buy a 1600 x 1200 resolution LCD monitor. I
research that by opening one instance of FireFox for each manufacturer of LCD
displays. I open an instance of FireFox for froogle.google.com for each one that
I consider more closely. Buying this monitor is far more difficult than it
should be, which is typical. I open many, many tabs in each instance of FireFox,
but find I cannot make a decision immediately, so I leave everything open.

At this point, both the instances of FireFox for hardware firewalls and for LCD
monitors remain open. I didn't have enough time to read the Slashdot story about
databases before I went back to work. That's open, also.

Other questions arise during the day. I'm having difficulty printing to receipt
printers used in a point-of-sale application. They have a serial interface.
Receipt printers cost $350 each; changing to USB printers is not an option for
those who have many serial printers. The difficulty is due to some problem in
Windows XP that did not exist in Windows 98. I spend many hours researching the
problem. This is a far more difficult problem than I can recount here, and
results in opening many instances of FireFox and many, many tabs.

I see several more Slashdot stories I would like to read, but don't have time to
read immediately. Each gets an instance of FireFox; I use FireFox instances as a
kind of bookmark.

At some point I leave the computer on, or put it into hibernation, and quit for
the day. Next day I begin with all of the previous day's instances of FireFox,
and open more. On the third or fourth day of working like this, a lot of the
original instances are still open, and many more have been opened.

At one point, after I had bought the LCD monitor, but before I decided about
hardware firewalls, FireFox crashed. I lost all my work about hardware firewalls.

Yes, I could switch to another browser. Switching would not solve the problem;
other browsers are worse. They take longer to open.

Needs

I need to be able to save each instance of FireFox, with all its tabs, to a
file, not just a FireFox bookmark. I need FireFox to do this automatically after
I open each tab. Opera does this, but Opera is too slow and too quirky in its
design.

I need FireFox instances to be completely independent of each other.

Memory Management: The Real Problem

The real problem is the memory leaks in FireFox. Opening many instances and tabs
is a way of demonstrating the memory leaks. The method of demonstration should
not be criticized; it's just a method.

I notice that, in Windows XP, FireFox will sometimes increase its memory usage
as tabs and instances are closed. My experience with the crashing shows that
FireFox becomes slow to respond just before the problems begin occurring.
Everything is completely fine, then opening one more tab makes all instances
slow, and I know a crash is likely.

Possibly there is a memory leak in the event handling code. However, I would
think that would just make FireFox crash, not become slow first.

These problems have been the same since the days of Mozilla 1.0. I reported them
extensively in Mozilla 1.3, testing carefully under Windows XP SP1 and Knoppix
Linux.

Support Many Different Usage Patterns

FireFox may one day be the browser of choice for hundreds of millions of people.
All that's needed to get a view on the world is a computer, an operating system,
an internet connection, and a browser. Only a few years ago, not even
governments had such rich access to information. Providing a good browser to
everyone is important world-class work.

Michael

Comment 11

[Tadeu "Tcmjr"Junior]

*** Bug 234179 has been marked as a duplicate of this bug. ***

Comment 12

[Timwi]

I don't know if the following is of any use in this bug, but I thought I might
mention this. I have always experienced memory leaks with Firefox, simply by
observing the memory usage in Windows Task Manager while it is running for
prolonged periods of time. However, I do not (as other people in this comment
thread) run several instances. Sometimes I have a large amount of tabs open, but
not for long. This usually already gets the memory usage above 100 MB. I usually
close and re-start Firefox when it gets above 150 MB.

However, most often, the memory usage climbs up ridiculously even more when I
quit Firefox. Quitting it closes the windows immediately, but the process is
still running and progressively eats more and more memory. By the time it
reached 170 MB for me today, it crashed.

I think this should be the first thing for developers to look at, to ensure that
even if there are memory leaks, we can at least close the browser without
risking a crash. Then you should probably move on to the actual memory leaks.

Comment 13

[brandon]

I believe I'm having a memory related bug also. My machine is an AMD2400XP 
with 512MB ram running XP. I have no swap file. When I start firefox as one 
user I have no problems. But as another user (since last night) it hangs 
immediately ("not responding" in task manager). When it gets to about 384MB it 
just disappears (crashes?). Initially thought it may have been a virus, but 
seems to scan clear. Rebooting had no effect for this user.

If I start it in profile management mode and check the offline box, it starts 
at about 20MB. I can surf a few pages (No multi-tab or windows - just one) 
then it hangs, then crashes as above. 

Also get this happening if in offline mode, then go to Tools + Options + 
Privacy.

Now going to try to flush caches etc... (If I could only find where this is)

Comment 14

[Sebastian Nohn]

Verified with Firefox 0.8 and latest nighlty build on Windows XP.

http://blog.alkoholbedarf.de/archives/374_Feines_Memory_Leak_im_Firefox.html

Comment 15

[Scott MacVicar]

Would be handy if talkback was enabled with firefox builds, does the same 
problem happen with seamonkey?

Comment 16

[Etienne Labonte]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040319
Firefox/0.8.0+

The memory leak problem I have encountered is with the download manager. Memory
goes up with every new download but never goes down until I close the download
manager.

Comment 17

[Adam Hauner]

Michael: Are you still able to reproduce with 0.9 builds? These builds contain
TalkBack utility, so please provide TalkBack ID of your crash.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

Note:

They may (very well) be memory leaks to be dealt with in Firefox and Mozilla. 
We do use tools in tinderbox where a large number of windows are created and
destroyed to see if there are any leaks, but they may not be catching this case.

However:

The description of the way you're using Firefox normally when then occurs (many
windows open with many tabs, displaying many documents (some of them PDFs), is
part of your problem.

Mozilla and Firefox, by adding tabbed browsing, made it reasonable to open far
more web pages than was practical before (or is practical now in IE).  This is
good, in that it enables other ways of interacting with the browser (as you've
discovered).  It's bad, in that it makes is FAR easier to run your computer out
of resources, especially memory.

40 "instances" of Firefox with 10 tabs apiece is 400 web pages open at once. 
Think about that for a second.  Also, if any of those were PDFs (and they were),
you have an instance of Adobe open for each PDF open in a tab - and Adobe is
probably at least several meg, maybe 10+ per instance (depending on the
document).  The more of those pages that were graphics-heavy, the more memory is
required (graphics for pages being displayed are kept in-memory).

So, even with a reasonable amount of memory, 400 web pages (some of them PDFs)
is a LOT of memory use.  No surprise you'd run out, and Windows deals poorly
with running out of memory at times (at least for the app).  Not to mention,
while Mozilla tries to deal with out-of-memory issues, like most modern apps its
low-memory handling is imperfect at best.  With large RAM and fast HD's for VM
being the norm now, people don't work as hard at testing every memory-failure
path as they did (for example) back in the days of the Amiga (or Win 3.1 even).

Now, having it use a inordinate amount of memory (or not drop it's usage) when
opening a bunch of windows/tabs and then closing them would definitely be an
issue worth investigating.  I don't think Mozilla has this same problem (or at
least it didn't), but there is a limit to open windows/tabs for a given memory
size.  At one point, there was a (circa) 50 tab limit per window (or total?)
done to try to limit the impact of another bug, but that was removed in the
pre-1.4 days (I forget when).

One last thing to note: If you click on the firefox icon again, it doesn't start
a new Firefox "instance".  It tells Firefox to open a new window.  Many (most?)
larger windows apps work this way, as does IE.  So if one "instance" (window)
dies, they all do.  Same with IE that I've seen.  One could start separate
instances, but (a) how would you know which windows was part of which instance?
 (b) if you changed a setting/etc in one window, you'd be confused if others
didn't pick up that change (and doing so would involve a lot more code), (c)
they'd have to use separate caches and other temporaries, and (d) they'd use
appreciably _more_ memory per window/"instance" than just opening another window
of the same "instance".

Comment 19

[Michael Jennings]

A recent experience: After two days of opening and closing instances of FireFox,
with two FireFox instances open and maybe 5 tabs total, the FireFox memory usage
in Windows XP was 374,656 kilobytes. When I closed one of the instances, the
memory usage went UP to 385,868 kilobytes.

I will test the latest nightly build, as recommended below, but it will require
several days:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/

Comment 20

[David Fraser]

I found I was having huge memory leaks on Linux with Firefox 0.8, which may be
related.
As a test, I opened a page with about 1400 photo thumbnails on it. Firefox
memory went up to 300+MB. Closing it did not restore the memory.
I have now tested it on Firefox 0.9 builds and a) the memory usage is much less,
and b) it seems to get cleaned up on closing.
If these bugs are similar, people may find opening such a page a quicker way of
testing than waiting for days...

Comment 21

[Jay Patel [:jay]]

It would be great if you could try testing with the latest Firefox release
(0.9.1) and submit Talkback reports for your crashes.  I'm sure the memory leaks
are still around, but it would nice to see if things have improved at all.

Comment 22

[Asa Dotzler [:asa]]

unable to reproduce with the latest branch or trunk builds on XP and FC2.

If you're crashing and can give us a stack trace or a talkback incident ID,
please open a new bug.

If you're experiencing a memory leak and can document it using tools listed at
http://www.mozilla.org/performance/tools.html then please open a new bug. 

Comment 23

[Worcester12345]

(In reply to comment #20)
> I found I was having huge memory leaks on Linux with Firefox 0.8, which may be
> related.
> As a test, I opened a page with about 1400 photo thumbnails on it. Firefox
> memory went up to 300+MB. Closing it did not restore the memory.
> I have now tested it on Firefox 0.9 builds and a) the memory usage is much less,
> and b) it seems to get cleaned up on closing.
> If these bugs are similar, people may find opening such a page a quicker way of
> testing than waiting for days...

Is "WORKSFORME" for anyone to mark, or just for the originator of the bug?

I'd like to hear what Mr. Jennings has to say about this web page with regards
to this bug.

Thanks.

Comment 24

[Michael Jennings]

I'm still testing. I'm testing under actual circumstances, which takes a week or
more.

One completed test showed that FireFox has improved, but there are still
problems with instability in Windows XP.

I'm very interested in having a link to the page mentioned in Comment #20 that
has 1400 thumbnails.

Comment 25

[Michael Jennings]

Cannot test the long-term memory leaks under FireFox 0.92 because all windows
and tabs of FireFox crash before many can be opened. FireFox 0.92 is definitely
far worse than ever before.

See the TalkBack crash log for FireFox 0.92 under Win XP SP1:
http://futurepower.org/FireFox_092_Crash.txt

This is the second crash of FireFox 0.92 on this machine. The crashes occur when
going back and forth rapidly between tabs and Windows. There seems to be no
specific URL that causes the crash. The TalkBack logged crash above occurred
just after loading several JPG photos from Steve's Digicam. One of them was
http://www.steves-digicams.com/2004_reviews/sony_w1/samples/dsc01264.jpg

Beginning to test v. 0.93.

Conditions: The test computer otherwise working perfectly, with no issues
whatsoever. Intel 815EEA2 motherboard, 833MHz Pentium III processor. All
critical patches applied to Win XP SP1.

Comment 26

[Michael Jennings]

Firefox 0.93 is the worst yet for memory leaks. After closing all Firefox
windows, Firefox still owned 126,904 Megabytes. 

Opening perhaps 8 windows and 30 tabs eventually causes Firefox to stop
functioning. For example, the mouse wheel no longer scrolls up and down. After
the limit is reached, it is no longer possible to reload a web page, or bookmark
a page. The Address box no longer updates when switching between tabs.

Comment 27

[:Gavin Sharp [email: [e-mail]]]

Although you may be well intentioned, posting over and over again stating that
"firefox crashed when I loaded lots of tabs" is not helpful to development in
any way. Screenshots of memory usage meters, while useful for demonstrating that
there IS a problem, also do not help actually SOLVE those problems. The summary
and the description of the bug is so broad, that your crash could be caused by
any number of issues with Firefox, or by something completely unrelated (faulty
memory?).

I myself frequently use many windows/tabs and have not been able to reproduce
the crashes you speak of. That is why I will mark this bug WORKSFORME.

That said, you may very well have found an actual bug, and you could very well
contribute to resolving it by using the tools mentioned by Asa at comment 22.
But please, leave this bug as WORKSFORME and file a new one when/if you have
some relatively specific information to describe the bug. General descriptions
of symptoms and anecdotes, like the ones in this bug, will not help resolve any
issues.

Comment 28

[David Fraser]

Re comment 24: I have just tried to reproduce the problem I had in comment 20
with Firefox 0.9.3 on Linux (GTK2).
This doesn't seem to happen anymore. i.e. after closing the page the resources
(particularly X memory and resource allocation) seem to be freed correctly.
In fact Firefox's memory usage doesn't seem to increase to 300MB like it used to
(although the X server does use up a lot of resources while the page is being
displayed).

Comment 29

[David Fraser]

Re comment 27: Surely a Talkback Crash log counts as more than just "it crashed
when I loaded lots of tabs"? In fact it's one of the things Asa asked for in
comment 22.
Re comment 25: Can you open a new bug for this talkback crash as Asa requested
and add a link to it here?

Comment 30

[timeless]

[e-mail]: i don't see a single talkbackid anywhere in this bug report,
i see an absolutely useless copy of the client side talkback data in comment 25.

reporter: please don't bother saving that data or posting it anywhere, we can't
do anything with it. instead please let the talkback app submit the data, and
then run the talkback application to get an incident id which we *could* use.

Comment 31

[Michael Jennings]

Attachment: Firefox 1.0 using 98 percent CPU cycles

Comment 32

[Michael Jennings]

Problem clarified: Before the crash,
Firefox uses almost 100% CPU cycles

See the file attachment in Comment #31, showing Firefox 1.0 taking 98% of the
CPU cycles. The hard disk was idle at that time and had been idle for at least
two minutes. Note that the bug being discussed here crashes TalkBack, too, so
that there are no TalkBack reports.


Testing conditions

1) Toshiba laptop model 2415-S205, 2.0 GHz Mobile Pentium, 512 MB of memory.
Windows XP SP2, all critical patches applied. This is a different computer than
used for any of the other testing.

2) Firefox 1.0 with 200 days of History. Bookmarks file is 2.5 Megabytes.


New Comment

In the original filing of this bug, Firefox was characterized as "slow" as the
problem with the bug advanced toward crashing Firefox. See also comment #10
"slow", comment #6, "all of the browser windows became unresponsive", and
comment #13, ' "not responding" in task manager" '.

Apparently the slowness was caused by Firefox taking a huge percentage of CPU
cycles before crashing.

The problem may have improved since this bug was originally posted, but the bug
is still substantially the same.


Response to criticism

1) Comment #30: "i don't see a single talkbackid anywhere in this bug report,..."

That's because whatever crashes Firefox crashes the TalkBack program as well.

2) Comment #27: "... your crash could be caused by any number of issues with
Firefox, or by something completely unrelated (faulty memory?)."

That's why I tested with several different computers and two operating systems.

3) Comment #27: "... posting over and over again stating that "firefox crashed
when I loaded lots of tabs" is not helpful to development in any way."

Note that the posts were in different versions of Firefox, verifying that the
bug has not been fixed.

4) Comment #27: "I myself frequently use many windows/tabs and have not been
able to reproduce the crashes you speak of. That is why I will mark this bug
WORKSFORME." And, "General descriptions of symptoms and anecdotes, like the ones
in this bug, will not help resolve any issues."

Note that the actual conditions of failure are carefully documented in the
original bug report, and by other authors in Comment #6 and Comment #7.

Note that the criticism in comment #27 does not document the conditions, but
merely recounts the author's anecdote: "I myself frequently use many
windows/tabs..."

What are many? What is frequently?

5) Comment #22: "If you're experiencing a memory leak and can document it using
tools listed at http://www.mozilla.org/performance/tools.html then please open a
new bug."

I've given that suggestion a lot of thought. I have a lot of debugging
experience, but not with those tools. I'm guessing that learning to use the
tools and searching for memory leaks would take at least a month of full-time
work. I'm guessing that someone who knows the tools would take less than 8
hours. At present, I can't afford to volunteer a month of my time.

6) Comment #22: "... then please open a new bug."

It seems to me that opening a new bug report would just tend to detach the issue
from this discussion.


Conclusions

There are no TalkBack reports for this bug, because the bug crashes TalkBack
too, not just Firefox.

After months of considering the suggestion in Comment #22 to use memory leak
tracing tools, I'm guessing it is possible that those tools would not find the
problem. If the problem crashes TalkBack, I'm guessing it will crash the leak
detection tools, too.

Also, leak detection tools detect leaks. The problem may be that Firefox is
corrupting itself, and that there is no memory leak, in the normal sense of the
phrase, meaning failure to de-allocate unused memory.

When "memory leaks" have been reported above, they have not been only due to
failure to de-allocate unused memory, because that would cause no other problems
than a greater use of memory.


About the value of anecdotes

I may have much less experience with code like that in Firefox than some of the
people commenting here. However, I have extensive experience in thinking about
problems of this nature. I think it is a possible theory supported by the facts
that, at this stage of trying to find an elusive bug, anecdotal evidence may be
very valuable.

Discussions of this issue on Slashdot have brought several claims that the bug
is associated with Firefox's connection with other programs, such as when
clicking on a link that starts a Java program or loads a PDF file. That fits
with my experience, also. Since the obvious symptom of the problem apparently
occurs at a much later time than whatever it is that initiates the problem, it
is very difficult to give a more accurate report.

I suggest that one of us could write a Slashdot story asking for anecdotes of
Firefox crashes. Such a story might bring many useless comments, but someone may
have noticed something valuable that would make someone else realize how to find
the bug. I am volunteering to write the Slashdot story, submit it, and see if it
will get published, if that would help. The Slashdot editors have published
several of my submissions, most recently on February 28, 2005, "Non-Technical
Managers in a Technical Company?"


Did someone edit some of the comments above?

It seems to me that some of the comments are not now as they were originally posted.

Comment 33

[Michael Jennings]

There is considerable contention concerning this bug. Some say a bug should not
be reported until it can be fully characterized. Others say that even limited
information about a bug may eventually prove valuable. 

There are 8 more new reports of this bug below. Also, this bug, 222660, is the
same as bug 204668 (the Mozilla version) and bug 246974.

The Mozilla version of this Firefox bug is 204668.
https://bugzilla.mozilla.org/show_bug.cgi?id=204668

Other reports about what seems to be the same bug:

http://slashdot.org/comments.pl?sid=141586&cid=11868266
"basically after using firefox heavily for a while (many tabs open and closed,
often on complex pages) firefox will start eating 100% CPU and become slow as
molasses and never recover."

http://slashdot.org/comments.pl?sid=141586&cid=11875707
"I have found that if I load a PDF document and then use 'Back' to back up to
the page which had the link pointing to the pdf document that Firefox crashes.
Eventually, the adobe reader process also crashes."

http://slashdot.org/comments.pl?sid=141586&cid=11863855
"I'm on a Mac, so it tends to only actually crash when it's loaded down and I
hit a bad flash or java applet"

http://slashdot.org/comments.pl?sid=141586&cid=11863924
"Usually though it [Firefox crash] happens after an extend period of time,
without fail really, as my lone firefox window often stays open for days on end,
so while my usage habits aren't much (compared to some at least) in the short
term, in the long term the crashes have been making me wonder if a memory leak
may be the cause, but sadly I lack the time to investigate it myself."

http://slashdot.org/comments.pl?sid=141586&cid=11864110
"There are bugs that cause memory leaks and slowdowns, relating to plugins and
Javascript. Any one of the pages you have opened could be responsible, it could
well be absolutely nothing to do with the number of pages you have open."

http://slashdot.org/comments.pl?sid=141586&cid=11864102
"When windows runs out of memory, all sorts of strange things happen. I've done
it lots of times doing testing: buttons disappear, applications crash etc."

This report fits with my experience. Often the Firefox bug has seemed connected
with some bug in the way Windows XP handles beginning to use virtual memory.

(Note that, due to software failure, the Slashdot comments are sometimes not
properly nested. Some replies are not under the comment to which they are
replying. The Slashdot thread starts here: 
http://slashdot.org/comments.pl?sid=141586&cid=11863643)

From these comments and others posted in other Slashdot discussions, there seems
to be a general idea that this bug is due to something in the way Firefox and
Mozilla handle plugins. If the plugin does something unexpected, Firefox and
Mozilla crash, possibly many hours later.

Apparently, bug 246974 is a duplicate of this bug:
http://slashdot.org/comments.pl?sid=141586&cid=11878009
"It sounds exactly like this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=246974
Which gets me all the time. Its also been discussed at Mozillazine. Just for the
heck of it, next time FF starts to wig-out, attach gdb to it and print a
backtrace. See if it ends up with about 100 level deep nesting of...
nsPRUint32Key::Clone() const () ...which is interesting, because the file where
nsPRUint32Key::Clone() is defined has some fine comments like the following...
/**
* nsHashtable is OBSOLETE. Use nsTHashtable or a derivative instead.
*/"

Comment 34

[Michael Jennings]

Below: Summary of important facts about this bug. Suggestions. More bug reports
from users.


Summary of important facts:

1) Apparently this bug sometimes eventually results in Mozilla or Firefox using
all the CPU cycles, something that was not noticed during the early years of
testing. When those programs use 99% of CPU cycles, every operation of every
program, not just Mozilla or Firefox, takes 100 times longer, making users think
the OS has crashed.

2) This bug also causes Mozilla or Firefox memory usage to be abnormal.

3) There is often no TalkBack report, since TalkBack sometimes never receives a
message that Mozilla or Firefox is in trouble. On other occasions, there is a
TalkBack report, but the TalkBack information is useless, because TalkBack
crashed, too, apparently.

Apparently users sometimes terminate TalkBack reporting because, with Firefox at
99% CPU utilization, the reporting takes too long, making them think TalkBack
has failed.

4) This bug eventually always occurs in both Mozilla and Firefox. However, with
most usage patterns, the failure takes many days or weeks to occur. It is not
reasonable to ask testers to give an exact method of making the failure happen.

5) This bug has been reported for years, since version 0.61 of Mozilla. It is
apparently substantially the same in both Firefox and Mozilla.


Suggestions:

1) Fix TalkBack, so we don't lose that information. Maybe there could be a
"Write everything to disk" mode that the more dedicated testers could turn on.
Holding everything in memory cannot be useful when the bug is essentially
crashing the OS.

Maybe some testers could have a version of TalkBack that would have a "Trigger
TalkBack Report" menu choice.

2) Recognize that some bugs are far more difficult to find than others, and that
poorly characterized reports may be better than nothing in difficult cases.

3) Read the end of comment #33 of this bug, 222660. Someone has reported an area
of code that seems like a good candidate for causing this problem.

4) Recognize that the reporters of bugs are doing the best they can, under the
circumstances that apply to them.

5) Recognize that no one is implying anything negative about the Mozilla team.
This is a very difficult bug to characterize.

6) Recognize that the partial failure of the Mozilla social group, as reported here:
http://developers.slashdot.org/article.pl?sid=05/03/06/2232211
requires sophisticated debugging, and that is even more important than any
debugging software failure.


More reports from users, sometimes imperfect and confused, with minimal editing
for clarity:

http://developers.slashdot.org/comments.pl?sid=141586&cid=11864609
"The last few releases have a habit of freezing up in various ways. It's not
something that happens every day, but it happens a lot more than it used to."

http://developers.slashdot.org/comments.pl?sid=141586&cid=11865831
"... firefox DOES NOT let other applications that need it [memory] get it back.
it [Firefox] routinely crawls the machine to a halt until it's killed and
restarted."

http://developers.slashdot.org/comments.pl?sid=141586&cid=11866690
"[Firefox] really shouldn't use as much memory as it does, and it shouldn't have
the memory retention policy that it does either. The amount of memory that it
uses does matter, because it completely fragments the heap, it pushes the
address space of other programs to disk, and it performs... [badly] after you've
used another program that requires a lot of memory.

Comment 35

[Michael Jennings]

An idea: Create a latest build of Firefox and Mozilla with a stack dump menu
choice. Both Firefox and Mozilla usually show they are sick long before a crash.
If I could do voluntary stack dumps, I could post the most relevant ones. This
is in response to bug 204668, comment #9, "In particular for crashes we need the
stack to help to find the real cause, because no-one could reproduce it we don't
have a stack. Without it fixing almost impossible."

I can sympathize with this, from bug 204668, comment #9: "We see a lot of bug
reports with insufficient information..." However, what's happening here is not
only a case of sloppy, less educated reporters. This bug is genuinely difficult
to characterize. I realize that, under the circumstances, it was difficult to
realize that this situation is different.

Comment 36

[timeless]

please no more ideas. build mozilla or firefox debug and crash it. do yourself a
favor and run them from a |screen|d session so that you can get back to them
later, i'd suggest running gdb from another terminal, also in |screen|d,

generally i do:
(ps aux|grep mozilla-bin);./mozilla -g -d gdb
attach [pid from ps output]

you may need to use |c| to continue, eventually when you crash, use |bt|.

Comment 37

[Ryuichi KUBUKI]

Is this bug about crash or memory leak?

I observe no crash on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2)
Gecko/20050523 Firefox/1.0+ for typical usage.

Comment 38

[Worcester12345]

Is this bug obsolete, invalid, or should the title at least change? I was
reading up on memory leak bugs here: 
http://forums.mozillazine.org/viewtopic.php?t=141658&highlight=mlk+memory

and somehow wound up on this bug. Thanks.

Comment 39

[Michael Jennings]

This is a showstopper bug. After Mozilla, Firefox, or Thunderbird have been in
use for several days, all of the latest versions of those programs (Mozilla
1.7.11, Firefox 1.07, and Thunderbird 1.06) begin taking a large amount of CPU
time, even when idle, and eventually crash.

When I post comments to Slashdot, such as this one, 
http://slashdot.org/comments.pl?sid=163772&cid=13678221
generally there are replies from people saying that they have stopped reporting
showstopper bugs because they are not fixed. I first reported this bug 2 1/2
years ago.

One reply to another comment suggested the bug was associated with the way
Mozilla products handle plugins.

See https://bugzilla.mozilla.org/show_bug.cgi?id=204668
This is the same bug, apparently.

This bug is associated with unreasonable memory use, too.

Comment 40

[Benjamin Smedberg]

We can't fix what we can't understand. INVALID. If you can figure out why this
is happening, please file a new bug with sufficient detail to examine and fix
the bug.

Comment 41

[Michael Jennings]

We have been discussing this bug on Slashdot again today:

Title of comment: I reported the crashing 2 1/2 years ago!
http://slashdot.org/comments.pl?sid=165784&cid=13831071

The answer from Mozilla people has always been: "Did you try the latest version,
compiled last night? The problem may be fixed." By the time I can test the
latest version, there is a new version. I get the same answer again. That's
happened for 2 1/2 years. 

The parent comment that started the discussion about memory management problems
is here:
http://slashdot.org/comments.pl?sid=165784&cid=13828636

Note that it is not only me who has seen this bug for years.

Comment 42

[Michael Jennings]

Attachment: Windows Task Manager shows Firefox using 96% CPU.

Associated with Comment #42. Version 1.0.7 of Firefox tested.

Comment 43

[Michael Jennings]

Failure: Firefox used 96% CPU time.

Reproducibility: 100%. This failure is completely reproducible, and has been since Firefox version 0.8. The failure is identical in Mozilla browser. When last tested in Linux, the failure was identical. For reporting of this bug in Mozilla, see Bugzilla bug 204668.

Reliable method of reproducing this bug: Open and close Firefox windows and tabs for two weeks, or until Firefox crashes. The failure may occur much sooner than two weeks. Note that since it takes a long time for a user to open and close many windows during normal use, it is never possible to test the latest nightly version on the day the bug occurs.

Tested version: Firefox version 1.0.7, Windows XP Service Pack 2, all critical updates applied. Everything besides Firefox working perfectly.

Hardware: Toshiba laptop, working perfectly.

Failure conditions for the particular failure being reported: Firefox ran perfectly for 2 weeks. After hibernating Windows twice, Firefox began using 96% CPU time, as shown in Windows Task Manager. (See attached screen shot.) At that time, there were 14 Firefox windows open, some with many tabs. When Firefox first began using 96% CPU time, the responsiveness of the computer was still acceptable. After opening and closing a few more tabs and windows, the computer became so slow as to be unusable.

Talkback reports: Usually there are none. Either Talkback is not called, or Talkback crashes too.

Ease of characterization of this bug: Extremely difficult. 

Guesses as to the cause of this bug: Many users report that the problem occurs after hibernation of the OS. The problem seems associated with use of virtual memory; installing more actual memory definitely decreases the rate incidence of this bug. Other times it has seemed that this bug is associated with Firefox's handling of plug-ins.

Reports of problems from other people:
http://ask.slashdot.org/comments.pl?sid=167814&cid=13994698
http://ask.slashdot.org/comments.pl?sid=167814&cid=14002741 (Quote: I'm sick of Firefox crashes.)

Comment 44

[Michael Jennings]

Comment on attachment 202670 [details]
Windows Task Manager shows Firefox using 96% CPU.

Associated with Comment #43.

Comment 45

[Mike Connor [:mconnor]]

Do we have crash and hang bugs? Sure, absolutely, just search on bugs marked critical.  Is this particular bug which is basically saying "bad things happen sometimes" of any use?  Not at all.  There are bugs on memory leaks, many of which have been fixed for 1.5, same with crashes, and the hibernation issue you mentioned.

I'm going to mark this particular bug as INVALID again, because it is of a vast and unfixable scope.  Sooner or later, if you browse enough sites, you can hit a crash bug.  That doesn't mean its the same crash (code flaw) every time, or a single fix can change that.

Comment 46

[Michael Jennings]

PROGRESS: Testing in Firefox v. 1.5 RC3 -- CROSS-PLATFORM SHOWSTOPPER BUG

SPECULATION: Possibly this bug happens because Firefox hogs the OS event handler. This seems reasonable since tasks outside the event handler seem to run at normal speed, even when Firefox is using 90% CPU.

This bug is worse, and therefore easier to reproduce, in RC3. CPU hogging now happens sooner. Increases in CPU hogging after hibernation happens sooner. Firefox v. 1.0.7 is better than v. 1.5 RC2, and RC2 is better than RC3. This suggests that the bug is related to over-running an allocated memory resource that is in shorter supply due to other bug fixes.

FACTS ABOUT THIS BUG:

1) It is not related to any particular web page. It is not a "crash bug" or "hang bug". While this bug may appear to have crashed or hung the OS, actually everything operates perfectly, but at one-fiftieth speed, for example, because Firefox is taking 98% of the CPU time.

2) This bug cannot be characterized further without use of a debugger. Those who report this bug cannot do more than they have already done. On the other hand, the bug should be very easy to find with a debugger or profiler. Since this bug is easy to reproduce, and difficult for non-programmers to characterize, it makes sense that developers should characterize it.

3) The CPU hogging and memory hogging seem to be symptoms of the same bug, since both occur and progress together. Those who have low amounts of installed memory notice the memory hogging first. Those who have a low amount of memory experience extreme slowness due to thrashing of the hard drive because of virtual memory access.

____________________________

MORE COMMENTS ABOUT THIS CPU AND MEMORY HOGGING BUG IN FIREFOX:

FROM:
http://slashdot.org/comments.pl?sid=168683&cid=14062209

"Every time I use firefox and open a few tabs my vm size goes to 1GB. It's getting ridiculous how developers of firefox are ignoring to fix this problem."

FROM:
http://slashdot.org/comments.pl?sid=168683&cid=14062501

"I love firefox, but after using it extensively for a couple of hours it occupies about a third of my available memory and a lot of VM. I know that there are a lot of complains about this but I have found no solution. This should definitely be the top priority for firefox developers."

FROM:
http://slashdot.org/comments.pl?sid=168683&cid=14062671

"I have the same issues [memory leaks], up to 1.5 rc2 and the 1.0.x series.

"... this is a LONGSTANDING issue that has not gotten any attention.

"I have 1GB of RAM (FF usually peaks at about 160MB for me before I restart it) so I dont care that much, but I know lots of users on lo-mem systems who are highly annoyed by this behavior and switched to Opera. I think this kind of thing should be a high priority critical/major bug and receive attention ASAP."

FROM:
http://slashdot.org/comments.pl?sid=168683&cid=14063971

"In my opinion, this bug is the most important thing that makes me question the usability of FF. Really, I need to adjust my browsing behavior in order to deal with this bug, and constantly check task manager (>300Mb => restart)."

FROM:
http://slashdot.org/comments.pl?sid=168683&cid=14067985

"People are posting to Slashdot because nothing is happening. These and related bugs are not getting fixed and have been lingering for years. Many of my friends and family have given up. They are loyal Opera users."

____________________________

REACTION TO COMMENT #45:

I posted an excerpt from Comment #45 to a Slashdot story:
CPU hogging bug is much worse in RC2.
http://slashdot.org/comments.pl?sid=168683&cid=14063163

Here are some responses:

FROM:
http://slashdot.org/comments.pl?sid=168683&cid=14066613

"This [bug] is not vague or unreproducable. I know countless numbers of people who have problems with memory and/or CPU hogging with Firefox.

"Just because we are all not programmers who can sit here and run gdb to debug our everyday browsing does NOT make this an invalid bug. The fact that this is so extensively widespread but isn't getting fixed is a testament to a major problem with Mozilla's programmers.

"If they are "being fixed all the time", then why have these issues NEVER disappeared across at least two major versions?"

FROM:
http://slashdot.org/comments.pl?sid=168683&cid=14063938

"I have given up on FF as the default browser because of the "hogging" bug. My Mac will not goto or awake from sleep properly when FF is active about 1/4 of the time.

"Also, my activity monitor, after awhile, will show 90 to 100% activity when nothing is going on. If I quit FF, it goes away."

____________________________

MOZILLA HAS EXACTLY THE SAME ISSUES:

Linux/Windows Reproducible Crash Tests
https://bugzilla.mozilla.org/show_bug.cgi?id=204668
(The bug reported here, 222660, is also present in Mozilla.)

____________________________

BUG THAT MAY BE RELATED:

Memory leak (especially in graphics-intensive webpages), freed upon minimize
https://bugzilla.mozilla.org/show_bug.cgi?id=249469
(The severe memory leaks in this bug, 222660, do not free after minimizing.)

Comment 47

[Michael Jennings]

Firefox v. 1.5 RC3:

Three more test cycles show that the CPU and memory hogging bug in Firefox v. 1.5 RC3 is much worse than in previous versions.

This is, in one way, an advantage, because now it is possible to demonstrate the bug in less than a day. In previous versions, demonstrating this bug might require up to two weeks.

For people who do a lot of research on the internet, or who would otherwise have many windows and tabs open at the same time, Firefox v. 1.5 RC3 is not an option. Unfortunately for those people, in other ways Firefox is the best browser available.

The bug happens only because of use of Firefox and not because of visiting any particular URL. In Windows XP SP2, all critical updates applied, the Task Manager typically shows perhaps 4% CPU use by Firefox with no activity, with maybe 5 megabytes memory use per tab, even though most tabs display HTML pages of no more than 20,000 bytes. During use, the CPU use grows until it eventually until it becomes 94%. With continued use of Firefox, the computer becomes unusable until all Firefox windows and tabs are closed.

Comment 48

[Michael Jennings]

Attachment: CPU hogging bug affects Firefox, Mozilla, and Thunderbird

CPU, memory hogging bug in Firefox, Mozilla, and Thunderbird

The attachment shows that the CPU and memory hogging bug affects not only Firefox, but Mozilla and Thunderbird, too.

Facts about the bug: 

1) Much worse with Firefox 1.5. Now Firefox is unusable for people who do extensive research. When the CPU hogging starts, all instances and tabs must be closed to recover full use of the CPU. This is very inconvenient, to say the least.

2) Affects only Firefox, Mozilla, and Thunderbird. No other programs malfunction like these.

3) Has been present since Firefox 0.8.

4) Very easy to reproduce. Someone with knowledge of the code could easily investigate.

5) The bug is related to opening and closing windows and tabs in Mozilla.org browsers.

6) The bug is often much worse when the computer (a Toshiba laptop in this particular case) comes out of Standby.

7) This is by far the most interesting bug in the Mozilla family of programs. Unlike other bugs, finding the cause of this requires a scientifically oriented investigation, in which facts are gathered, and theories are made and tested.

8) Something in Firefox initiates the problem in Mozilla and Thunderbird.

9) Conditions: 

a) Windows XP SP2, all critical updates applied. 

b) No other malfunctions despite use of many other programs.

c) Neither Firefox or Mozilla browsers are allowed to open PDF or other files requiring plugins. 

d) Bug is apparently not related to installed extensions. Extensions installed in Firefox: DOM Inspector 1.8, TalkBack 1.5, Image Zoom 0.2.1, Adblock 0.52.0.56, Flashblock 1.5.

e) Mozilla browser is used only to read Google News. That way, if it crashes, it does not affect Firefox, which has windows and tabs devoted to research.

f) Tests done on Toshiba Satellite Laptop model 2415-S205. Previous tests show that the problem is the same with widely varying motherboards, processors.

g) 1,000 Megabytes memory. Pasts tests have shown that the bug is related to the amount of memory installed. Having more memory delays the onset of the bug.

h) Previous tests show the problem occurs under Linux, too.

Comment 49

[Michael Jennings]

Attachment: Screenshot shows cause of CPU and memory hogging bug.

Windows Task Manager screen shot: I/O Other Bytes increasing 20K/second with no program activity. 

Whatever causes the I/O Other Bytes to increase hogs the CPU.

This particular screen shot shows CPU hogging by Mozilla Mail, but the problem is the same in Firefox, as will be shown in the next attachment.

The CPU hogging in Mozilla Mail was somehow caused by extensive use of Firefox, which at the time of the screen shot had been closed to recover normal use of the computer.

Task Manager entries have been sorted by CPU (CPU use percentage) by clicking on the CPU column header.

Comment 50

[Michael Jennings]

Attachment: Firefox CPU hogging: Screen shot shows cause.

Firefox using 27% of the CPU. "I/O Other Bytes" is growing by 20 bytes each 3 seconds (not 20K), with no program activity. Only 6 Firefox windows open.

The problem will soon be much worse, after opening and closing more Firefox windows and tabs, or after returning again from Standby. Eventually the Firefox CPU usage will be 94%, and all operations on the computer will become very slow. At that time, the Firefox I/O Other Bytes will be growing much faster, even though there is no activity in any program, and no keyboard or mouse or disk activity.

Mozilla is not open.

As mentioned, the problem is often, but not always, made worse by putting the laptop on Standby and then returning from Standby. 

Conditions are the same as in Comment #48. Firefox 1.5.

Windows Task Manager screen shot, sorted by clicking on the CPU column (CPU %) header twice. 

(Researching banks and money market interest rates in Firefox. Also some Slashdot.org stories open. Opera is installed in several folders, without profiles so that multiple Opera windows can be used. Most of the research is in Opera tabs. Opera does not have the CPU and memory hogging bug, even when 50 tabs are opened, and even though there is intensive activity loading and closing very complex and large web pages. However, Firefox has a better user interface than Opera.)

Comment 51

[HJ]

My system details: Mac OS 10.3.9, all patches. G4 Powerbook 1.25 GHz, 512MB RAM. FF 1.5 final [Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051111 Firefox/1.5].

A text search of the many comments only shows one mention of Mac OS X, so I'll chime in with my two cents. FF 1.5 becomes virtually unusable about one out of every four sessions due to behavior that looks a whole lot like what is described in the parent. Far from being invalid, *this is a showstopper for me* and will prompt me to switch to Safari (from which I am posting now), Opera, or even IE if it keeps happening.

Initially, I noticed the slows-to-a-crawl behavior to be roughly correlated with having lots of tabs (between about 15 and 30) open at once. I couldn't determine if it was something specific to the content of those tabs.

However, using the example link in a post I found on Slashdot today (http://slashdot.org/comments.pl?sid=171357&threshold=0&commentsort=3&tid=154&mode=nested&cid=14271754), I was able to hang up and crash FF 1.5 with just three tabs, each open to the same page (http://www.gnu.org/software/libc/manual/html_mono/libc.html). This was in addition to another crash (with about 20 tabs open, but not the libc page) I got earlier today! To quantify:

- At initial launch (homepage is Slashdot), the OS X Activity Monitor shows FF 1.5 using 1% CPU and 51.4MB of real memory. By comparison, Safari is about 1%, 24.8MB.

- Opening a *single copy* of the gnu page mentioned above causes FF's CPU usage to spike to over 90% and real memory usage to over 150MB.

- After the page is finished loading, the CPU drops back down to around 1%. However the real memory 
usage remains above 150MB.

- Returning to my homepage leaves the CPU around 1%, *but the real memory remails above 150MB*.

- Opening two or more tabs with this page causes FF to hang, then crash.

In response to Asa's comment #22 from over a year ago, here are four talkback IDs: TB13023234G, TB13022667K, TB13012245E, and TB12679698W. i believe all four illustrate this horrible memory leak, all with FF 1.5 final.

So: This is definitely not an invalid bug. It is a **major** problem, affects OS X as well as Windows, is easily reproducible, and not only still exists but seems to be getting worse than before (I don't think I ever saw this with 1.0.7).

I respectfully submit that this memory leak renders one of the most prominent advantages of FF over, say, IE -- tabbed browsing -- substantially useless.

Comment 52

[Mike Connor [:mconnor]]

(In reply to comment #50)
> Created an attachment (id=205042) [edit]
> Firefox CPU hogging: Screen shot shows cause.
> 
> 
> Firefox using 27% of the CPU. "I/O Other Bytes" is growing by 20 bytes each 3
> seconds (not 20K), with no program activity. Only 6 Firefox windows open.

If you're going to cite a tool, understand its output.  I/O Other Bytes isn't memory, its just how much that process is communicating with the OS.
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/prork/preb_mon_nbcl.asp

It seems like you're grasping at straws.  Even if that was related to memory usage, it still wouldn't be a cause, because its measuring activity, not identifying the code/architecture problem that is causing us to not release memory when we should be.

I haven't bothered to track down exact matches for the litany of complaints you naively assume are a single bug, but its a fallacy to assume that they don't exist because I didn't take the time to search on your behalf.  That said, the following steps will hopefully show you the scope of what we're dealing with in this project.

- If you want bugs on crashes or hangs, search on bugs 
  with a severity of critical.
- If you want memory leak bugs, search on bugs with the 
  mlk keyword.  There's lots, some more obscure than others.  
- There's also http://talkback-public.mozilla.org/talkback/fastfind.jsp 
  if you want to see top crashers and associated bugs.

You also might be interested to know that with 1.5's faster back/forward navigation, we do use more memory, and allocate more memory depending on how much is available to the system.

Comment 53

[Patrick Tufts]

I have observed the same behavior on all recent RC and stable versions of Firefox and Thunderbird. However, if I then put either program in OFFLINE mode, the CPU consumption drops from 95-100% down to 2%.

Perhaps this bug has to so with suspend/resume and networking?

I am currently runing FF 1.5

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

And Thunderbird 1.5

version 1.5 (20051025)

--Pat

Comment 54

[Michael Jennings]

Comment #53 from Patrick Tufts is interesting.

I also have observed that, during CPU hogging, the CPU use of all Firefox windows and tabs, no matter how many are open, will go from 94% to 0% when File/ Work Offline/ is chosen. When that option is unchecked, the CPU use instantly goes back to 94%. 

My guess is that observation isolates the bug to a small part of the code.

Comment 55

[Michael Jennings]

Attachment: 1.5.0.1 is the worst yet. Clean profile, no extensions.

Firefox 1.5.0.1 is the worst yet. Firefox is the most unstable program in common use.

http://slashdot.org/comments.pl?sid=175800&cid=14612269

Comment 56

[HJ]

The "work offline" bit does not have any apparent effect on my machine. Tiger 10.4.4, 1.25GB RAM, Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1.

Have been browsing for ~15 minutes, now have two tabs open (bugzilla form plus one other). Activity Monitor shows FF using 255MB of real memory and ~50% CPU. Toggling "work offline" back and forth doesn't do anything at all to these numbers.

Comment 57

[Michael Jennings]

Success! My testing shows that Firefox 1.5.0.3 still has the CPU hogging
problem, but that the problem disappears when particular extensions are
installed.

The extensions I have installed that have somehow caused Firefox 1.5.0.3 to be
stable are: Flashblock 1.5.1, Image Zoom 0.2.5 (or 0.2.4), Talkback 1.5.0.3,
and DOM Inspector 1.8.0.3.

My guess is that it is Flashblock that cures the CPU hogging problem. The
problem is cured even though I often decide to watch Flash objects in web
pages.

I have no theory about why installing these extensions should make a
difference.

With this 1.5.0.3 version of Firefox, the CPU hogging problem was the worst I
have ever seen. It caused major problems within 4 hours of beginning to use
Firefox, slowing the entire computer. I had been using Firefox installed with
a clean install, with no extensions other than Talkback.

Then I installed the extensions, and the CPU problem disappeared.

Having Firefox work reliably is a big relief for me. I often have to do
research on several computer software or hardware items at the same time, and
I open at least one Firefox window for each manufacturer, always with many
tabs. Firefox is the most efficient browser to use for that, even though the
CPU hogging was a huge time waster.

My last Talkback incident was a severe crash: TB18589230M on 2006-05-11. It
seemed obvious why that crash occurred: Not enough resources are allocated
inside Firefox for events. So, someone who is working very fast can outrun or
overuse the GUI resources.