Closed Bug 715371 Opened 8 years ago Closed 8 years ago

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

Categories

(Core :: General, defect)

12 Branch
x86
Windows XP
defect
Not set

Tracking

()

VERIFIED DUPLICATE of bug 634444

People

(Reporter: aryx, Unassigned)

References

()

Details

(Keywords: qawanted, Whiteboard: [MemShrink])

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.
Component: IPC → General
Keywords: qawanted
QA Contact: ipc → general
Whiteboard: [MemShrink]
That page is a 404 now.

Do you have any idea what was going on with this page?  If not, this bug is incomplete.
> 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?
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?).
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).
> @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?
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
Presumably you're getting tons of strict warnings?
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 653890
Actually, bug 634444 is the original bug report.

Thanks for hunting this down, aryx!
Duplicate of bug: 634444
bz: no idea, Firefox freezes and has to be killed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.