715371 - Large spike in memory consumption on http://battlelog.battlefield.com/bf3/

Status: VERIFIED DUPLICATE of bug 634444

(Core :: General, defect)

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20111230 Firefox/12.0a1
Mozilla/5.0 (Windows NT 5.1; rv:9.0.1) Gecko/20100101 Firefox/9.0.1

There is a larger memory spike when opening http://battlelog.battlefield.com/bf3/user/test in a tab (I killed Firefox after it hang and Process Explorer showed more than 1,100,000 KB (9.0.1) or 700,000 KB (nightly) of private bytes for the process.

On weak systems like this one (1 GB RAM), Firefox should refuse such a huge request if it knows that this won't run (stable) if it's not a problem in Firefox rendering the page itself.

I don't know if this problem applies to other gaming sites, just noticed it when doing add-on reviews.

Comment 1

[Justin Lebar (not reading bugmail)]

That page is a 404 now.

Do you have any idea what was going on with this page?  If not, this bug is incomplete.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

This is a random user page:
http://battlelog.battlefield.com/bf3/user/dima20019/

Comment 3

[Nicholas Nethercote [inactive]]

> There is a larger memory spike when opening
> http://battlelog.battlefield.com/bf3/user/test in a tab (I killed Firefox
> after it hang and Process Explorer showed more than 1,100,000 KB (9.0.1) or
> 700,000 KB (nightly) of private bytes for the process.

That URL gives a "Sorry, that page doesn't exist" message.  Is there a particular user account that needs to be used or something?

Also, the high memory usage may be reasonable if it's a very complex web app.


> On weak systems like this one (1 GB RAM), Firefox should refuse such a huge
> request if it knows that this won't run (stable) if it's not a problem in
> Firefox rendering the page itself.

Determining whether Firefox will be stable is quite difficult.  We do have some bugs for adapting Firefox's behaviour in the face of low memory conditions:  bug 670967, bug 664291, bug 710501.  That's about as much as we can do in such cases.	Given that, do you still want this bug open?

 
> I don't know if this problem applies to other gaming sites, just noticed it
> when doing add-on reviews.

How are add-on reviews involved?

Comment 4

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Sorry for not mentioning, but this page was always a 404. I installed an OpenSearch search engine which simply added the search terms as the user name in the url.

@njn: What about (after the implementation of memory per tab) measuring the memory usage per tab and compare that to the machine's specifications, if it munches too much, replace it with an error page. Provide a button if the user still wants to load the page (and take his system to a halt for minutes).

If this is already being tracked somewhere, please close this bug (make duplicate?).

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

It spiked 1GB of allocations on a 404?

What extensions are you using?  What's exactly the reproduction sequence?  Does it do this with a fresh profile?  (firefox -profilemanager).  Could this OpenSearch engine be involved?

Opening that 404 URL on my browser uses virtually nothing (10ish MB it seems).

Comment 6

[Nicholas Nethercote [inactive]]

> @njn: What about (after the implementation of memory per tab) measuring the
> memory usage per tab and compare that to the machine's specifications, if it
> munches too much, replace it with an error page. Provide a button if the
> user still wants to load the page (and take his system to a halt for
> minutes).

The trouble with that is that measuring the memory usage per tab is expensive -- it touches every live byte on the JavaScript heap, among other things... if you're already low on memory that'll make things much worse.  It's fine to do that when the user loads about:memory, but we can't do it every time we open a new page.

I can't think of any other reasonable way to handle this kind of thing other than the aforementioned memory pressure events.  Therefore, are you happy if I close this bug?

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Identified the problem, it's the preference javascript.options.strict if it is set to true.

Steps to reproduce:
1. Create a new profile.
2. If asked if you want to make the browser your standard browser, choose 'No'.
3. Close the first tab.
4. In the second, open about:config.
5. Change javascript.options.strict to true.
6. Load http://battlelog.battlefield.com/bf3/user/test

Reproducible on Windows XP SP 3 32-bit with Firefox 9.0.1 and Mozilla/5.0 (Windows NT 5.1; rv:12.0a1) Gecko/20120111 Firefox/12.0a1

Comment 8

[Boris Zbarsky [:bzbarsky]]

Presumably you're getting tons of strict warnings?

Comment 10

[Nicholas Nethercote [inactive]]

Actually, bug 634444 is the original bug report.

Thanks for hunting this down, aryx!

Comment 11

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

bz: no idea, Firefox freezes and has to be killed.