608954 - Seamonkey memory leak

Status: RESOLVED DUPLICATE of bug 713216

(Core :: JavaScript: GC, defect)

Description

[Phoenix]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101101 Firefox/4.0b8pre SeaMonkey/2.1b2pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b8pre) Gecko/20101101 Firefox/4.0b8pre SeaMonkey/2.1b2pre

Hello
I've experiencing problems with Seamonkey freezes when it runs more than one day and at least one video were watched online (most easy case to reproduce).
First I've faced freeze problems a couple of month ago, when installed for test purposes Firebug plugin. Uninstalling it solves the problem, so I think that is a plugin problem, and forgot about it. But in October I've faced this problem again, and this time no new plugin or Seamonkey update was installed. After performing several tests I've see, that in some circumstances Seamonkey fully occupies 1 core of my dual-core cpu. Process Explorer show thread, responsible for it - seamonkey.exe!jsj_JavaInstanceMethodWrapper+0x7d748, it's stack was:
ntkrnlpa.exe+0x6e9eb
ntkrnlpa.exe+0x2bf8c
hal.dll+0x2ef2
js3250.dll!JS_CallTracer+0x25
js3250.dll!js_CheckUndeclaredVarAssignment+0x19fb
I've searched through Internet, found several similar issues, but provided advices doesn't help (recreating profile from blank, update plugins to latest versions, disable several NoScript functions and some other...), I've even tried special SSE2 builds of Seamonkey, it's performance grew up, but freezes doesn't disappear. For test purposes I've disabled all Extensions, and most of the Plugins, that also doesn't help.
Searching for solution, I've updated Seamonkey to version 2.1b2pre, found that plugins now runs in separated plugin-container.exe thread, but problem doesn't disappear (with or without Extensions/Plugins)
Also checks for relation to CPU power saving - no luck, Seamonkey freezes no matter when CPU works on full 2.7 GHz or drop speed to 1 GHz.

Reproducible: Always

Steps to Reproduce:
1. Start Seamonkey
2. Watch several YouTube videos
3. Don't unload Seamonkey for day or two
Actual Results:  
On next day (most time) Seamonkey starts to freeze on regular pages, even with simple text only. Most suffers wheel scroll feature, I can scroll the page with mouse wheel in several seconds after animation on pages (gif or flash) starts to work again.

Expected Results:  
Seamonkey doesn't freeze

Watching video just speeds up problem appearance, in other case it appearing near after week
Tested builds:
Seamonkey 2.0.8/2.0.9 regular builds
Seamonkey 2.0.7/2.0.9 SSE2 builds from http://sites.google.com/site/s7930162/home
Seamonkey 2.1b2pre
Installed extensions:
Adblock Plus 1.2.2
Adblock Plus Element Hiding Helper 1.0.6
ChatZilla 0.9.86
DOM Inspector 2.0.8
Firebug 1.6X.0b3
FxIF 0.4.2
JavaScript Debugger 0.9.88.1
NoScript 2.0.4
Russian Spellcheck 0.4.4
SeaMonkey Debug and QA UI 1.0pre
Stylish 1.0.11
Ukrainian Spellcheck 1.6.0
Plugins: http://img203.imageshack.us/img203/8058/smplugins.png
Theme: SeaMonkey Modern 1.0
OS: Windows XP SP3, fully updated
CPU: AMD Athlon 64 X2 5200+ (2.7 GHz)

Also, I'll attach several stack dumps for different builds on freeze, hope it helps to investigate source of the problem.
If any additional information or tests is needed, feel free to ask.

Comment 1

[Phoenix]

Attachment: Process Explorer freezed thread infos

Comment 2

[Phoenix]

Attachment: Yet another hang

Today things get worse, SeaMonkey stuck with near 20 windows open, consuming all power from one core and doesn't responding to any actions. Process Explorer show it's activity, most of it was in mozjs.dll (stack example on the attached screenshot), after 10 minutes Seamonkey was still irresponsible, so I've killed process. After it restarting with restoring all previous windows, all runs fine...at least for next couple of days...

Comment 3

[Phoenix]

Is anybody alive here?

Comment 4

[Philip Chee]

Do you still see the same problem with SeaMonkey 2.1b1 (or the current nightly build 2.1b2pre). Note install in a different directory than 2.0 and test with a different profile.

Also to generate a useful trace you will need a nightly build and windbg.

Comment 5

[Phoenix]

