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...
Is anybody alive here?
Version: unspecified → SeaMonkey 2.0 Branch
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.
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 on attachment 510274 [details] useless Please follow the instructions in: https://developer.mozilla.org/en/how_to_get_a_stacktrace_with_windbg
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
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
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
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
Attachment #511001 - Attachment mime type: application/octet-stream → text/plain
Attachment #510973 - Attachment mime type: application/octet-stream → text/plain
Attachment #510974 - Attachment mime type: application/octet-stream → text/plain
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.
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.
(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
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
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
Attachment #513106 - Attachment mime type: application/octet-stream → text/plain
Hi! Can you use the following path for the symbol server? thanks. http://symbols.mozilla.org/seamonkey (instead of firefox).
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...
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
>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
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
I've pinged timeless. But with Gallifreyan Timelords who knows when he'll drop by.
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.
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
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
the second stack trace is GC() the first stack trace would be more interesting. .call xul!DumpJSStack(); g
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
Created attachment 518674 [details] Second xul!DumpJSStack() trace And second, just to be sure that nothing missed
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...)
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
Created attachment 519111 [details] First xul!DumpJSStack() console dump And here is console content for first trace, xul!DumpJSStack() results starts from line 773
Created attachment 519112 [details] Second xul!DumpJSStack() trace with console dump Second trace in same conditions
Forgot to write - in second console dump xul!DumpJSStack() results starts from line 766
i don't think i can hold your hand past this, hopefully someone else can...
Assignee: nobody → general
Product: SeaMonkey → Core
QA Contact: general → general
Version: SeaMonkey 2.0 Branch → 1.9.2 Branch
Okay, thank you for your support, I'll wait for further instructions...
Sorry to bump, but any news?
(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.
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
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.
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.
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.
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
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.
Snappy is firefox-specific.
(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?
I was referring to [Snappy] being inappropriate for non-firefox.
Whiteboard: [closeme 2012-04-15][safe mode results?]
(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?
(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
I'm having the same problem as Phoenix, but without watching videos.
still seeing this?
Severity: normal → major
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
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
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.
(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?
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
Resolution: --- → DUPLICATE
Duplicate of bug: 713216
You need to log in before you can comment on or make changes to this bug.