Last Comment Bug 790062 - rapid memory growth, over 2GB due to hwaccel
: rapid memory growth, over 2GB due to hwaccel
Status: RESOLVED INVALID
[MemShrink:P3]
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: 16 Branch
: x86_64 Windows 7
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-10 14:23 PDT by warhamma
Modified: 2012-11-03 07:06 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
FF troublshooting info (2.78 KB, text/plain)
2012-09-10 14:23 PDT, warhamma
no flags Details
about:compartments (17.75 KB, text/plain)
2012-09-11 10:55 PDT, warhamma
no flags Details
about:memory (9.83 KB, text/plain)
2012-09-11 10:56 PDT, warhamma
no flags Details
about:support - layers.acceleration.disabled=true (5.97 KB, text/plain)
2012-09-12 09:45 PDT, warhamma
no flags Details

Description warhamma 2012-09-10 14:23:56 PDT
Created attachment 659857 [details]
FF troublshooting info

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20100101 Firefox/16.0
Build ID: 20120904124322

Steps to reproduce:

casual browsing, any site, even with only one tab open. easy to reproduce when I go to 9gag.com and scroll down 10-20 posts there


Actual results:

FF's memory usage rapidly grows to 2GB and it starts to slow down and eventually crashes quite quickly. Happens ever since version 14, although it may have something to do with the installation of Shockwave Flash v11.4 r402 which happened around that time, but:
* I disabled all plug-ins (I don't have any other add-ons) and it didn't help.
* restarting in safe mode solves the problem (all plug-ins remained enabled), no rapid memory growth and memory remains at a low value, similarly to IE9.


Expected results:

FF should remain within reasonable memory consumption.
Comment 1 warhamma 2012-09-10 14:26:10 PDT
tried resetting FF through the troubleshooting screen - didn't help
Comment 2 Matthias Versen [:Matti] 2012-09-10 15:14:11 PDT
Can you please attach a copy of about:memory and about:compartments if you have that high memory consumption ?

Could you please also change javascript.options.methodjit.content to false and test if the issue is gone. That is something that the safemode does besides of disabling extensions. Don't forget to change it back to true after testing !

btw: Firefox is currently a 32bit process and a 32bit process can allocate only 2GB of memory. The crash is very likely a OOM crash (out of memory)
Comment 3 warhamma 2012-09-11 10:55:57 PDT
Created attachment 660157 [details]
about:compartments
Comment 4 warhamma 2012-09-11 10:56:34 PDT
Created attachment 660158 [details]
about:memory
Comment 5 warhamma 2012-09-11 11:00:26 PDT
set "javascript.options.methodjit.content" to false, restarted FF, same problem.
Comment 6 Matthias Versen [:Matti] 2012-09-11 11:22:08 PDT
Nicholas: Could you take a look at this. I don't understand why the resident memory is a 1.9gb
Comment 7 Nicholas Nethercote [:njn] 2012-09-11 16:32:36 PDT
From your about:memory:

   71.81 MB ── explicit
1,963.07 MB ── resident
3,968.38 MB ── vsize

That's *really* odd.  "explicit" and "resident" should be fairly close to each other.  "vsize" is excessive, too.

Can you visit about:config and change the "layers.acceleration.disabled" option to "true" by double-clicking on it, and then restart Firefox and see what happens?  We've seen hardware acceleration problems cause this kind of problem before and that's the only thing I can think of.
Comment 8 Justin Lebar (not reading bugmail) 2012-09-11 16:38:50 PDT
I think a key question is, why would safe-mode fix this problem?

Can you please attach the contents of your about:support both in and out of safe mode?
Comment 9 Matthias Versen [:Matti] 2012-09-11 16:49:04 PDT
>I think a key question is, why would safe-mode fix this problem?
The safemode disables the hardware acceleration and the assumption about the layers-acceleration from Nicholas makes sense.
I would have suggested this but it didn't know that hwa could cause memory issues.
Comment 10 Nicholas Nethercote [:njn] 2012-09-11 20:32:27 PDT
Bug 767337 is a prior case where hwaccel caused high memory consumption.
Comment 11 Nick Cameron [:nrc] 2012-09-11 20:39:18 PDT
(In reply to Nicholas Nethercote [:njn] from comment #10)
> Bug 767337 is a prior case where hwaccel caused high memory consumption.

We've only seen those problems on Intel graphics hardware, but it is not hard to imagine that similar problems could occur with some AMD drivers.

Are there any websites in particular that seem to cause this problem?
Comment 12 Matthias Versen [:Matti] 2012-09-12 04:20:07 PDT
>Are there any websites in particular that seem to cause this problem?
The reporter mentioned http://9gag.com in his comment.

Reporter:
Can you please post the graphic section from about:support here ?
Comment 13 warhamma 2012-09-12 09:44:41 PDT
I've set "layers.acceleration.disabled" to "true" and it indeed solved the problem.
The first attachment in this bug is actually the about:support with "layers.acceleration.disabled" set to "false".
Going to add the same with this setting on "true".
Maybe since I have 2 graphics cards in CrossfireX this causes the problem?
Comment 14 warhamma 2012-09-12 09:45:37 PDT
Created attachment 660486 [details]
about:support - layers.acceleration.disabled=true
Comment 15 warhamma 2012-09-12 09:58:26 PDT
So here's what I've done now: I've disabled CrossfireX for FF through the graphics drivers and the problem has been solved. The crazy memory growth does not happen anymore.
I don't know whether you're going to try and fix this bug or leave it as a "known bug" but I guess you should at least document it somewhere.
Comment 16 warhamma 2012-09-12 13:40:41 PDT
By the way, thank you for the quick responses and the professional handling of the issue so far.
Comment 17 Nicholas Nethercote [:njn] 2012-09-18 16:22:02 PDT
Nick, are you able to look further into this?  Should this driver be on the hwaccel blocklist?
Comment 18 Nick Cameron [:nrc] 2012-09-18 16:37:06 PDT
(In reply to Nicholas Nethercote [:njn] from comment #17)
> Nick, are you able to look further into this?  Should this driver be on the
> hwaccel blocklist?

Sorry, I don't have access to a machine with AMD graphics card, I couldn't recreate on my machine. We might want to block CrossfireX, since we block Optimus and it sounds like it is causing us problems.
Comment 19 Joe Drew (not getting mail) 2012-09-18 18:36:41 PDT
Bas, do you have access to a CrossfireX computer?
Comment 20 Matthias Versen [:Matti] 2012-09-27 08:09:15 PDT
Reporter: There is a new driver version available from AMD
http://support.amd.com/de/kbarticles/Pages/AMDCatalyst129betadriver.aspx
the list of fixes includey a fixed crossfire corruption with Firefox. Could you test this driver ?
Comment 21 Justin Lebar (not reading bugmail) 2012-09-27 09:15:12 PDT
Is there a bug to blocklist the old version of the driver?
Comment 22 Matthias Versen [:Matti] 2012-09-27 09:18:36 PDT
bug 792480 blocked one driver version
Comment 23 warhamma 2012-09-27 11:26:36 PDT
The new 1.29 Catalyst driver seems to have solved the problem. I've removed the special Firefox profile that I'd created in the old driver, made sure that CrossfireX was enabled and FF's HWAccel was enabled. No crazy memory growth.
Comment 24 Nicholas Nethercote [:njn] 2012-09-27 16:50:22 PDT
Great!  Can we close this now?
Comment 25 warhamma 2012-09-28 05:15:54 PDT
You can close it. Thanks, all!
Comment 26 Bas Schouten (:bas.schouten) 2012-09-28 05:27:55 PDT
(In reply to Joe Drew (:JOEDREW! \o/) from comment #19)
> Bas, do you have access to a CrossfireX computer?

I do not, we should get one somewhere though.
Comment 27 Danial Horton 2012-11-03 07:06:04 PDT
(In reply to Matthias Versen (Matti) from comment #2)
 
> btw: Firefox is currently a 32bit process and a 32bit process can allocate
> only 2GB of memory. The crash is very likely a OOM crash (out of memory)

Firefox is a 32bit process with Large Address Aware enabled.
It can use closer to 4GB on a 64bit operating system by default, and on a 32bit OS depends on the userva setting in bcedit or /3GB setting in Boot.ini

Note You need to log in before you can comment on or make changes to this bug.