Status

()

RESOLVED DUPLICATE of bug 713216
8 years ago
2 years ago

People

(Reporter: pppx, Unassigned)

Tracking

({memory-leak})

Trunk
x86
All
memory-leak
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 20 obsolete attachments)

3.31 KB, text/plain
Details
37.66 KB, text/plain
Details
24.05 KB, text/plain
Details
(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
Created attachment 487561 [details]
Process Explorer freezed thread infos
(Reporter)

Comment 2

8 years ago
Created attachment 489461 [details]
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...
(Reporter)

Comment 3

8 years ago
Is anybody alive here?
Version: unspecified → SeaMonkey 2.0 Branch

Comment 4

8 years ago
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.
(Reporter)

Comment 5

8 years ago
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
(Reporter)

Comment 6

8 years ago
Created attachment 510274 [details]
useless

Comment 7

8 years ago
Comment on attachment 510274 [details]
useless

Please follow the instructions in: https://developer.mozilla.org/en/how_to_get_a_stacktrace_with_windbg
Attachment #510274 - Attachment description: Stack info from windbg → useless
Attachment #510274 - Attachment is obsolete: true
(Reporter)

Comment 8

8 years ago
Created attachment 510973 [details]
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
(Reporter)

Comment 9

8 years ago
Created attachment 510974 [details]
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
(Reporter)

Comment 10

8 years ago
Created attachment 510999 [details]
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
(Reporter)

Comment 11

8 years ago
Created attachment 511001 [details]
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
(Reporter)

Updated

8 years ago
Attachment #511001 - Attachment mime type: application/octet-stream → text/plain
(Reporter)

Updated

8 years ago
Attachment #510973 - Attachment mime type: application/octet-stream → text/plain
(Reporter)

Updated

8 years ago
Attachment #510974 - Attachment mime type: application/octet-stream → text/plain
(Reporter)

Comment 12

8 years ago
Any news?

Comment 13

8 years ago
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

8 years ago
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.
Keywords: stackwanted
(Reporter)

Updated

8 years ago
Attachment #487561 - Attachment is obsolete: true
(Reporter)

Updated

8 years ago
Attachment #489461 - Attachment is obsolete: true
(Reporter)

Updated

8 years ago
Attachment #510973 - Attachment is obsolete: true
(Reporter)

Updated

8 years ago
Attachment #511001 - Attachment is obsolete: true
(Reporter)

Updated

8 years ago
Attachment #510999 - Attachment is obsolete: true
(Reporter)

Updated

8 years ago
Attachment #510974 - Attachment is obsolete: true
(Reporter)

Comment 15

8 years ago
(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
(Reporter)

Comment 16

8 years ago
Created attachment 513104 [details]
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
(Reporter)

Comment 17

8 years ago
Created attachment 513106 [details]
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

Updated

8 years ago
Attachment #513106 - Attachment mime type: application/octet-stream → text/plain

Comment 18

8 years ago
Hi!

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

Comment 19

8 years ago
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

8 years ago
Oh sorry.

Comment 21

8 years ago
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).
OS: Windows XP → All
(Reporter)

Comment 22

8 years ago
>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
(Reporter)

Comment 23

8 years ago
Created attachment 513964 [details]
Seamonkey !sym noisy results
(Reporter)

Comment 24

8 years ago
Created attachment 515594 [details]
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
(Reporter)

Comment 25

8 years ago
Any news?

Comment 26

8 years ago
I've pinged timeless. But with Gallifreyan Timelords who knows when he'll drop by.
(Reporter)

Comment 27

8 years ago
:(

Comment 28

8 years ago
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.
(Reporter)

Comment 29

8 years ago
Created attachment 518035 [details]
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
Attachment #513104 - Attachment is obsolete: true
Attachment #513106 - Attachment is obsolete: true
Attachment #513964 - Attachment is obsolete: true
Attachment #515594 - Attachment is obsolete: true
(Reporter)

Comment 30

8 years ago
Created attachment 518036 [details]
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

8 years ago
the second stack trace is GC()

the first stack trace would be more interesting.

.call xul!DumpJSStack(); g
(Reporter)

Comment 32

8 years ago
Created attachment 518673 [details]
First xul!DumpJSStack() trace

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

Comment 33

8 years ago
Created attachment 518674 [details]
Second xul!DumpJSStack() trace

And second, just to be sure that nothing missed

Comment 34

8 years ago
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...)
(Reporter)

Comment 35

8 years ago
Created attachment 519110 [details]
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
(Reporter)

Comment 36

8 years ago
Created attachment 519111 [details]
First xul!DumpJSStack() console dump

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

Comment 37

8 years ago
Created attachment 519112 [details]
Second xul!DumpJSStack() trace with console dump

Second trace in same conditions
(Reporter)

Comment 38

8 years ago
Created attachment 519113 [details]
Second xul!DumpJSStack() console dump

And its console dump
(Reporter)

Comment 39

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

Comment 40

8 years ago
i don't think i can hold your hand past this, hopefully someone else can...
Assignee: nobody → general
Component: General → JavaScript Engine
Keywords: stackwanted
Product: SeaMonkey → Core
QA Contact: general → general
Version: SeaMonkey 2.0 Branch → 1.9.2 Branch
(Reporter)

Comment 41

8 years ago
Okay, thank you for your support, I'll wait for further instructions...
(Reporter)

Comment 42

8 years ago
Sorry to bump, but any news?
(Reporter)

Comment 43

7 years ago
Created attachment 571331 [details]
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
(Reporter)

Comment 44

7 years ago
(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.
(Reporter)

Comment 45

7 years ago
Created attachment 571917 [details]
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
(Reporter)

Comment 46

7 years ago
Created attachment 571919 [details]
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.
(Reporter)

Comment 47

7 years ago
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)
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.
(Reporter)

Comment 49

7 years ago
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
(Reporter)

Comment 50

7 years ago
Created attachment 573490 [details]
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.
(Reporter)

Updated

7 years ago
Summary: Seamonkey performance degradation over time, resulting in hangs/freezes → Seamonkey performance degradation over time because of long cycle collection time, resulting in hangs/freezes
Whiteboard: [Snappy]
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

7 years ago
Snappy is firefox-specific.
Whiteboard: [Snappy]
(Reporter)

Comment 53

7 years ago
(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

7 years ago
I was referring to [Snappy] being inappropriate for non-firefox.
(Reporter)

Updated

7 years ago
Depends on: 710170
(Reporter)

Updated

7 years ago
Depends on: 713216
Depends on: 696761

Updated

7 years ago
Keywords: perf
Whiteboard: [closeme 2012-04-15][safe mode results?]
(Reporter)

Updated

7 years ago
Whiteboard: [closeme 2012-04-15][safe mode results?]

Comment 55

7 years ago
(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?
(Reporter)

Comment 56

7 years ago
(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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: 1.9.2 Branch → Trunk
(Reporter)

Updated

7 years ago
Attachment #518035 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #518036 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #518673 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #519111 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #518674 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #519110 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #519112 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #519113 - Attachment is obsolete: true
(Reporter)

Updated

7 years ago
Attachment #571331 - Attachment is obsolete: true
(Assignee)

Updated

4 years ago
Assignee: general → nobody

Comment 57

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

Comment 58

3 years ago
still seeing this?
Severity: normal → major
Component: JavaScript Engine → JavaScript: GC
Flags: needinfo?(pppx)
(Reporter)

Comment 59

3 years ago
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
(Reporter)

Updated

3 years ago
Flags: needinfo?(pppx)

Updated

2 years ago
Severity: major → normal
Keywords: perf → mlk
Summary: Seamonkey performance degradation over time because of long cycle collection time, resulting in hangs/freezes → Seamonkey memory leak

Comment 60

2 years ago
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

2 years ago
(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?
Flags: needinfo?(pppx)
(Reporter)

Comment 62

2 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(pppx)
Resolution: --- → DUPLICATE
Duplicate of bug: 713216
You need to log in before you can comment on or make changes to this bug.