Open
Bug 641164
Opened 13 years ago
Updated 5 years ago
sessionrestore OOM crash on startup when hundreds of tabs and large sessionstore.js
Categories
(SeaMonkey :: Session Restore, defect)
Tracking
(Not tracked)
UNCONFIRMED
People
(Reporter: therubex, Unassigned)
Details
Attachments
(5 files)
SeaMonkey 2.0 crasher at 10 min mark.
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110305 Firefox/4.0b13pre SeaMonkey/2.1b3pre Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b13pre) Gecko/20110305 Firefox/4.0b13pre SeaMonkey/2.1b3pre I am unable to successfully load SeaMonkey using an existing sessionrestore.json file in an otherwise new Profile. Reproducible: Always Steps to Reproduce: 1. create a new Profile 2. open Profile, open two tabs, save session, & quit 3. copy existing sessionrestore.json into Profile, & start SeaMonkey Actual Results: SeaMonkey crashes. Expected Results: SeaMonkey should not crash. I am starting with an existing sessionrestore.json file, originally from SeaMonkey 2.0, migrated (copied) to SeaMonkey 2.1, & now using same to test in a new clean Profile. Both working (non-test, regular use) Profiles, well, work. I crash in both SM20 & SM21, clean Profiles with this sessionrestore.json file. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.18pre) Gecko/20110309 SeaMonkey/2.0.13pre Mozilla/5.0 (Windows NT 6.1; rv:2.0b11) Gecko/20110209 Firefox/4.0b11 SeaMonkey/2.1b2 Two runs in SM20. #1, crash ~1:37. #2, crash ~10:26. Given a few more minutes, I actually thought #2 would have loaded. Three runs in SM21. All crash ~1:40. If I add NoScript extension (v2.0.9.9) with no other changes, both test Profiles will load (~2 minutes for SM20, ~5 minutes for SM21). (Just to add), if I add BarTab extension, in addition to NoScript, both test Profiles will load & MUCH quicker (<40 seconds). My sessionstore.json is 587 KB, so while "large", still far smaller then some others have reported. Crash reports (though I was not able to actually view them, getting the "Oh Noes!" instead): SM20 01:37 https://crash-stats.mozilla.com/report/pending/c438836f-fb0d-4660-be5a-2e6032110311 10:26 https://crash-stats.mozilla.com/report/pending/23db4a8c-785e-4b30-bbcf-20f5e2110311 SM21 #1 https://crash-stats.mozilla.com/report/pending/7f83b947-7969-448f-89cc-83d852110311 #2 https://crash-stats.mozilla.com/report/pending/8764fd59-2e84-4e6b-9c29-8c9ba2110311 #3 https://crash-stats.mozilla.com/report/pending/b3237fb0-5419-4569-9b03-b49d62110311 Memory usage, & this is overall system memory usage, not just of the seamonkey.exe (or seamonkey.exe & plugin-container.exe) processes, though nonetheless, it should be indicative of differences of memory usage between SM20 & SM21. SM20 2.14 GB ram at run #2, 10 minute mark. SM21 2.40 GB ram. SM20 & NoScript, successful load, 2 minutes, 1.80 GB ram. SM21 & NoScript, successful load, 5 minutes, 2.10 GB ram. SM20 & NoScript & BarTab, successful load < 40 seconds, 0.90 GB ram. SM21 & NoScript & BarTab, successful load < 40 seconds, 1.25 GB ram. Some time difference may be due to /cached/ data. Some due to content not loaded (JavaScript & plugins ... with NoScript, & whatever BarTab may block or delay on load). Possible DUP of Bug 511135 - crash during startup sesssionrestore [@ free | js3250.dll@0xb00ae] (or some of the other bugs mentioned in that report)?
By the time of the shot, memory usage had already dropped.
|
||
Comment 4•13 years ago
|
||
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.
|
Reporter | |
Comment 10•13 years ago
|
||
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:
|
|
Reporter | |
Comment 11•13 years ago
|
||
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.
|
|
Reporter | |
Comment 12•13 years ago
|
||
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.
|
|
Reporter | |
Comment 13•13 years ago
|
||
"Performance/MemShrink" https://wiki.mozilla.org/Performance/MemShrink
Whiteboard: MemShrink:P2
|
||
Updated•13 years ago
|
Whiteboard: MemShrink:P2 → [MemShrink:P2]
|
|
Reporter | |
Comment 14•13 years ago
|
||
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
|
|
||
Updated•13 years ago
|
Whiteboard: [MemShrink:P2] → [MemShrink]
|
|
||
Updated•13 years ago
|
Whiteboard: [MemShrink]
|
||
Comment 15•13 years ago
|
||
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.
|
|
Reporter | |
Comment 16•13 years ago
|
||
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|
|
Reporter | |
Comment 17•13 years ago
|
||
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
|
|
Reporter | |
Comment 18•13 years ago
|
||
Where things stood after my crash.
|
||
Comment 19•12 years ago
|
||
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
|
|
Reporter | |
Comment 20•12 years ago
|
||
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.)
|
|
Reporter | |
Comment 21•12 years ago
|
||
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.
|
|
Reporter | |
Comment 22•12 years ago
|
||
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
|
|
Reporter | |
Comment 23•12 years ago
|
||
Oh, & while I have not crashed, OUCH (it's painful to use). Win7 x64, i5 750, 12 GB RAM
|
|
||
Comment 24•12 years ago
|
||
"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.
Description
•