105.38 KB, image/png
42.19 KB, image/png
42.07 KB, image/png
12.09 KB, image/png
12.03 KB, image/png
Created attachment 518898 [details] SeaMonkey 2.0 crasher at 10 min mark. By the time of the shot, memory usage had already dropped.
Did you allow the crash reporter to send the crash reports to mozilla? Perhaps they are still stuck on your PC?
All crash reports were sent, though the majority were worthless; "... stackwalk.sh returned no header lines for reportid: 252333870; No thread was identified as the cause of the crash; No signature could be created ...". The few that actually returned some data: https://crash-stats.mozilla.com/report/index/bp-1c5d396f-a948-461e-af80-de2ac2110407 https://crash-stats.mozilla.com/report/index/bp-f513cbac-d123-46f6-8013-f0b862110429 https://crash-stats.mozilla.com/report/index/bp-6765b593-eaa7-4928-bbb7-9ad7d2110501
I took my existing sessionstore.json & copied it over into a FF4 profile (as sessionstore.js), & FF would then crash on startup just as SeaMonkey does. (The FF crash reports are all worthless too.) (Now working in FF4 ...) I manually opened about:sessionrestore, then opened all 483 (or so) links in the same window (center clicking the links). (I would open a handful at a time, wait a few seconds, then grab another handful...) That completed successfully, no crash. (Ratty) pointed me to /browser.sessionstore.max_concurrent_tabs/. I tried loading with settings of -1, 1, & finally 0. (Already knew that the default of 3 crashed.) -1, crashed. 1, crashed. With 0, I was able to successfully load (from sessionstore.js, 483 tabs in a single window). Then I copied my SeaMonkey sessionstore.json over again (into FF4) & then (still with a setting of 0) was able to successfully open 483 tabs spread over 43 windows. (Back to SeaMonkey ...) Setting /browser.sessionstore.max_concurrent_tabs;0/, I am now able to successfully load from my sessionstore.json.
Now, I'll just note that what you get with /browser.sessionstore.max_concurrent_tabs;0/ is not as feature laden as what BarTab would do (does in earlier builds, where it still worked). Comments starting about here https://bugzilla.mozilla.org/show_bug.cgi?id=561149#c2 & #c9 spell out the differences well.
Now an interesting comment which I hadn't considered, https://bugzilla.mozilla.org/show_bug.cgi?id=556826#c20 . > Seems like these crashes are due to out of memory. If the people who are seeing > this are running the standard 32-bit versions of Firefox then even if you have > 6 gigs of ram (or more) windows still limits the address space of the 32-bit firefox > process to 2 gigs (same goes for any 32-bit app, it's a windows limitation), so if > you're running at 1.5 gigs+ of memory usage we may very well run into allocation > failures which can lead to a crash My OS's are x86's & all of my crashes, be it Bug 657115 - Extensive memory usage during ROME demo, or this bug, have all been right around the 1.6 GB mark of Mem Usage. (1.6 GB applicable to the browser itself - alone. I have 4 GB physical memory, & even of that Windows limits its usage to a bit over 3 GB anyhow.)
Another interesting tidbit from that thread, https://bugzilla.mozilla.org/show_bug.cgi?id=556826#c23 . > windows users might have a look at windows' taskmgr GDI count for firefox.exe > next time you have this many tabs open. There is a per-task limit if 10k for > GDI objects, and my experience is FF typically starts becoming unstable in the > 5-7k range, even though FF isn't using anywhere close to the 2GB 32bit process > limit. I'll have to take a look at that.
Created attachment 537742 [details] Screenshot. GDI Handles 7389. Mem Usage 1.6 GB. "1.6" was always a magic number for me. I knew when I got right around that point, I would crash. So maybe it wasn't a memory issue I (may have been) running into, but a GDI Handles issue. As per above, it is right in the range where I /should/ crash. :frown:
Suppose I could change the number of GDI Objects setting & see if that makes any difference. "GDI Objects" http://msdn.microsoft.com/en-us/library/ms724291(v=vs.85).aspx This is on Window 7, x86, 4GB RAM, btw.
I should note, that I use only the browser portion of SeaMonkey. In the past I've used Chat, cZ, but more recently I've exclusively been using ChatZilla on XULRunner (with FF30 as its base). http://chatzilla.rdmsoft.com/xulrunner/ I do not use Mail or News. Composer, rarely.
No changes, still crashes. Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20100101 Firefox/5.0 (Now what does that tell you!) http://hg.mozilla.org/releases/mozilla-release/rev/7b56ff900c2a
This is basically an out-of-memory crash on a large number of tabs. In FF4 BarTab doesn't work (unless you use a beta); FF4 uses more memory in some cases and so a profile that worked on FF 3.x can fail on FF4.x. It would be worth trying with FF7 or FF8 (as of tomorrow or so FF8 is Aurora, FF7 is Beta). And do use max-concurrent-tabs of 0 (negative isn't valid, any positive number will eventually try to load all ~500 tabs) and you should be ok. This isn't a memshrink bug; it is a OOM crash that might be fixed by the memshrink project. 500 tabs in a 32-bit process is a LOT if they're all loaded.
Yes I've already tried (perhaps in a less then scientific manner) SeaMonkey 2.5a2 (akin to FF 8) 20110817 yesterday (or two days ago now as it appears to be). > & all that to find out that it /appears/ that memshrink is actually showing > some results. hallelujah 690 MB vs 890 MB, that's a decent drop. This was on an initial load from Session Restore, comparing on a normal Profile (so with extensions & whatnot enabled) in SeaMonkey 2.5a2 vs. 2.3 (akin to FF 6). Now that said, after being open a day or so, I'm now up to ~1 GB of Mem usage, & while "feel" may be a bit better then what I have been seeing, it is still FAR from crisp. (Running with browser.sessionstore.max_concurrent_tabs;0) I'll try browser.sessionstore.max_concurrent_tabs;1, but I've got to think my UX [User eXperience, found about that today is some, oh, "controversial" bug ;-)] will be far worse (given that it will take about forever to finally finish loading). Oh, well ... Mozilla/5.0 (Windows NT 6.1; rv:8.0a2) Gecko/20110817 Firefox/8.0a2 SeaMonkey/2.5a2
browser.sessionstore.max_concurrent_tabs;1 seemed to work the same as ;0 ? so I set it to default (3) (& yes it was pointed out to me that browser.sessionstore.max_concurrent_tabs is being replaced by <the seemingly less useful & forward thinking> browser.sessionstore.restore_on_demand) browser.sessionstore.max_concurrent_tabs;3 And the ensuing crash (though worthless): https://crash-stats.mozilla.com/report/index/bp-4c416f74-6829-4548-9ed0-cbf2a2110819 (Though I do have a nice screenshot, see below.) Mozilla/5.0 (Windows NT 6.1; rv:8.0a2) Gecko/20110818 Firefox/8.0a2 SeaMonkey/2.5a2
you might try a 64bit build of SM. I can run more tabs on win7 with 64bit firefox than 32bit
Summary: sessionrestore crash on startup → sessionrestore OOM crash on startup when hundreds of tabs and large sessionstore.js
Bug is still valid. Now running Win7 x64 & I'm crashing when I reach right around the 3 GB memory mark. SeaMonkey 2.13a, 32-bit. (32-bit app will max out around 3 GB even on a 64-bit OS.) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20120826 Firefox/16.0 SeaMonkey/2.13a2 Worthless: https://crash-stats.mozilla.com/report/index/bp-3c273ce1-d144-4e7d-9d8d-cf4b02120826 https://crash-stats.mozilla.com/report/index/bp-4373e5a8-3993-4f18-b479-276fc2120826 Towards the end: handles 7280, peak handles 13535, gid handles 660, user handles 426 This was with a new Profile. Only addition was to copy in my existing sessionstore.json file, 3,130,773 bytes, 725 tabs, 62 windows. (Now I run that sessionstore.json file all the time, without problems, though I do have browser.sessionstore.max_concurrent_tabs;0 & I also run NoScript which will block a lot of content too.)
64-bit SeaMonkey 2.11 from here: http://code.google.com/p/htguardmozilla/downloads/detail?name=seamonkey-2.11.en-US.win64-x86_64.installer.exe&can=2&q= Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:14.0) Gecko/20120716 Firefox/14.0.1 SeaMonkey/2.11 I have loaded (am loading) far more then with 32-bit & have not crashed (yet?). But it is not fun. Have been loading for a LONG time. Not sure if it will ever finish? Can be hard to determine? CPU has been at 25% (100% of 1 of 4 cores) for a LONG time now. I/O is still going on. Mem usage seems to have stabilized just below the 8.7 GB mark. I have 12 GB total. HUGE difference in Handles, for whatever that may mean: > handles 7280, peak handles 13535, gid handles 660, user handles 426 (32-bit) (towards the end, before crash) > handles 612, peak handles 898, gid handles 693, user handles 423 (64-bit) (ATM) It is not fun.
Screenshots. It's difficult to do anything. These shots are from the 26th, at which time I put the computer to sleep. Awakened just now, with no change, not like I expected any. Mem bumped itself up to 9111 MB. (I see it is now up to 9554 MB. I've only open a few sites, mainly to upload the pics.) CPU & I/O are basically the same. Mem, CPU, I/O http://i48.tinypic.com/2ykax34.jpg Handles http://i49.tinypic.com/awz49g.jpg SeaMonkey 64 http://i49.tinypic.com/6fy44j.jpg about.memory http://i50.tinypic.com/i56j35.jpg about.support http://i45.tinypic.com/2iky0ew.jpg
Oh, & while I have not crashed, OUCH (it's painful to use). Win7 x64, i5 750, 12 GB RAM
"725 tabs, 62 windows" sorry, but that's just absurd. What happened to your testcase of 500 tabs - that wasn't enough?? Of course it is going to use tons of memory. And be slow. And painful. I dare say you are beyond reasonable usage. Firstly, your 3MB sessionstore gets written to disk every 15 seconds or something when there are changes to be noted. That alone is going to affect UI responsiveness. Secondly, garbage collection time is no doubt in the toilet. Install the memchaser addon and you will see high igc, gc and cc times. If you are seeing figures higher than 200-300ms then your UI performance is affected. My bet is your figures are higher than 1sec. Cut the number of active tabs by half or more and you will see improvement. There are addons that will help you get there.
You need to log in before you can comment on or make changes to this bug.