374746 - SeaMonkey has become increasingly unstable for long continuous use, frequent freezes, and occasional crashes are guaranteed

Status: RESOLVED DUPLICATE of bug 342810

(SeaMonkey :: General, defect)

Description

[Kent Paul Dolan]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070313 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070313 SeaMonkey/1.5a

Over the last year, SeaMonkey nightly builds have
become more freeze prone, and more crash prone, with
long (days rather than hours) ongoing use, to the
point that my behavior has had to change to
frequently closing and reopening SeaMonkey, at any
point where I'm not adding intellectual content in
any tab, merely to avoid lock-ups.

This vastly decreases the utility and attractiveness
of the browser to the heavy user.

This degraded use is accompanied by SeaMonkey having
an incredible appetite for RAM. Launched with a
footprint of around 80 Mbytes of RAM, it is often
seen to be holding up to 640+ MBytes of RAM when tab
painting or external to tab painting starts to
"freeze up", but can "lose its mind" at levels as
low as 140 MBytes of RAM held captive.

Evidently it is grabbing far more real estate than
it knows how to manage.

In a machine with only 1 GByte of RAM, any one
application grabbing 65% of it is simply
unacceptable, a "doesn't play well with others"
style of behavior.

Specific symptoms prior to freezing entirely
include, in an order something like this:

  Banner ads and other active parts of web pages
  overwritten with alternating bands of grainy black
  and white stripes, when the computer is left idle
  for a few hours.

  Doing a "next" on a series of pages (like comics
  or other pages which display similarly laid out
  material in a series) refreshes only the
  "foreground" (comic, ad, widgets) stuff, but where
  these may have changed size between pages, fails
  to redraw the page background over the superseded
  prior version visible selvage of these active
  parts. For example, the remainder of the larger
  Sunday comic would not be overpainted with the web
  page background when the next, smaller Monday
  comic was displayed over it.

  Tab buttons don't get repainted.

  Toolbars don't get repainted.

  Menu toolbar menus, when clicked, fail to appear,
  but when dragged over, paint themselves menu item
  by menu item.

  The vertical slider becomes unusable.

At that point SeaMonkey is unusable, and usually
also cannot be closed without use of the task
manager.

This behavior is inevitable if SeaMonkey is
simply used actively and for a long enough time.
No particular URL or type of URL seems to be
involved, though heavily image laden ones make
it all happen sooner, sometimes as little as 90
minutes of viewing or downloading images from
some site like Flickr will freeze SeaMonkey.

xanthian.


Reproducible: Always

Steps to Reproduce:
1. Use SeaMonkey heavily and for long enough.
2.
3.
Actual Results:  
SeaMonkey grabs huge amounts of RAM,
freezes or crashes, must be killed
from the task manager and restarted.

Expected Results:  
SeaMonkey sips RAM rather than gobbling it,
retains its mind and continues to function.

There is rarely any data loss involved
in all this. Once in a while the latest
history entry or most recently saved
bookmark goes missing, but nothing more
troubling.

Comment 1

[Wayne Mery (:wsmwk)]

in future reports, could you please be less wordish and still provide detail, like a URL and setting version correctly? It would help a LOT.

Comment 2

[Kent Paul Dolan]

(In reply to comment #1)
> in future reports, could you please be less wordish and still provide detail,
> like a URL and setting version correctly? It would help a LOT.

> *** This bug has been marked as a duplicate of bug 342810 ***

Asking for a URL for a bug report which is obviously not URL
specific isn't sane.

The version is conveyed by bugzilla, I have nothing to do with
that.

Marking this bug a duplicate of 342810 is pure speculation on
your part. Nothing in this bug report referenced Flash.

I'm not about to re-open this, but you should mark it "wontfix",
not pretend it is a duplicate, if your intention is to leave the
bug festering in SeaMonkey out of indolence or incompetence.

It isn't like the described behavior is difficult to reproduce;
it happens every time SeaMonkey is used.

xanthian.