Closed
Bug 702012
Opened 13 years ago
Closed 13 years ago
Exit is slow. Firefox using lots of memory with very high tab count.
Categories
(Core :: General, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: rob1weld, Unassigned)
Details
(Keywords: perf, Whiteboard: [CLOSEME 2012-03-12])
Attachments
(6 files)
When I exited Nightly 11.0a1 it allowed saving the current Session to TM+ (thus it 'partially exited correctly') and the Window snapped shut but Window's Task Manager showed high Processor load and that a lot of memory was still in use (Nightly's cache of open Tabs was very slow to flush).
I attached WinDbg to the still open Process (a minute after the Window had closed) and I find code and memory corruption in the enclosed WinDbg Log File.
Example:
----- Line # 985: -----
.....
BUGCHECK_STR: APPLICATION_FAULT_STACKIMMUNE_MEMORY_CORRUPTION_LARGE
PRIMARY_PROBLEM_CLASS: STACKIMMUNE
DEFAULT_BUCKET_ID: STACKIMMUNE
STACK_TEXT:
00000000 00000000 firefox.exe+0x0
CODE_MISMATCH: 7c901200 40 bytes
.event_code
7c901200, 0x40 bytes valid.
7c901200 46 10 10 0f 84 ed ec 00-00 5e c9 c2 04 00 cc c3 F........^......
7c901210 8b ff cc c3 8b ff 8b 44-24 04 cc c2 04 00 64 a1 .......D$.....d.
7c901220 18 00 00 00 c3 57 8b 7c-24 0c 8b 54 24 08 c7 02 .....W.|$..T$...
7c901230 00 00 00 00 89 7a 04 0b-ff 74 1e 83 c9 ff 33 c0 .....z...t....3.
Mismatch at 7c90120f - c3 at event vs. e9 now
Mismatch at 7c901210 - 8b at event vs. 34 now
Mismatch at 7c901211 - ff at event vs. f3 now
Mismatch at 7c901212 - cc at event vs. 7d now
Mismatch at 7c901213 - c3 at event vs. 86 now
.....
Here is another example, with WinDbg attached to the Nightly Process, 10 minutes after closing the Browser. The total time to exit was over well 20 minutes.
Window's Task Manager screenshot of Nightly 11.0a1. Shows Processor pinned and slow cache flushing when exiting (annotated).
This issue has not occurred recently but does reoccur often enough to leave open for the time being.
If the 'pinning' and 'slow cache flushing upon exit' desist for three months I will close this.
Note: I am starting WinXP using the /3GB Switch (since reporting this) and that would allow more Memory and less use of the larger Cache (and thus hide this Bug (and many others) from me).
Updated•13 years ago
|
Whiteboard: [CLOSEME 2012-02-12]
@ Wayne Mery (:wsmwk)
1. I reported this against "Nightly" (or so Comment 0 says) but for some reason the "Version:" is set to "10 Branch" - I don't know why.
2. I note that this is "Whiteboard: [CLOSEME 2012-02-12]" and while that _might_ be OK we also have Bug 709873 (which SOUNDS LIKE (and looks like) the same problem; reported against Firefox "Release") it is for rasterimage.cpp whereas Comment 0 is for jemalloc.c .
There is a problem with allocation of Memory past the 4GB mark (on WinXP in 32 Bit mode) that is causing Memory corruption; this leads to a variety of hard to track Bugs and the various complains we get about slow shutdown (that seem to come and go).
It is probably the lower likelihood of people using that much Memory on WinXP combined with the random corruption caused by an errant Subroutine (somewhere) that makes this problem intermittent and hard to track (or reproduce). I hope the problem is found and resolved before the (suggested) closeme date.
Comment 5•13 years ago
|
||
(In reply to Rob from comment #4)
>
> There is a problem with allocation of Memory past the 4GB mark (on WinXP in
> 32 Bit mode) that is causing Memory corruption; this leads to a variety of
> hard to track Bugs and the various complains we get about slow shutdown
> (that seem to come and go).
>
> It is probably the lower likelihood of people using that much Memory on
> WinXP combined with the random corruption caused by an errant Subroutine
> (somewhere) that makes this problem intermittent and hard to track (or
> reproduce). I hope the problem is found and resolved before the (suggested)
> closeme date.
it would help immensely to provide details of the steps and URLs required to get into this problem state.
(In reply to Wayne Mery (:wsmwk) from comment #5)
> (In reply to Rob from comment #4)
> >
> > There is a problem with allocation of Memory past the 4GB mark (on WinXP in
> > 32 Bit mode) that is causing Memory corruption; this leads to ...
> it would help immensely to provide details of the steps and URLs required to
> get into this problem state.
It almost always occurs with many Tabs open (thus I am low on memory and the Browser needs to go from allocating "real" (physical) memory to cache (swap drive) memory) and WinXP Task Manager reports "Physical Memory (K)[C/R] Available" at less than about 320K (my "Commit Charge (K) [C/R] Limit" is 769K -- IE: I have 4GB or real memory and 4GB of Swap).
I usually have over 2-3 hundred Tabs open (to use that much memory) so providing a list of URLs is not practical. It is unfortunate that the two .LOGs and the .PNG were not helpful to show what to look for.
BTW: This has only happened once in the last month whereas before it happened once every couple days when reported - so it is nearly fixed (possibly via another BR).
Comment 7•13 years ago
|
||
(In reply to Rob from comment #6)
> (In reply to Wayne Mery (:wsmwk) from comment #5)
> > (In reply to Rob from comment #4)
> > >
> > > There is a problem with allocation of Memory past the 4GB mark (on WinXP in
> > > 32 Bit mode) that is causing Memory corruption; this leads to ...
Is this analysis an assumption on your part?
1. If my memory is accurate, processes on XP (i.e. thunderbird) can't exceed 2gb.
2. Furthermore, at 200-400 tabs you absolutely are in territory where you start hitting issues with GDI. The absolute ceiling is GDIProcessHandleQuota =10,000 default. However, FIrefox will start behaving poorly and even crash in the 6,000-8,000 range. This is all about windows, not firefox. I have significant first hand experience with this, having routinely run 100-300 tabs on XP for a long time. It wasn't pretty. see bug 551667 and bug 640162 comment 4
3. Even if you solved both of the above issues (which you can on win7 and 64bit firefox) with ~100+ tabs you hit yet a third issue, namely GC and CC performance that mozilla have been working on for the past year.
4. lastly you may find you have a humungous sessionstore.js file which is helping to kill your performance
In short your options are limited, and using current version of Firefox you aren't likely to ever be happy running 300-400 (and perhaps even 200) tabs on XP.
> > it would help immensely to provide details of the steps and URLs required to
> > get into this problem state.
>
> It almost always occurs with many Tabs open (thus I am low on memory and the
> Browser needs to go from allocating "real" (physical) memory to cache (swap
> drive) memory) and WinXP Task Manager reports "Physical Memory (K)[C/R]
> Available" at less than about 320K (my "Commit Charge (K) [C/R] Limit" is
> 769K -- IE: I have 4GB or real memory and 4GB of Swap).
>
> I usually have over 2-3 hundred Tabs open (to use that much memory) so
> providing a list of URLs is not practical. It is unfortunate that the two
> .LOGs and the .PNG were not helpful to show what to look for.
I could be wrong but I doubt this info is going to be useful. And even if it is, you have an edge case (300-400 tabs) that isn't a typical user and so isn't going to garner attention from developers.
That said, firefox performance has improved over the last few months and will get continue to get better. And it is great that you are running the development builds, and are trying to help. But your time is probably too important to be pursuing this type of testcase.
Here's what helped me the most:
- install flashblock addon
- severely minimize use of addons
- disable or lower fast back history (or whatever it is called) that keeps previous pages of a tab in memory - I think the default is 8. However, they might have removed the hidden preference - I no longer recall because I last looked at this a couple years ago
- reduce the number of tabs, especially ones in js-heavy and those with lots of images. game pages for example. you can also reduce the number of tabs by running more than one browser. google chrome works great here, to a point.
(In reply to Wayne Mery (:wsmwk) from comment #7)
> (In reply to Rob from comment #6)
> > (In reply to Wayne Mery (:wsmwk) from comment #5)
> > > (In reply to Rob from comment #4)
> > > >
> > > > There is a problem with allocation of Memory past the 4GB mark (on WinXP in
> > > > 32 Bit mode) that is causing Memory corruption; this leads to ...
>
> Is this analysis an assumption on your part?
I have a screenshot that demonstrates the problem. I keep getting the problem in the same area.
Kind of like driving down a dark road and hearing a big bang in the same spot each time. Looking at the dents in your Rim you can assume from your analysis that it is a pothole.
> 1. If my memory is accurate, processes on XP (i.e. thunderbird) can't exceed
> 2gb.
>
> 2. Furthermore, at 200-400 tabs you absolutely are in territory where you
> start hitting issues with GDI. The absolute ceiling is GDIProcessHandleQuota
> =10,000 default. However, FIrefox will start behaving poorly and even crash
> in the 6,000-8,000 range. This is all about windows, not firefox. I have
> significant first hand experience with this, having routinely run 100-300
> tabs on XP for a long time. It wasn't pretty. see bug 551667 and bug 640162
> comment 4
>
> 3. Even if you solved both of the above issues (which you can on win7 and
> 64bit firefox) with ~100+ tabs you hit yet a third issue, namely GC and CC
> performance that mozilla have been working on for the past year.
>
> 4. lastly you may find you have a humungous sessionstore.js file which is
> helping to kill your performance
>
> In short your options are limited, and using current version of Firefox you
> aren't likely to ever be happy running 300-400 (and perhaps even 200) tabs
> on XP.
Once I "get over the hump" Firefox runs GREAT, possibly 10-20% slower than I might like it to but since my Computer is a half dozen years old, I expect no more of it.
Once it is kickstarted it works well enough that if it had ran that way in the first place (without a kickstart) I would have no complaint at all.
Note: I "get over the hump" (or "kickstart") (when there are more than 250 Tabs involved) by:
1. Opening a saved Session.
2. Terminating Firefox when cache allocations "flatten out" (just past 2GB).
3. Don't bother trying to save the partially opened Session when asked.
4. Open the saved Session from Step 1, again.
Now (after a SECOND restart) Firefox starts normally and runs fairly quicly and smoothly.
Again, see the Screenshot to see what this looks like.
> > > it would help immensely to provide details of the steps and URLs required to
> > > get into this problem state.
> >
> > It almost always occurs with many Tabs open (thus I am low on memory and the
> > Browser needs to go from allocating "real" (physical) memory to cache (swap
> > drive) memory) and WinXP Task Manager reports "Physical Memory (K)[C/R]
> > Available" at less than about 320K (my "Commit Charge (K) [C/R] Limit" is
> > 769K -- IE: I have 4GB or real memory and 4GB of Swap).
> >
> > I usually have over 2-3 hundred Tabs open (to use that much memory) so
> > providing a list of URLs is not practical. It is unfortunate that the two
> > .LOGs and the .PNG were not helpful to show what to look for.
> I could be wrong but I doubt this info is going to be useful. And even if it
> is, you have an edge case (300-400 tabs) that isn't a typical user and so
> isn't going to garner attention from developers.
>
> That said, firefox performance has improved over the last few months and
> will get continue to get better. And it is great that you are running the
> development builds, and are trying to help. But your time is probably too
> important to be pursuing this type of testcase.
I agree that most users don't have that many Tabs open.
I have them open so I can swap from one hobby to another, check prices at various stores for different items, and go from Project to Project without having each saved in a different Session and waiting for each to reload.
I try (assuming no crashes) to leave my Browser open all the time and run it along with any other Programs.
I use the PAE and 3GB switches in my Startup (one example discussion: http://www.techsupportforum.com/forums/f10/the-old-4gb-pae-thing-274199.html).
> Here's what helped me the most:
> - install flashblock addon
> - severely minimize use of addons
> - disable or lower fast back history (or whatever it is called) that keeps
> previous pages of a tab in memory - I think the default is 8. However, they
> might have removed the hidden preference - I no longer recall because I last
> looked at this a couple years ago
> - reduce the number of tabs, especially ones in js-heavy and those with lots
> of images. game pages for example. you can also reduce the number of tabs
> by running more than one browser. google chrome works great here, to a point.
Thanks for the Tips. I think the best solution will be a new Computer (waiting on AMD Trinity Piledriver) and Win8.
I use Flash a lot (YouTube and other Sites) and have over a dozen add-ons and Plugins. I do use a second Browser at times when I want to delve into something but KNOW that it won't be kept a part of my 300+ Tabs -- that said I am trying to go through my Tabs and close a hundred :) -- it feels like throwing out a Book.
See the Screenshot in next Post.
Firefox Aurora 12.0a2 crashes when restarted FIRST time (with many Tabs open) but NOT when reopened a SECOND time, then it runs well and uses LESS memory than previously.
While MOST people may not open that many Tabs my doing so seems to have exposed a memory allocation problem and possibly an issue with GC too.
By fixing my complaint it will ensure that so-called "common usage" (far less that 300 Tabs) will always work well.
The screenshot clearly shows an inconsistency in the allocation of memory (IE: 1. works OK when adding Tabs over a period of time, 2. crashes on first restart since it won't allocate more than 2GB, 3. works fine on second restart BUT winds up using LESS memory than it did before (when restoring the exact same Tabs))
So I assume (or analyze) that 1. GC is broke and/or 2. memory is being allocated but not released when it could be, and/or 3. we are occasionally using memory pointers that were not allocated to the function using them or releasing memory in a function that did not allocate the pointer.
When I get a brand new Computer (20+ times faster than this one) I can compile with Mudflaps and look for the problem myself; hopefully that won't be more than a couple of months away.
Comment 10•13 years ago
|
||
(In reply to Rob from comment #8)
> (In reply to Wayne Mery (:wsmwk) from comment #7)
> > (In reply to Rob from comment #6)
> > > (In reply to Wayne Mery (:wsmwk) from comment #5)
> > > > (In reply to Rob from comment #4)
> > > > >
> > > > > There is a problem with allocation of Memory past the 4GB mark (on WinXP in
> > > > > 32 Bit mode) that is causing Memory corruption; this leads to ...
> >
> > Is this analysis an assumption on your part?
>
> I have a screenshot that demonstrates the problem. I keep getting the
> problem in the same area.
>
> Kind of like driving down a dark road and hearing a big bang in the same
> spot each time. Looking at the dents in your Rim you can assume from your
> analysis that it is a pothole.
analogies are useless. but if you must use analogy, I would say you are making an analysis of a poorly performing care by looking at the body of a car when what is really needed is a diagnostic computer hooked up under the hood of the car
> > 1. If my memory is accurate, processes on XP (i.e. thunderbird) can't exceed
> > 2gb.
> >
> > 2. Furthermore, at 200-400 tabs you absolutely are in territory where you
> > start hitting issues with GDI. The absolute ceiling is GDIProcessHandleQuota
> > =10,000 default. However, FIrefox will start behaving poorly and even crash
> > in the 6,000-8,000 range. This is all about windows, not firefox. I have
> > significant first hand experience with this, having routinely run 100-300
> > tabs on XP for a long time. It wasn't pretty. see bug 551667 and bug 640162
> > comment 4
> >
> > 3. Even if you solved both of the above issues (which you can on win7 and
> > 64bit firefox) with ~100+ tabs you hit yet a third issue, namely GC and CC
> > performance that mozilla have been working on for the past year.
> >
> > 4. lastly you may find you have a humungous sessionstore.js file which is
> > helping to kill your performance
> >
> > In short your options are limited, and using current version of Firefox you
> > aren't likely to ever be happy running 300-400 (and perhaps even 200) tabs
> > on XP.
>
> Once I "get over the hump" Firefox runs GREAT, possibly 10-20% slower than I
> might like it to but since my Computer is a half dozen years old, I expect
> no more of it.
>
> Once it is kickstarted it works well enough that if it had ran that way in
> the first place (without a kickstart) I would have no complaint at all.
you didn't cite firefox's GDI and handle count leading up to the crash. If you get that info then we have something useful to talk about
> Note: I "get over the hump" (or "kickstart") (when there are more than 250
> Tabs involved) by:
> 1. Opening a saved Session.
> 2. Terminating Firefox when cache allocations "flatten out" (just past 2GB).
> 3. Don't bother trying to save the partially opened Session when asked.
> 4. Open the saved Session from Step 1, again.
>
> Now (after a SECOND restart) Firefox starts normally and runs fairly quicly
> and smoothly.
>
>
> Again, see the Screenshot to see what this looks like.
This isn't terribly useful.
> I have them open so I can swap from one hobby to another, check prices at
> various stores for different items, and go from Project to Project without
> having each saved in a different Session and waiting for each to reload.
>
> I try (assuming no crashes) to leave my Browser open all the time and run it
> along with any other Programs.
>
> I use the PAE and 3GB switches in my Startup (one example discussion:
> http://www.techsupportforum.com/forums/f10/the-old-4gb-pae-thing-274199.
> html).
enabling PAE affects only ONE XP limitations - ability to use more real memory. All other XP limitations remain. In other words, it does not improve your ability the problem being discussed here.
> > Here's what helped me the most:
> > - install flashblock addon
> > - severely minimize use of addons
> > - disable or lower fast back history (or whatever it is called) that keeps
> > previous pages of a tab in memory - I think the default is 8. However, they
> > might have removed the hidden preference - I no longer recall because I last
> > looked at this a couple years ago
> > - reduce the number of tabs, especially ones in js-heavy and those with lots
> > of images. game pages for example. you can also reduce the number of tabs
> > by running more than one browser. google chrome works great here, to a point.
>
> Thanks for the Tips. I think the best solution will be a new Computer
> (waiting on AMD Trinity Piledriver) and Win8.
There is no doubt in my mind that running a 64bit OS and 64bit firefox will help your situation.
> I use Flash a lot (YouTube and other Sites) and have over a dozen add-ons
> and Plugins. I do use a second Browser at times when I want to delve into
> something but KNOW that it won't be kept a part of my 300+ Tabs -- that said
> I am trying to go through my Tabs and close a hundred :) -- it feels like
> throwing out a Book.
you would do well then to install flashblock
(In reply to Rob from comment #9)
> Created attachment 598623 [details]
> Screenshot of WTM when running and restarting Aurora 12 - shows memory
> problem.
>
> Firefox Aurora 12.0a2 crashes when restarted FIRST time (with many Tabs
> open) but NOT when reopened a SECOND time, then it runs well and uses LESS
> memory than previously.
[1] This mainly demonstrates that firefox doesn't completely load all tabs after a restore - which is expected.
> While MOST people may not open that many Tabs my doing so seems to have
> exposed a memory allocation problem and possibly an issue with GC too.
yes. but
> By fixing my complaint it will ensure that so-called "common usage" (far
> less that 300 Tabs) will always work well.
>
> The screenshot clearly shows an inconsistency in the allocation of memory
> (IE: 1. works OK when adding Tabs over a period of time, 2. crashes on first
> restart since it won't allocate more than 2GB, 3. works fine on second
> restart BUT winds up using LESS memory than it did before (when restoring
> the exact same Tabs))
[1] again. n
> So I assume (or analyze) that 1. GC is broke and/or 2. memory is being
> allocated but not released when it could be, and/or 3. we are occasionally
> using memory pointers that were not allocated to the function using them or
> releasing memory in a function that did not allocate the pointer.
>
> When I get a brand new Computer (20+ times faster than this one) I can
> compile with Mudflaps and look for the problem myself; hopefully that won't
> be more than a couple of months away.
I don't see Mudflaps being any help here. And unless you plan on running a preview release you wont be seeing windows 8 before fall 2012 at the earliest.
You might install this morning's nightly build (version 13) dated 2/19/2012 - because incremental GC landed yesterday. That may help your performance. But it will not improve memory usage.
Comment 11•13 years ago
|
||
you may also find that sessionstore.js is large. this can also cause performance problems.
also, instead of loading many tabs for multiple hobbies in the same browser, eg 300 tabs, you should probably use multiple profiles each running fewer tabs, for example 50 tabs per browser.
Summary: Nightly 11.0a1 - Exit hangs, attaching WinDbg finds memory corruption; cache very slow to flush → Exit is slow. Firefox using lots of memory with very high tab count.
Comment 12•13 years ago
|
||
please list your addons from help | troubleshooting
Reporter | ||
Comment 13•13 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #10)
> (In reply to Rob from comment #8)
> > (In reply to Wayne Mery (:wsmwk) from comment #7)
> > > (In reply to Rob from comment #6)
> > > > (In reply to Wayne Mery (:wsmwk) from comment #5)
> > > > > (In reply to Rob from comment #4)
> > > > > >
> > > > > > There is a problem with allocation of Memory past the 4GB mark (on WinXP in
> > > > > > 32 Bit mode) that is causing Memory corruption; this leads to ...
> > >
> > > Is this analysis an assumption on your part?
> >
> > I have a screenshot that demonstrates the problem. I keep getting the
> > problem in the same area.
> >
> > Kind of like driving down a dark road and hearing a big bang in the same
> > spot each time. Looking at the dents in your Rim you can assume from your
> > analysis that it is a pothole.
>
> analogies are useless. but if you must use analogy, I would say you are
> making an analysis of a poorly performing care by looking at the body of a
> car when what is really needed is a diagnostic computer hooked up under the
> hood of the car
I _could_ run it under WinDbg except that it takes over an hour and a half to load that many Tabs (under WinDbg, 25 min. without) _and_ under WinDbg this problem sometimes does not reproduce (so I might have to try a few times).
(A new Computer is long overdue, as is the uProcessor I am waiting for (now it's coming in 2013 - but I won't wait that long)).
> > > 1. If my memory is accurate, processes on XP (i.e. thunderbird) can't exceed
> > > 2gb.
> > >
> > > 2. Furthermore, at 200-400 tabs you absolutely are in territory where you
> > > start hitting issues with GDI. The absolute ceiling is GDIProcessHandleQuota
> > > =10,000 default. However, FIrefox will start behaving poorly and even crash
> > > in the 6,000-8,000 range. This is all about windows, not firefox. I have
> > > significant first hand experience with this, having routinely run 100-300
> > > ...
> > > In short your options are limited, and using current version of Firefox you
> > > aren't likely to ever be happy running 300-400 (and perhaps even 200) tabs
> > > on XP.
> >
> > Once I "get over the hump" Firefox runs GREAT, possibly 10-20% slower than I
> > might like it to but since my Computer is a half dozen years old, I expect
> > no more of it.
> >
> > Once it is kickstarted it works well enough that if it had ran that way in
> > the first place (without a kickstart) I would have no complaint at all.
>
> you didn't cite firefox's GDI and handle count leading up to the crash. If
> you get that info then we have something useful to talk about
1. 308 Tabs open (with half a dozen YouTube pages and over a dozen 'Flash Sites').
2. After 'kickstart' (with it running smoothly): Handles: 23868 Threads 952 Processes 78 -- Available Memory 398940 (out of 3668460)
Next time it crashes I will try to catch the "Handle Count" but I have well over 20k of Handles with it running (kickstarted).
> > Again, see the Screenshot to see what this looks like.
>
> This isn't terribly useful.
I can see the Cache load properly if Tabs are added slowly, if I restart then I hit a limit, when I start the second time I can pass that limit (where it flatlines).
> There is no doubt in my mind that running a 64bit OS and 64bit firefox will
> help your situation.
I have the $, just need them to make the uP and GPU (Heterogeneous) but the wait is too long (2013) so I'll look at Trinity when it comes.
> (In reply to Rob from comment #9)
> > Created attachment 598623 [details]
> > Screenshot of WTM when running and restarting Aurora 12 - shows memory
> > problem.
> >
> > Firefox Aurora 12.0a2 crashes when restarted FIRST time (with many Tabs
> > open) but NOT when reopened a SECOND time, then it runs well and uses LESS
> > memory than previously.
>
> [1] This mainly demonstrates that firefox doesn't completely load all tabs
> after a restore - which is expected.
>
> > While MOST people may not open that many Tabs my doing so seems to have
> > exposed a memory allocation problem and possibly an issue with GC too.
>
> yes. but
>
> > By fixing my complaint it will ensure that so-called "common usage" (far
> > less that 300 Tabs) will always work well.
> >
> > The screenshot clearly shows an inconsistency in the allocation of memory
> > (IE: 1. works OK when adding Tabs over a period of time, 2. crashes on first
> > restart since it won't allocate more than 2GB, 3. works fine on second
> > restart BUT winds up using LESS memory than it did before (when restoring
> > the exact same Tabs))
>
> [1] again. n
Yes, but; it exceeds the 'flatline' where it crashed on the first restart.
> > So I assume (or analyze) that 1. GC is broke and/or 2. memory is being
> > allocated but not released when it could be, and/or 3. we are occasionally
> > using memory pointers that were not allocated to the function using them or
> > releasing memory in a function that did not allocate the pointer.
> >
> > When I get a brand new Computer (20+ times faster than this one) I can
> > compile with Mudflaps and look for the problem myself; hopefully that won't
> > be more than a couple of months away.
>
> I don't see Mudflaps being any help here. And unless you plan on running a
> preview release you wont be seeing windows 8 before fall 2012 at the
> earliest.
Mudflaps would (likely) catch allocations that are exceeded, double free()s, and free()s of unallocated - which MIGHT catch the problem.
Another thought is that we might be mixing our allocation procedures, by that I mean "don't mix calls on memory segments between malloc/free and fmalloc/ffree".
> You might install this morning's nightly build (version 13) dated 2/19/2012
> - because incremental GC landed yesterday. That may help your performance.
> But it will not improve memory usage.
I update Nightly and Aurora as it comes down the pipe and the 'Release' I try to check for Updates once a month.
Hans Boehm [1] updated his Code but GCC did not (as of a year ago) and used two different versions of GC, I doubt 'MS Code' (which is more applicable to my situation) has the same trouble.
Boehm has had incremental GC for a while (and other advances), we are behind the curve to have it land yesterday.
[1] http://www.hpl.hp.com/personal/Hans_Boehm/gc/
>>> you may also find that sessionstore.js is large. this can also cause performance problems.
>>>also, instead of loading many tabs for multiple hobbies in the same browser,
>>> eg 300 tabs, you should probably use multiple profiles each running fewer
>>> tabs, for example 50 tabs per browser.
It would still be about 100 per Session, there is a bit of overlap to synchronize, and a 10 min. Tab load time to switch Sessions.
Reporter | ||
Comment 14•13 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #12)
> please list your addons from help | troubleshooting
Extensions
Name Version Enabled ID
Adblock Plus 2.0.3 true {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Add-on Compatibility Reporter 1.0.3 true compatibility@addons.mozilla.org
Advertising Cookie Opt-out 1.5 true optout@google.com
Browser Defender Toolbar 3.0.0.313 true {cb84136f-9c44-433a-9048-c5cd9df1dc16}
Element Hiding Helper for Adblock Plus 1.2.1 true elemhidehelper@adblockplus.org
Flagfox 4.1.12 true {1018e4d6-728f-4b20-ad56-37578a4de76b}
Java Quick Starter 1.0 true jqs@sun.com
Microsoft .NET Framework Assistant 1.0 true {20a82645-c095-46ed-80e3-08825760534b}
Nightly Tester Tools 3.2.1.1 true {8620c15f-30dc-4dba-a131-7c5d20cf4a29}
NoScript 2.3.1rc2 true {73a6fe31-595d-460b-a920-fcc0f8843232}
RealPlayer Browser Record Plugin 15.0.0 true {ABDE892B-13A8-4d1b-88E6-365A6E755758}
RightToClick 2.8.9 true {cd617375-6743-4ee8-bac4-fbf10f35729e}
Tab Mix Plus 0.4.0pre.120207a true {dc572301-7619-498c-a57d-39143191b318}
Test Pilot 1.2 true testpilot@labs.mozilla.com
DivX Plus Web Player HTML5 <video> 2.1.2.145 false {23fcfd51-4958-4f00-80a3-ae97e717ed8b}
Reporter | ||
Comment 15•13 years ago
|
||
Unfortunately when it crashes I get an empty Dump: bp-54dcfda9-c5cd-4d75-9fc7-e70132120226 I reported that Bug in another Report.
Comment 16•13 years ago
|
||
(In reply to Rob from comment #13)
> >>>also, instead of loading many tabs for multiple hobbies in the same browser,
> >>> eg 300 tabs, you should probably use multiple profiles each running fewer
> >>> tabs, for example 50 tabs per browser.
>
> It would still be about 100 per Session, there is a bit of overlap to
> synchronize, and a 10 min. Tab load time to switch Sessions.
of course. but it will load faster, and perform far better than an instance with 400 tabs. If if segregated by work type, surely not substantially slower to switch a to a different window, versus finding and switching to a different tab.
GDI count??
WHat results do you get when running without Tab Mix Plus? I hear it can substantially affect memory usage.
Reporter | ||
Comment 17•13 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #16)
> (In reply to Rob from comment #13)
> > >>>also, instead of loading many tabs for multiple hobbies in the same browser,
> > >>> eg 300 tabs, you should probably use multiple profiles each running fewer
> > >>> tabs, for example 50 tabs per browser.
> >
> > It would still be about 100 per Session, there is a bit of overlap to
> > synchronize, and a 10 min. Tab load time to switch Sessions.
>
> of course. but it will load faster, and perform far better than an instance
> with 400 tabs. If if segregated by work type, surely not substantially
> slower to switch a to a different window, versus finding and switching to a
> different tab.
I will try closing more Tabs, try splitting the workload along some kind of (wiggly) line and attempt to make multiple Sessions that will each be loaded into a separate Window (instance) of Firefox and switch between Windows.
> GDI count??
I thought I had answered that in Comment 13 (with "Handle Count"). I did some Googling and came up with "GDIView" http://www.nirsoft.net/utils/gdi_handles.html .
GDIView says that the Process Firefox.exe has a "GDI Total" of 2991 and an "All GDI" of 3010.
There is no 'Total for every Process' feature but doing some quick math I can see that it is easily under 6000.
Taking a peek at about:memory I see this
Main Process
Explicit Allocations
2,101.19 MB (100.0%) -- explicit
├────940.06 MB (44.74%) -- js
│ ├──484.35 MB (23.05%) ++ (536 tiny)
│ ├──139.08 MB (06.62%) -- compartment(https://plus.google.com/u/...
│ │ ├───66.46 MB (03.16%) -- gc-heap
│ │ │ ├──26.41 MB (01.26%) ── scripts [2]
│ │ │ ├──21.39 MB (01.02%) ++ objects
│ │ │ └──18.66 MB (00.89%) ++ (4 tiny)
│ │ ├───47.56 MB (02.26%) ── script-data [2]
│ │ └───25.06 MB (01.19%) ++ (6 tiny)
│ ├──102.23 MB (04.87%) -- compartment(https://plusone.google.com/_/...
│ │ ├───52.38 MB (02.49%) ++ gc-heap
│ │ ├───32.97 MB (01.57%) ── script-data [2]
│ │ └───16.89 MB (00.80%) ++ (6 tiny)
│ ├───73.35 MB (03.49%) -- compartment([System Principal], 0x376e000)
│ │ ├──43.89 MB (02.09%) ++ gc-heap
│ │ └──29.46 MB (01.40%) ++ (7 tiny)
│ ├───41.17 MB (01.96%) ++ compartment(https://encrypted.google.com/...
│ ├───41.05 MB (01.95%) ── gc-heap-decommitted
│ ├───35.52 MB (01.69%) ++ compartment(http://www.youtube.com/watch?...
│ └───23.31 MB (01.11%) ++ compartment(http://www.google.ca/search?q=...
├────476.73 MB (22.69%) ++ layout
├────299.10 MB (14.23%) -- dom+style
│ └──299.10 MB (14.23%) -- window-objects
│ ├──299.09 MB (14.23%) ++ active
│ └────0.00 MB (00.00%) ++ other
├────241.50 MB (11.49%) ── heap-unclassified
├────110.42 MB (05.26%) -- images
│ ├──110.06 MB (05.24%) -- content
│ │ ├──110.06 MB (05.24%) -- used
│ │ │ ├───96.51 MB (04.59%) ── raw
│ │ │ └───13.55 MB (00.64%) ++ (2 tiny)
│ │ └────0.00 MB (00.00%) ++ unused
│ └────0.36 MB (00.02%) ++ chrome
└─────33.39 MB (01.59%) ++ (9 tiny)
Other Measurements
73.30 MB ── canvas-2d-pixel-bytes
112.47 MB ── dom-total-window
2,101.19 MB ── explicit
0.00 MB ── gfx-d2d-surfacecache
0.00 MB ── gfx-d2d-surfacevram
0.00 MB ── gfx-surface-image
87.54 MB ── gfx-surface-win32
1,553.13 MB ── heap-allocated
1,639.09 MB ── heap-committed
5.24% ── heap-committed-fragmentation
3.11 MB ── heap-dirty
226.87 MB ── heap-unallocated
19 ── js-compartments-system
718 ── js-compartments-user
505.00 MB ── js-gc-heap
24.91 MB ── js-main-runtime-analysis-temporary
82.67 MB ── js-main-runtime-gc-heap-arena-unused
0.00 MB ── js-main-runtime-gc-heap-chunk-clean-unused
0.00 MB ── js-main-runtime-gc-heap-chunk-dirty-unused
41.05 MB ── js-main-runtime-gc-heap-decommitted
0.00% ── js-main-runtime-gc-heap-unused-fraction
32.61 MB ── js-main-runtime-mjit
179.95 MB ── js-main-runtime-objects
299.24 MB ── js-main-runtime-scripts
169.37 MB ── js-main-runtime-shapes
31.28 MB ── js-main-runtime-strings
44.68 MB ── js-main-runtime-type-inference
0 ── low-memory-events-physical
0 ── low-memory-events-virtual
2,310.02 MB ── private
2,333.15 MB ── resident
11.72 MB ── storage-sqlite
186.62 MB ── style-sheets-total-window
2,573.84 MB ── vsize
> WHat results do you get when running without Tab Mix Plus? I hear it can
> substantially affect memory usage.
First off my 300+ Tabs (saved in a TM+ Session) would not get loaded. If I saved a list of them, loaded them all back into Firefox, and used Firefox's Session saving feature then I could check that.
TM+ is entirely JS based (isn't it) and thus if it breaks something it is breaking OUR JavaScript Interpreter (isn't it?).
Reporter | ||
Comment 18•13 years ago
|
||
This Screenshot shows that just as the Browser is about to crash that Firefox has corrupted it's own Screen (whereas the Operating System's Screen remains OK).
It also shows that I can not even launch Notepad without that failing to load.
Sometimes I get a popup (from the OS) saying that one of my svchost.exe instances has crashed (I usually have a half a dozen svchost.exe Processes running), but not this time.
I was able to get the Screenshot because I used a capture Program that loads before Firefox runs. It was able to capture a Screenshot but I couldn't even use my [Start] Button to restart the Computer, I had to power off to reboot.
So there is some leakage in the allocations (as evidenced by the corrupted Firefox Window).
(Note: After restarting and reloading the Browser (with the exact same TM+ Session) a second time everything works FINE and the Browser runs reasonably quickly with over 300 Tabs open. If it did this the first time I would have no Bug to report).
Reporter | ||
Comment 19•13 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #7)
> (In reply to Rob from comment #6)
> > (In reply to Wayne Mery (:wsmwk) from comment #5)
> > > (In reply to Rob from comment #4)
> > > >
> > > > There is a problem with allocation of Memory past the 4GB mark (on WinXP in
> > > > 32 Bit mode) that is causing Memory corruption; this leads to ...
>
> Is this analysis an assumption on your part?
>
> 1. If my memory is accurate, processes on XP (i.e. thunderbird) can't exceed
> 2gb.
>
> 2. Furthermore, at 200-400 tabs you absolutely are in territory where you
> start hitting issues with GDI. The absolute ceiling is GDIProcessHandleQuota
> =10,000 default. However, FIrefox will start behaving poorly and even crash
> in the 6,000-8,000 range. This is all about windows, not firefox. ...
> ...
My HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows is set to the default of 10,000 .
As mentioned in Comment 17: GDIView says that the Process Firefox.exe has a "GDI Total" of 2991 and an "All GDI" of 3010, and my 'all Process total' is less than 6k (by eye).
Comment 20•13 years ago
|
||
(In reply to Rob from comment #17)
> (In reply to Wayne Mery (:wsmwk) from comment #16)
> > (In reply to Rob from comment #13)
> > > >>>also, instead of loading many tabs for multiple hobbies in the same browser,
> > > >>> eg 300 tabs, you should probably use multiple profiles each running fewer
> > > >>> tabs, for example 50 tabs per browser.
> > >
> > > It would still be about 100 per Session, there is a bit of overlap to
> > > synchronize, and a 10 min. Tab load time to switch Sessions.
> >
> > of course. but it will load faster, and perform far better than an instance
> > with 400 tabs. If if segregated by work type, surely not substantially
> > slower to switch a to a different window, versus finding and switching to a
> > different tab.
>
> I will try closing more Tabs, try splitting the workload along some kind of
> (wiggly) line and attempt to make multiple Sessions that will each be loaded
> into a separate Window (instance) of Firefox and switch between Windows.
>
>
> > GDI count??
>
> I thought I had answered that in Comment 13 (with "Handle Count"). I did
> some Googling and came up with "GDIView"
> http://www.nirsoft.net/utils/gdi_handles.html .
>
> GDIView says that the Process Firefox.exe has a "GDI Total" of 2991 and an
> "All GDI" of 3010.
I'm not familiar with GDIView, but 3k GDI for firefox with 300 tabs seems to me to be awfully low.
To see gdi count for a process within taskmgr, add the column via view | select columns.
Reporter | ||
Comment 21•13 years ago
|
||
More Googling ...
That it might be a JS issue lead me to https://bugs.eclipse.org/bugs/show_bug.cgi?id=211124 (their c # 17) and onto http://journals.jevon.org/users/jevon-phd/entry/19833 - my WTM "GDI Object" is 1843 (far less than GDIView reports).
I've installed Dheapmon to check if that is part of the problem.
Reporter | ||
Comment 22•13 years ago
|
||
Here is a WinDbg Log. By allowing Firefox to run for a while when starting and then attaching the Debugger I greatly sped up the startup while still permitting debugging.
Once it got near to 2GB the Window snapped shut (no Error Reporter popup) but the crash was no so bad the it took the OS (and the Debugger) with it - thus I have a Log.
After the crash I simply restarted it (with the SAME 310 Tabs), it starts fairly fast and works fine. It is only the first attempt that fails and when you try the exact same thing a second time all is fine. grrrr.
Reporter | ||
Comment 23•13 years ago
|
||
At this moment (after the last Update) Aurora fine works with one start but Nightly still needs a restart to load the exact same set of Tabs.
When Nightly crashed it produced bp-cf259747-cc06-4e7c-8e3e-5d6f82120227 unfortunately stackwalk.sh returned no header lines, but the 'Memory Report' is at the end.
Fixed in Aurora, broken in Nightly.
Reporter | ||
Comment 24•13 years ago
|
||
(In reply to Rob from comment #22)
> ...
> Once it got near to 2GB the Window snapped shut (no Error Reporter popup)
> but the crash was no so bad that it took the OS (and the Debugger) with it ...
Currently Nightly no longer crashes the OS (as mentioned in Comment 22) but the Screen corruption (mentioned in Comment 18) still occurs during startup when loading 300+ Tabs.
Nightly is now able to start and _exceed_ the "2GB limit" before the WTM shows it 'flatlining' and pinning one Core.
It stills needs to be terminated and restarted to load all it's Tabs (when there are over 300+ Tabs) but at least it seems to be able to use all the available (real) Memory (leaving only 200k free Memory). If only it could send 'old Tabs' to Window's Swap would it be able to fully start.
I tested FF "Release" yesterday and it is the same as Nightly was (two days ago).
Thus, this BR is _almost_ fixed. Nightly still needs to start on 'one start' (with too many Tabs open) and it could do so IF it could use VM as well as RM. I presume that TM+ doesn't tell the Browser which Tabs are old (and could be sent to the Swap) and that Nightly simply tries to load everything into real Memory.
Reporter | ||
Comment 25•13 years ago
|
||
Nightly now operates differently than it did when this was first reported.
Nightly will now load with many Tabs (re-opened from a prior run using TM+) and start without problems.
The "difference", compared to previous operation, is that although the Tabs are "re-opened" they are not "re-loaded" (each loads when accessed); thus it is easier (and WAY faster) for Nightly to start.
To 'fix' the "difference" simply right-click on a Tab and choose "Reload All Tabs" (which STILL results in a quicker restart (total time) than when Nightly chose "Reload All Tabs" for you (default? or TM+ change).
The "exit speed" is also greatly improved.
There is no (or not enough of a) complaint remaining, closing.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•