Its been noted that beginning with the Nightly build 20130426182205 cset: 0e45f1b9521f that memory usage has nearly doubled. good: 20130426134304 cset: 34fabb5ccebf bad: 20130426182205 cset: 0e45f1b9521f My 'normal' memory usage averges around ~400-500meg, starting with the Nightly noted above its now running ~800meg or more, sometimes peaking 1gig if left open for several hours and browsing images. STR: 1. Open the browser 2. Open a new window (I've been testing with a PB window) 3. Open www.reddit.com/r/pics 4. look at several of the pics and watch the memory rise. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130426 Firefox/23.0 Posted using a build without the memory issue ^^ Seems its not addon related as I only use 3 addons, and have for years and have never noted any issues with memory use and these addons. Console2, Forecastfox, Flashblock.

https://areweslimyet.com/ doesn't show anything out of the ordinary. I don't think Flashblock is required in nightly anymore though. * About:addons * Plugins * "Ask to activate"

I'm also been experiencing this issue. I did some additional testing and I've found that disabling all add-ons and plugins has no impact on this whatsoever. However, disabling HWA or setting 'gfx.direct2d.disabled' to true in about:config seems to make it go away. This increase in memory consumption is not visible in about:memory measurements, except for: 1,012,924,416 B ── private 823,668,736 B ── resident 1,758,523,392 B ── vsize

For those experiencing this issue, try and narrow the regression window using the mozilla-inbound builds: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/ I can't help, because my graphics card is blacklisted, so I can't reproduce this.

I can confirm comment #2, turning 'off' HWA does eliminate the excessive memory issue. Any chance that https://bugzilla.mozilla.org/show_bug.cgi?id=865929 caused this problem. @IU, finding the right build to test on m-i is a total nightmare. I spend 45 mins digging through m-i builds and m-i tbpl and still couldn't find even the build with bug 865929 and a previous one to even begin testing. I do not understand how to use the mozilla regression tool. So we are still at the mercy of someone that can repo and find the range. :(

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #4) > @IU, finding the right build to test on m-i is a total nightmare. I spend > 45 mins digging through m-i builds and m-i tbpl and still couldn't find even > the build with bug 865929 and a previous one to even begin testing. You don't have to test every build. Just bisect it. You start with a build far enough back that the bug should not exist and a build far enough ahead that the bug should exist. Test those builds to confirm your hypothesis. If you are correct, you bisect (i.e. choose a build midway between those two) and test it to see if it has the regression. If it does, you bisect to an earlier build; if not, you bisect to a later build. You continue this process till you've found the culprit. This is a process that converges rapidly. For example, if you have 100 builds to test, bisection will give you the answer after testing only about 9 builds. For your case, you should probably bisect between the 23-Apr-2013 08:01 and 26-Apr-2013 23:02 mozilla-inbound builds.

And as Alice pointed out at forums.mozillazine.org, there's also birch: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/birch-win32/ joy

The range on inbound is: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7f68735fc8da&tochange=6255ed636db1 The last tinderbox build to not include any of those changesets is: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1366918756/ The first tinderbox build to include all of those changesets is: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1367006345/ So that gives you a range of 1366918756-1367006345 to bisect. I suggest sorting by name, since that gives the order in which the builds were triggered (if you sort by date you get the last time each directory was touched, which can vary a lot): http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/?C=N;O=D Oh, and in case you can only reproduce on PGO builds, the range there is 1366916714-1367009335 and the directory you want is: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32-pgo/?C=N;O=D

I've been trying to bisect the range, but it's pretty tough as sometimes it takes a while for memory usage to accumulate, making it hard to tell whether the bug is present. On a side note, I've noticed that killing dwm.exe, which is responsible for desktop composition (don't worry, Windows immediately launches another one), with Task Manager causes firefox.exe memory usage to drop back to more acceptable levels.

Can confirm both https://bugzilla.mozilla.org/show_bug.cgi?id=866648#c2 and https://bugzilla.mozilla.org/show_bug.cgi?id=866648#c8. Killing DWM immediately drops the memory to reasonable levels, and disabling HWA seems to have stopped the general increase in usage while running.

I suspect the problem is 859377. It caused other problems, and it's about painting and all this hard to understand things that affect memory and performance.

Seth: Given Ted's suspicion that bug 859377 may be the cause of OOM issues he's been seeing recently (bug 859377 comment 47), along with that being in the regression windows for this bug, could you please take a look at this. Thanks

I went to the tinderbox builds and I can confirm bug 859377 is the culprit here. https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=0ae79e3f9e6f&tochange=5a913ab3d2a5 GOOD https://hg.mozilla.org/integration/mozilla-inbound/rev/0ae79e3f9e6f http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1366930711/ BAD https://hg.mozilla.org/integration/mozilla-inbound/rev/5a913ab3d2a5 http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1366930855/

There was a band-aid patch for bug 857377 https://bugzilla.mozilla.org/show_bug.cgi?id=859377#c45 The respin in cset: https://hg.mozilla.org/mozilla-central/rev/4ff1e574e509 has the temp work-around for bug 857377 , and I can confirm using this build that the memory usage is back to 'normal for me'.

1,329.44 MB ── gfx-d2d-surfacevram in about:memory just before my last crash today.

Yes, this is indeed bug 859377. If there are no objections I'm just going to dupe it. The band-aid should take care of things for now; before the next uplift I will either produce a real fix or back this out.