Updated to latest nightly build (unpacked in separate folder):
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110203 Firefox/4.0b12pre SeaMonkey/2.1b2pre
Problem still exists.
What information from windbg needed? I'm not very familiar with it, and before use it only on applications crashes. Using it as usual, I tried to catch high CPU usage moment, and take stack info for "high usage" threads, it is in new attachment.
If some other information must be collected, please provide an instruction (or link to it) for needed data collection

Comment 6

[Phoenix]

Attachment: useless

Comment 7

[timeless]

Comment on attachment 510274 [details]
useless

Please follow the instructions in: https://developer.mozilla.org/en/how_to_get_a_stacktrace_with_windbg

Comment 8

[Phoenix]

Attachment: Crash on new windows\tabs open

Followed the instructions and here is results. Used build:
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110207 Firefox/4.0b12pre SeaMonkey/2.1b3pre
This crash occurred, when I open one after another two windows from bookmarks, first with 7 tabs, second with 18 tabs

Comment 9

[Phoenix]

Attachment: Crash on start in debugger

Just after crash, I restarted debugger and try to start Seamonkey again, but it refuses to do so, here is the log from windbg. Starting Seamonkey without windbg works, later I'll try again to start it in debugger

Comment 10

[Phoenix]

Attachment: Crash on middle-click on bookmarks group

Another crash, just almost after start, I use middle click on bookmarks folder on bookmarks panel, log attached

Comment 11

[Phoenix]

Attachment: Crash on middle-click on hyperlink

Suspecting, that crashes somehow connected with middle clicking, I've start to open all hyperlinks with it, and near 10 opened page SeaMonkey crashed again. Log attached

Comment 12

[Phoenix]

Any news?

Comment 13

[Philip Chee]

Somebody who knows how to read these stack traces will have to come around and comment. I'll CC timeless since he commented here earlier.

Comment 14

[timeless]

1. if you're using seamonkey then i think sympath has to say 'seamonkey' instead of 'firefox', otherwise you won't get symbols and hence your stacks will be next to useless.
2. if you're hitting an application restart, you kind of need to know to just <g>o past it (or attach later or ask the app to skip the restart phases), i believe this happened in attachment 510974 [details], you can see you're quiting because it says:
> 0012f5cc 7813179e kernel32!ExitProcess+0x14
-- I have to hope this is for a restart

3. you need to <g>o past break instructions:
> (12ac.1684): Break instruction exception - code 80000003 (first chance)

that's just to enable you to do things like setting breakpoints and whatever debugger setup you want to do, but you don't want to do any.

Sorry, there's nothing here yet.

Philip: please see if there's anything you can do to improve the url we're using to ensure reporters don't hit as many of these snags. Thanks. Please cc me when there are new traces if they look helpful.

Oh, for my sanity, reporter, when you attach your next log, please obsolete all of the other attachments.

Comment 15

[Phoenix]

(In reply to comment #14)
> 1. if you're using seamonkey then i think sympath has to say 'seamonkey'
> instead of 'firefox', otherwise you won't get symbols and hence your stacks
> will be next to useless.
I've tested in windbg both sympath 'firefox' and 'seamonkey', the only difference between them is that 'seamonkey' 10-100 times slower
symchk also show same results
C:\Program Files\Debugging Tools for Windows (x86)>symchk "C:\Program Files\SeaMonkey\*" /s SRV*C:\symcache\*http://symbols.mozilla.org/firefox
SYMCHK: FAILED files = 28
SYMCHK: PASSED + IGNORED files = 16
C:\Program Files\Debugging Tools for Windows (x86)>symchk "C:\Program Files\SeaMonkey\*" /s SRV*C:\symcache\*http://symbols.mozilla.org/seamonkey
SYMCHK: FAILED files = 28
SYMCHK: PASSED + IGNORED files = 16

> 3. you need to <g>o past break instructions:
> > (12ac.1684): Break instruction exception - code 80000003 (first chance)
> 
> that's just to enable you to do things like setting breakpoints and whatever
> debugger setup you want to do, but you don't want to do any.
In first tests I can'to go after it, receiving same error, but now it's go fine. I'll try to provide needed results with next report.

> Oh, for my sanity, reporter, when you attach your next log, please obsolete all
> of the other attachments.
Done

Comment 16

[Phoenix]

Attachment: First trace at interface freeze

First catch, SeaMonkey running for two days, freezes occurs and catched in LiveJournal post add form.
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110214 Firefox/4.0b12pre SeaMonkey/2.1b3pre

Comment 17

[Phoenix]

Attachment: Second trace on interface freeze

This was catched after several hours of SeaMonkey running, on opening near 10 new windows from forum
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12pre) Gecko/20110216 Firefox/4.0b12pre SeaMonkey/2.1b3pre

If any additional info is needed, please inform me

Comment 18

[Philip Chee]

Hi!

Can you use the following path for the symbol server? thanks.
http://symbols.mozilla.org/seamonkey (instead of firefox).

Comment 19

[Phoenix]

Hello
As I explained in comment 15 (https://bugzilla.mozilla.org/show_bug.cgi?id=608954#c15), I find no difference between http://symbols.mozilla.org/seamonkey and http://symbols.mozilla.org/firefox symbol servers, but if you insist I'll do this, despite it taking more than hour to start Seamonkey with that server...

Comment 20

[Philip Chee]

Oh sorry.

Comment 21

[timeless]

sorry, if you can't get seamonkey to work, then you'll have to either use firefox or build your own.

if you're lucky, you may be able to replace seamonkey libraries with equivalent firefox libraries (basically copy over *.exe *.dll from firefox and then do some evil hacking to the xpt files).

I don't understand why it would take longer to start seamonkey with the server *unless* it's downloading dll's, which is the point.

please use:
!sym noisy

for your next log.

And you can include both firefox and seamonkey in your sympath. Note that the design should be such that it's only checking a handful of paths per dll per server path, so the general cost isn't much unless it finds a pdb, in which case you're downloading perhaps 100-200mb of pdb files (which is obviously time depending on the link bandwidth).

Comment 22

[Phoenix]

>sorry, if you can't get seamonkey to work, then you'll have to either use
firefox or build your own.
You mean to use firefox as symbol path, or as application? If first, than logs are already there. If second, than it doesn't help, I can't reproduce problem on installed on same machine firefox.
Make an own build is also not a way, I don't have either tool, nor qualification to do so.
But searching through mozilla sites, trying to find seamonkey symbols, I found some "tinderbox" builds, which seems to contain debug symbols for all files, but I'm not sure, which build to take.
Here some big table with automated test results - http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
And here is builds - http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/comm-central-trunk-win32-debug/
Is they are solution?

>please use:
>!sym noisy
>for your next log.
I'll put part of log with !sym noisy as next attachment

Comment 23

[Phoenix]

Attachment: Seamonkey !sym noisy results

Comment 24

[Phoenix]

Attachment: Yet another debug log

One of my friends created for me full debug build, source - http://hg.mozilla.org/comm-central/archive/bb7b2e55f9c2.tar.gz, here is debug log from it
If some other additional info needed, ask

Comment 25

[Phoenix]

Any news?

Comment 26

[Philip Chee]

I've pinged timeless. But with Gallifreyan Timelords who knows when he'll drop by.

Comment 27

[Phoenix]

:(

Comment 28

[timeless]

so, the last log has an assertion,

https://developer.mozilla.org/en/Automatically_Handle_Failed_Asserts_in_Debug_Builds has instructions which can let you automatically skip an assertion. You may also need to set some variable to force the code to use windbgdlg while you're already in a debugger. ask someone on irc if you hit that.

Comment 29

[Phoenix]

Attachment: First trace with disabled asserts

Okay, I've managed to disable assertions with XPCOM_DEBUG_BREAK=warn, and here is first log. Freeze occurs when I'm opening new window with middle click on hyperlink, ctrl+break pressed just after freeze

Comment 30

[Phoenix]

Attachment: Second trace with disabled asserts

And here is second trace, same conditions, but ctrl+break pressed 3 or 4 seconds after SeaMonkey freezed and still was irresponsible

Comment 31

[timeless]

the second stack trace is GC()

the first stack trace would be more interesting.

.call xul!DumpJSStack(); g

Comment 32

[Phoenix]

Attachment: First xul!DumpJSStack() trace

As I understand, this command must be used after break? If so, here first trace in same conditions

Comment 33

[Phoenix]

Attachment: Second xul!DumpJSStack() trace

And second, just to be sure that nothing missed

Comment 34

[timeless]

oh, you probably need to do one of:

firefox -console
firefox |more
firefox >logfile.txt

to use DumpJSStack(), we don't know to write to windbg's display field.... (there is a way...)

Comment 35

[Phoenix]

Attachment: First xul!DumpJSStack() trace with console dump

Ah, I understand, that console starts automatically with debug build, but I don't pay attention to it.
Here first trace, windbg log

Comment 36

[Phoenix]

Attachment: First xul!DumpJSStack() console dump

And here is console content for first trace, xul!DumpJSStack() results starts from line 773

Comment 37

[Phoenix]

Attachment: Second xul!DumpJSStack() trace with console dump

Second trace in same conditions

Comment 38

[Phoenix]

Attachment: Second xul!DumpJSStack() console dump

And its console dump

Comment 39

[Phoenix]

Forgot to write - in second console dump xul!DumpJSStack() results starts from line 766

Comment 40

[timeless]

i don't think i can hold your hand past this, hopefully someone else can...

Comment 41

[Phoenix]

Okay, thank you for your support, I'll wait for further instructions...

Comment 42

[Phoenix]

Sorry to bump, but any news?

Comment 43

[Phoenix]

Attachment: Memory usage report with 2.4.1

I'm updating this bug to reflect current situation with it.
Despite couple of releases come after report time, none of them improve situation for me, after day or two running, Seamonkey starts to freeze, after three or for days it became unusable, even with only two or three pages open. On other hang, added memory usage measurements and reading/searching through other bugs seems at last help me find the main source of the problem, it's in long cycle collections.
This data collected on regular 2.4.1 build, I moved to 2.7a1 nightlies, but gathering data with them take a day or two. So, CC+GC times with javascript.options.mem.log set to true:
CC timestamp: 1320052537368000, collected: 6 (6 waiting for GC), suspected: 309, duration: 3188 ms.
GC mode: full, timestamp: 1320052529180000, duration: 390 ms.
CC timestamp: 1320052524790000, collected: 332 (332 waiting for GC), suspected: 842, duration: 3157 ms.
GC mode: full, timestamp: 1320052516633000, duration: 390 ms.
CC timestamp: 1320052500180000, collected: 0 (6 waiting for GC), suspected: 3700, duration: 3203 ms.
CC timestamp: 1320052470821000, collected: 6 (6 waiting for GC), suspected: 3639, duration: 3281 ms.
GC mode: full, timestamp: 1320052466868000, duration: 375 ms.
CC timestamp: 1320052462493000, collected: 329 (329 waiting for GC), suspected: 3897, duration: 3234 ms.
GC mode: full, timestamp: 1320052456524000, duration: 359 ms.
CC timestamp: 1320052438087000, collected: 6 (6 waiting for GC), suspected: 125, duration: 3156 ms.
Memory usage report in time, when this cc+cg goes, attached as file.
In time, when CC goes, browser hangs and doesn't respond on any user actions (which helps me to reproduce bug 628780, but it's not a thing I'm happy about). Reading through other reports, I saw that they mostly concentrated on long GC times, not CC (at least those, where debugging clearly reveals source of problem), so this bug is not duplicate for them and need to be checked separately. Now, when I see that problem is in CC, what is next step for debugging?

---------------------------------------------------------------
Also, I'm posting the list of possibly related bugs and bugs, which "hides" the real source of problem
----
Bug 490122 – Firefox periodically becomes unresponsive/freezes: video jerks/pauses/halts; links, tabs, menus stop responding
Bug 495516 – cycle collector causing pauses every few seconds
Bug 579653 – extreme performance degradation (lack of responsiveness, temp-freezes) of firefox with long app uptime usage; time spent in cycle collector
Bug 614687 – High memory use (along with CPU spikes/hangs) after browsing YouTube for a while
Bug 646941 – Cycle and garbage collectors can sometimes become very slow
----
Bug 595671 - Animated images (GIFs) cause severe performance issues
Bug 666446 - lots of animated gifs swamp us with paint events
Bug 669034 – Periodic freezing with larger profiles (architectural issue with saving sessionstore.js)
----
And meta bug for CC problems
Bug 377787 – Cycle collector performance tracking

Comment 44

[Phoenix]

(In reply to ben turner [:bent] from comment #106 from bug 565217)
> (In reply to Phoenix from comment #103)
> > Examples of pauses due to CC
> 
> To clarify, we're interested in the time that the event loop is idle (while
> the app, or at least the main thread, has nothing to do).
When browser is completely idle, no CC or GC occures, but when I open new window, follow link or even just refresh current page, long CC event fires and browser freezes.

Comment 45

[Phoenix]

Attachment: Cycle collection times with nightly build

Posting CC+GC times taken with nightly build
Build identifier: Mozilla/5.0 (Windows NT 5.1; rv:10.0a1) Gecko/20111101 Firefox/10.0a1 SeaMonkey/2.7a1
GC mode: full, timestamp: 1320399985212000, duration: 296 ms.
CC timestamp: 1320399989041000, collected: 9525 (9525 waiting for GC), suspected: 10126, duration: 2891 ms.
GC mode: full, timestamp: 1320399993306000, duration: 265 ms.
CC timestamp: 1320399997728000, collected: 127 (127 waiting for GC), suspected: 6974, duration: 2859 ms.
CC timestamp: 1320400005697000, collected: 0 (127 waiting for GC), suspected: 6775, duration: 2922 ms.
CC timestamp: 1320400016540000, collected: 0 (127 waiting for GC), suspected: 6756, duration: 2968 ms.
CC timestamp: 1320400025900000, collected: 0 (127 waiting for GC), suspected: 6723, duration: 3016 ms.
GC mode: full, timestamp: 1320400056431000, duration: 266 ms.
CC timestamp: 1320400064368000, collected: 604 (604 waiting for GC), suspected: 488, duration: 2937 ms.
GC mode: full, timestamp: 1320400068634000, duration: 266 ms.
CC timestamp: 1320400076556000, collected: 422 (422 waiting for GC), suspected: 201, duration: 2922 ms.
GC mode: full, timestamp: 1320400080868000, duration: 297 ms.
CC timestamp: 1320400088774000, collected: 70 (70 waiting for GC), suspected: 162, duration: 2906 ms.
That is current state, full progress in attached file

Comment 46

[Phoenix]

Attachment: Memory usage report with nightly build

That is memory usage at moment, when last CC+GC times taken. Some comments: at that moment, there only four Seamonkey windows were open (plus Error console):
http://dynamo.kiev.ua/
http://www.cs.iptcom.net
http://cs.iptcom.net/ban_requests/bans1104.txt (was empty page, file was not exists at that moment)
about:memory?verbose
All other sites compartment were leaked, i suppose, most interested among them are www.ixbt.com and nag.ru, because I didn't open those links from yesterday. Supposing, that may be related to bug 672111.

Comment 47

[Phoenix]

And last: this is cycle collector heap dump taken when those four windows were open
http://www.cs.iptcom.net/debug/cc-edges-1.2520.7z (12 MB)

Comment 48

[Andrew McCreight [:mccr8]]

Your heap unclassified is fairly high.  Between that and the zombie compartments, I'd guess you are experiencing a memory leak that is showing up as long CC pauses.
Do you have any addons installed?  Those are the most common source of zombie compartments.

Comment 49

[Phoenix]

Current addon list:
Adblock Plus 1.3.10
ChatZilla 0.9.87
DOM Inspector 2.0.11
Element Hiding Helper for Adblock Plus 1.1.2
Firesizer 1.7
FxIF 0.4.4
JavaScript Debugger 0.9.88.2
NoScript 2.1.8
ReloadEvery 6.0.0
Russian spellchecking dictionary 0.4.4
Stylish 1.2.3
Ukrainian dictionary 1.6.5

Comment 50

[Phoenix]

Attachment: about:memory stat on leak catch

Catched first leak
./leak-gauge.pl nspr.log
Leaked docshell at address 13a40c00.
 ... which loaded URI "about:blank".
 ... which loaded URI "file:///M:/".
 ... which loaded URI "http://www.hirsch.sth.ac.at/~robert/thebot-logs/%23seamonkey-20111110-120004.xml".
 ... which loaded URI "http://www.hirsch.sth.ac.at/~robert/thebot-logs/seamonkey-index.xml".
 ... which loaded URI "http://www.hirsch.sth.ac.at/~robert/thebot-logs/".
 ... which loaded URI "file:///M:/%23seamonkey-20111110-120004.xml".
Summary:
Leaked 0 out of 0 DOM Windows
Leaked 0 out of 4343 documents
Leaked 1 out of 2194 docshells
Leaked content nodes within 0 out of 0 documents
about:memory in attached file, on that moment only three windows were open, one with non-existent page http://cs.iptcom.net/ban_requests/bans1110.txt, second was chatzilla window and third is about:memory.
cc heap dump: http://www.cs.iptcom.net/debug/cc-edges-1.5040.7z
cc+gc times:
GC mode: full, timestamp: 1320930121150000, duration: 110 ms.
CC timestamp: 1320930126996000, collected: 102 (102 waiting for GC), suspected: 166, duration: 846 ms.
CC timestamp: 1320930145629000, collected: 0 (102 waiting for GC), suspected: 4523, duration: 871 ms.
GC mode: full, timestamp: 1320930164056000, duration: 82 ms.
CC timestamp: 1320930165517000, collected: 162 (162 waiting for GC), suspected: 4657, duration: 873 ms.

Comment 51

[Andrew McCreight [:mccr8]]

Try starting the browser in safe mode and see if the problem reoccurs.  If it does not, then enable a couple of addons at a time until the problem shows up, to try to narrow down which addon it is.

Comment 52

[(dormant account)]

Snappy is firefox-specific.

Comment 53

[Phoenix]

(In reply to Andrew McCreight [:mccr8] from comment #51)
> Try starting the browser in safe mode and see if the problem reoccurs.  If
> it does not, then enable a couple of addons at a time until the problem
> shows up, to try to narrow down which addon it is.
Started safe-mode test, it takes a couple of days to complete

(In reply to Taras Glek (:taras) from comment #52)
> Snappy is firefox-specific.
So, you talking that it is not Core JS issue about high cc times, but seamonkey-specific and not related to firefox?

Comment 54

[(dormant account)]

I was referring to [Snappy] being inappropriate for non-firefox.

Comment 55

[Wayne Mery (:wsmwk)]

(In reply to Phoenix from comment #53)
> (In reply to Andrew McCreight [:mccr8] from comment #51)
> > Try starting the browser in safe mode and see if the problem reoccurs.  If
> > it does not, then enable a couple of addons at a time until the problem
> > shows up, to try to narrow down which addon it is.
> Started safe-mode test, it takes a couple of days to complete

results?

why are this and bug 710170 not one issue?

Comment 56

[Phoenix]

(In reply to Wayne Mery (:wsmwk) from comment #55)
> (In reply to Phoenix from comment #53)
> > Started safe-mode test, it takes a couple of days to complete
> 
> results?
Not reproducible in safe mode, two add-ons, causing problem, filled as separate blocking bugs

> why are this and bug 710170 not one issue?
Because Bug 713216 lead to same behavior (there may be others, not discovered yet), and I'm not sure, is this problem in add-ons implementing something wrong, or something in Core behaving wrong on correct add-ons requests

Comment 57

[MikeMac]

I'm having the same problem as Phoenix, but without watching videos.

Comment 58

[Wayne Mery (:wsmwk)]

still seeing this?

Comment 59

[Phoenix]

Actually, freeze part of the issue went some time ago, iirc when GC/CC moved to separate thread or something like this. Now only memory leak left, causing x32 builds to crash because of OOM after some time of using browser. But I prefer to leave this open until blocking bugs are resolved

Comment 60

[MikeMac]

I get the same result as Phoenix...

"Steps to Reproduce:
1. Start Seamonkey
2. Watch several YouTube videos
3. Don't unload Seamonkey for day or two
Actual Results:  
On next day (most time) Seamonkey starts to freeze on regular pages, even with simple text only. Most suffers wheel scroll feature, I can scroll the page with mouse wheel in several seconds after animation on pages (gif or flash) starts to work again."

Except I don't need to watch utube videos, just leaving SM on over a night or two triggers it.
When SM becomes unresponsive I close it with the instruction "save and close" and sometimes it save my tabs but often it does not.  SM is the only browser I use regularly.

Comment 61

[Wayne Mery (:wsmwk)]

(In reply to Phoenix from comment #56)
> ...
> > why are this and bug 710170 not one issue?
> Because Bug 713216 lead to same behavior (there may be others, not
> discovered yet), and I'm not sure, is this problem in add-ons implementing
> something wrong, or something in Core behaving wrong on correct add-ons
> requests

Phoenix, 
Where another bug is the suspected cause, I tend to handle such issues by closing one of the bugs - rather than keep both bugs open make bug B (this bug) dependent on bug A (710170), and then dup bug B to bug A.  Because you get a notification from bug B when bug A has been closed, you can then decide whether to keep bug B closed, or reopen it.
What do you think?

Comment 62

[Phoenix]

Hi Wayne, I think there is no value in keeping this bug open, Firefox devs don't care about amount of bugs they have, nor fixes of old issues. I'll duplicate this one to Stylish bug, as it is more easily reproducible.

(In reply to MikeMac from comment #60)
> I get the same result as Phoenix...
> 
> "Steps to Reproduce:
> 1. Start Seamonkey
> 2. Watch several YouTube videos
> 3. Don't unload Seamonkey for day or two

Hi Mike, this is too general description of the issue, first of all you need to check if this is reproducible in Safe Mode (Help - Restart with Add-ons Disabled), and on clean profile.