Closed Bug 703952 Opened 14 years ago Closed 13 years ago

Leak in Firefox on news.yahoo.com (~300 KB/click)

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Version:
8 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: q1, Unassigned)

Details

(Whiteboard: [MemShrink:P2])

Attachments

(1 file)

about:memory verbose after 1300 clicks
13.70 KB, text/plain
Details
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.24) Gecko/20111103 Firefox/3.6.24 (.NET CLR 3.5.30729) Build ID: 20111103063747 Steps to reproduce: 1. Create a new profile and start Firefox using it. Make sure NO extensions are installed. 2. Visit news.yahoo.com. 3. Click on an active story. 4. Scroll to the comments section of the story by searching for "all comments". 5. Open Process Explorer, locate the Firefox process, and note the value in the "private bytes" column. 6. Click "shared on Facebook", then "all comments", then "shared on Facebook" again, then "all comments", etc., clicking 100 times total. This will take a few minutes. Actual results: 7. Observe that Firefox's private bytes value at the end of step 6, above, is ~33 MB greater than its value at the end of step 5, and that it stays there, having gained > 300KB per click. Expected results: Firefox's private bytes total should fairly rapidly decline to approximately what it was at the end of step 5, above.
The Firefox 3.6 branch will only get security and stability fixes. There has been a lot of memory issues resolved in recent versions of Firefox. Are you able to reproduce the issue in Firefox Nightly https://nightly.mozilla.org/ or at least in Firefox 8 https://www.mozilla.org/en-US/firefox/all.html? You should select "Minimize memory usage" in about:memory both before and after doing a measurement in order to get meaningful values, and about:memory is also the primary place to look at when telling where the memory has gone.
(In reply to Thomas Ahlblom from comment #1) > The Firefox 3.6 branch will only get security and stability fixes. > > There has been a lot of memory issues resolved in recent versions of > Firefox. Are you able to reproduce the issue in Firefox Nightly > https://nightly.mozilla.org/ or at least in Firefox 8 > https://www.mozilla.org/en-US/firefox/all.html? > > You should select "Minimize memory usage" in about:memory both before and > after doing a measurement in order to get meaningful values, and > about:memory is also the primary place to look at when telling where the > memory has gone. I have tested with FF 8, using the following procedure: 1. Create a new profile and start Firefox using it. Make sure NO extensions are installed. 2. Open about:memory. 3. Open news.yahoo.com in a different window. 4. Click on an active story. 5. Scroll to the comments section of the story by searching for "all comments". 6. Open Process Explorer & locate the Firefox process. 7. Click "minimize memory usage" in the "about:memory" window, noting the resulting values for private/resident/vsize and the "private bytes" value in Process Explorer. 8. Click "shared on Facebook", then "all comments", then "shared on Facebook" again, then "all comments", etc., clicking 200 times total. This will take a few minutes. 9. Measure the memory size values each 10 clicks until 100 clicks, then at 150 and 200 clicks. Measure the "about:memory" memory size values by refreshing the "about:memory" window. 10. Click "minimize memory usage" and measure the final values again. Actual results: All memory sizes increased nearly monotonically, as follows: # clicks Process Explorer about:memory private bytes private bytes resident bytes vsize 0 132M 129M 133M 257M 10 132M 136M 139M 256M 20 134M 134M 136M 254M 30 135M 136M 139M 254M 40 136M 138M 141M 255M 50 137M 139M 142M 256M 60 139M 138M 142M 256M 70 140M 141M 145M 257M 80 142M 143M 147M 257M 90 146M 146M 149M 258M 100 148M 148M 151M 259M 150 173M 169M 173M 293M 200 191M 192M 195M 329M 200 188M 184M 188M 319M (after "minimize memory usage") After 100 clicks, private bytes leaked about 16M, or ~160 KB/click. Leakage seemed to accelerate around this point. At 150 clicks, leakage was about 41M, or ~270 KB/click. At 200 clicks, the tally was 59 MB and ~300 KB/click before "minimize memory usage", and 56 MB and ~280 KB/click afterward.
Version: 3.6 Branch → 8 Branch
Whiteboard: [Memshrink]
Whiteboard: [Memshrink] → [MemShrink]
This bug still exists in 8.0.1, though the leakage is somewhat smaller: # clicks Process Explorer private bytes 0 133M 100 161M (~280 KB/click) 150 170M (~250 KB/click) 200 183M (~250 KB/click) 200 177M (~220 KB/click) (after "minimize memory usage")
q1, can you please test with the Firefox nightly [1] and post the full contents of about:memory?verbose at each stage of your test? Clicking around on a JS-heavy page like yahoo or Facebook is likely to run code which could do any number of things. It's not so surprising to me that memory increases here, and it's not clear to me that Firefox is misbehaving. Anyway, we'll look at the about:memory results from the nightly build and see if things look out of place. [1] http://nightly.mozilla.org
Whiteboard: [MemShrink] → [MemShrink:P2]
> post the full contents of about:memory?verbose at each stage of your test? As an attachment, please. :)
(In reply to Justin Lebar [:jlebar] from comment #4) > q1, can you please test with the Firefox nightly [1] and post the full > contents of about:memory?verbose at each stage of your test? Unfortunately security issues prevent me from using non-release software at present, so I must ask some kind reader to take up that baton. > Clicking around on a JS-heavy page like yahoo or Facebook is likely to run code > which could do any number of things. It's not so surprising to me that memory > increases here, and it's not clear to me that Firefox is misbehaving. Perhaps. It's interesting, though, that the per-click memory usage increase seems to have shrunk somewhat from 8.0 to 8.0.1. That said, I know little about JS. Is it possible for a script to leak objects?
> Unfortunately security issues prevent me from using non-release software at present, so I must ask > some kind reader to take up that baton. about:memory?verbose from the current release would also be useful. The 8.0 to 8.0.1 update was nop on Windows. It only affected things on Mac. > Is it possible for a script to leak objects? JavaScript code can create and hold onto objects, just like any other programming language. But additionally, running JS takes up memory in Firefox. There should be an upper bound on the amount of memory used, though. It's not clear whether the growth is unbounded here.
I have done further tests with 8.0.1, though not as in-depth as requested. Memory usage growth does appear to be unbounded. Here are the details: # clicks Process Explorer KB/click KB/click private bytes non-cumulative cumulative 0 146M - - 100 211M 650 650 200 241M 300 475 300 277M 360 437 400 319M 420 433 500 346M 270 400 600 364M 180 363 700 399M 350 361 800 436M 370 363 900 478M 420 369 1000 528M 500 382 1100 580M 520 395 1200 593M 130 373 1300 621M 280 365 about:memory?verbose after 1300 clicks is attached.
Comment on attachment 578932 [details] about:memory verbose after 1300 clicks 207,131,013 B (35.38%) -- compartment(http://news.yahoo.com/) 165,539,840 B (28.28%) -- gc-heap You can see here that the Yahoo compartment is using a lot of memory. This is likely because the site itself is holding onto objects. The rest of the compartments, as you can see, are tiny. The 50% heap-unclassified is a bug, certainly. (We really need to fix those outstanding ones, so we know whether new reports are new dark matter bugs.)
So now the question is: Does this memory blow-up happen in other browsers? If so, it's almost certainly a bug in the page.
Product: Firefox → Core
QA Contact: general → general
(In reply to Justin Lebar [:jlebar] from comment #11) > So now the question is: Does this memory blow-up happen in other browsers? > If so, it's almost certainly a bug in the page. I beg another Mozilla community member to try that. I can't do it in the foreseeable future.
I don't have the patience to click thousands of times, but Chrome's memory usage increases at a rate of ~.38mb / click, very close to the number you saw for Firefox. So I suspect this is a bug Yahoo News. Do you agree, q1? If so, please close this bug.
(In reply to Justin Lebar [:jlebar] from comment #13) > I don't have the patience to click thousands of times, but Chrome's memory > usage increases at a rate of ~.38mb / click, very close to the number you > saw for Firefox. > > So I suspect this is a bug Yahoo News. > > Do you agree, q1? If so, please close this bug. Given the available evidence, I disagree. First, in comment 10, you said, "The 50% heap-unclassified is a bug, certainly." Well, heap-unclassified grows with each click. Second, just because Chrome seems to exhibit a similar behavior does not mean that Firefox has no bug -- both browsers could have similar bugs. Third, since you didn't click "thousands of times" (as I did), we don't really know whether Chrome's allocations grow without bound, as Firefox's seem to. I have found a very simple test case that would seem to bear some deeper investigation. I do not have the time to learn the Mozilla platform to investigate it myself. I hope that others will do so. Closing this bug now would tend to reinforce a not-uncommon perception about Firefox's memory usage -- and about the seriousness with which memory usage issues are treated. Finally, if this turns out to be a Yahoo News bug, I'm sure that the Mozilla team's input would be helpful in getting Yahoo to fix it.
(In reply to q1 from comment #14) > Closing this bug now > would tend to reinforce a not-uncommon perception about Firefox's memory > usage -- and about the seriousness with which memory usage issues are > treated. Please read https://wiki.mozilla.org/Performance/MemShrink and all the posts at http://blog.mozilla.com/nnethercote/category/memshrink/. (You might like to count how many times Justin's name appears in the posts while you're at it.)
It's possible that both Chrome and Firefox have the same leak bug here, but it's pretty unlikely, since our architectures are completely different. We have lots of known memory issues and a limited amount of time, so if we think it's rather unlikely that this is a Firefox bug, I'm not going to invest a lot of time proving that fact, when we could be fixing known bugs instead. > Finally, if this turns out to be a Yahoo News bug, I'm sure that the Mozilla team's input > would be helpful in getting Yahoo to fix it. I'm honestly not sure they would care; it's not as though a normal user would click between those tabs more than a few times. The heap-unclassified issue is real, for sure. But would you mind filing that as a separate issue?
(In reply to Justin Lebar [:jlebar] from comment #16) > ...The heap-unclassified issue is real, for sure. But would you mind filing > that as a separate issue? The steps to reproduce it are exactly the same. I don't quite understand how it's a separate bug. Explain? BTW, I apologize for the after-em-dash dig in Comment 14. By way of explanation, I've been using Mozilla browsers since, I dunno, Seamonkey 1.0, and have been frustrated by the memory usage all along. I've never previously found a simple test case, so I let it lie until I happened across this one. I have, however, read Mozillazine forums for a long time, and have seen there a strong tendency to dismiss memory-leak bugs. Mozillazine forums is not you, however, hence my apology.
(In reply to Justin Lebar [:jlebar] from comment #16) > > Finally, if this turns out to be a Yahoo News bug, I'm sure that the Mozilla team's input > > would be helpful in getting Yahoo to fix it. > > I'm honestly not sure they would care; it's not as though a normal user > would click between those tabs more than a few times. The same leak appears if you login and click between the "My Comments" tag and the "All Comments" tag. This is the only fast way to refresh the list of your own comments; the only other way is F5, then clicking on "My Comments", which is much slower. So I think Yahoo might actually care about this bug.
The STR are the same, but the discussion is different. If we morphed this bug, someone just stepping in would have to read down to comment 10 just to understand what's a valid and what's an invalid issue. Whereas if we file a new bug, we can discuss just the heap-unclassified without all the rest of the noise.
(In reply to Justin Lebar [:jlebar] from comment #19) > The STR are the same, but the discussion is different. If we morphed this > bug, someone just stepping in would have to read down to comment 10 just to > understand what's a valid and what's an invalid issue. Whereas if we file a > new bug, we can discuss just the heap-unclassified without all the rest of > the noise. OK. I'll refile this as a new bug focussed on the heap-unclassified leak.
Thanks; please cc me on the new bug. I'm going to close this one, but if you direct any Yahoo people here, I'd be happy to discuss with them.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: