Closed Bug 430573 Opened 12 years ago Closed 9 years ago

lolcats website makes firefox use 1GB+ of RAM due to iframe recursion

Categories

(Core :: General, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: sspitzer, Assigned: sicking)

References

()

Details

(Keywords: memory-footprint, Whiteboard: [MemShrink])

Attachments

(4 files)

lolcats website makes firefox use 1GB+ of RAM, at least if you believe the Windows Task Manager "Mem Usage" column

I'm using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042305 Minefield/3.0pre

I don't see this in IE 7.

Could it be that there are recursive iframes?  (See attached screen shot from DOMi)

Let me attach a few screen shots.

see also bug #420986
Product: Firefox → Core
QA Contact: general → general
Confirmed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042407 Minefield/3.0pre.  Memory slowly grows.  Continually hits google's adservicing among others.
IE7 doesn't have this, as it shows adds as well.

note, "I has a bucket" is working:  

http://icanhascheezburger.files.wordpress.com/2007/01/2001982351398543517_rs.jpg

(Sorry, couldn't resist)
Confirmed using Windows Vista

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042407 Minefield/3.0pre
same problem on an older build, so it doesn't look like we recently regressed this

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040100 Minefield/3.0pre ID:2008040100
It's really interesting b/c if you go to the site and keep the error console open notice that it has multiple entries for MineWidget not being defined and then after a few seconds the errors all disappear, very strange!
Could this be another regression from bug 402982. That bug landed early march.
Blocks: 402982
This just brought my Mac to its knees by slurping down more than 2G of memory.  Requesting blocking, since this is a pretty evil failure mode.
Flags: blocking1.9?
Keywords: footprint
I tried in Debian's Firefox (Iceweasel really) 2.0.0.12

[Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.8.1.12) Gecko/20080129
Iceweasel/2.0.0.12 (Debian-2.0.0.12-1)]

with a fresh profile, and I got the same behaviour so the problem seems pretty
old. The problem doesn't show with Javascript disabled. A friend with
Kazehakase (powered with Mozilla 1.8.0.9 according to the about box, so this is
really old) has the same problem:

[Mozilla/5.0 (X11; Linux x86_64; U;) Gecko/0 Kazehakase/0.4.3 Debian/0.4.3-1]
I really think we should block on at least figuring out what's going on here. If iframe recursion prevention has broken that will probably cause more sites to break in similar ways.
Assignee: nobody → jonas
Flags: blocking1.9? → blocking1.9+
Attached image what may be happening
The bug doesn't appear if adblock plus blocks the following javascript:
http://partner.googleadservices.com/gampad/google_service.js
Just to clarify, there are two issues going on here:

One is that for some reason the page is generating recursive iframes instead of ads. These are all JS injected. That's why disabling JS or using Adblock prevents the problem. Don't know why this happens, but it could be a bug with the site's (or Google's) code.

The other is that when such iframes are created -- whatever the reason -- we should be taking measures to prevent excessive resource consumption. It sounds like that's not happening for some reason.
So what seems to be happening here is epic fail on the part of lolcats.

http://icanhascheezburger.com/ when loaded with my tip build (which doesn't support flash) will produce a page with 5 <iframe>s, all of them pointing to various urls within http://partner.googleadservices.com/.

However each load for those urls will result in a redirect to http://icanhascheezburger.com/wp-content/themes/icanhascheezburger/google_adsense_script.html

This is a 404 page that largely looks like http://icanhascheezburger.com/, i.e. it will contain (only 4 this time) <iframe>s pointing at http://partner.googleadservices.com/

So basically lolcats creates infinite <iframe> recursion.

We do have 2 lines of defense to protect against this type of recursion. For one we generally refuse to nest more than 10 levels deep. However since each level here contains 4 iframes that still creates a whole lot of iframes (~4^9 > 1/4 million)

Second, we refuse to load a url if there is a parent frame with the same url. However this doesn't work here since the initial url is always a http://partner.googleadservices.com/, so we don't detect the recursion. We don't check for recursion on redirect.


There might be additional defenses going on here which I haven't found, since clearly we're not able to load .25 million lolcat pages. It's possible that we have a limit on the total number of frames per tab somewhere


Why this happens only for FF3 I don't know. Possibly because I don't have flash installed on my tip builds. This doesn't happen for me with my default profile where flash is installed.


Either we could simply evangelize here since clearly lolcats shouldn't be creating infinite frame recursion. Or we could detect recursion on redirect which would fix this too.
Actually, I do have flash installed on that build, so not sure why i'm getting iframes...
We don't do any recursion protection other than the 10-deep and no loading the same URI checks.  I have no idea why this isn't loading 4^9 or so frames, except for the fact that I'd expect the loads to happen slower and slower (with the browser frozen more and more) as we keep GCing and such...

Note bug 305524; fixing that might allow us to usefully check for redirects, I suspect.
Duplicate of this bug: 431954
It might be interesting to figure out exactly when this regressed.  Might give us more of an idea as to why it suddenly broke...
What exactly regressed?  I get recursive frames with a current branch build, SeaMonkey 1.0.1 and Mozilla 1.7.
Ah, somehow I'd gotten the impression that this is a trunk regression.  If it's not, I'm going to stop worrying about it.  ;)
Given comment 24 and comment 25 I'm taking this off the blocking list.
Flags: blocking1.9+ → blocking1.9-
Hai guize,

This is Cheez from I Can Has Cheezburger.

This file:
http://icanhascheezburger.com/wp-content/themes/icanhascheezburger/google_adsense_script.html
is supposed to collapse the ad space if no ad is shown by Google.

I am going to update this so that it is just a flat HTML file with no script.

I'd like to see what happens if I make this change.

Thanks for letting us know about this problem.
Are we sure this is specific to the lolcats site?  Did anyone get back with Cheez, about comment #27?  The reason I ask is that other wordpress-based pages with comments have large memory usage and slow scrolling issues, as has been reported in Bug 433469.
No, the bug isn't specific to the lolcats site. We do need to fix how we implement frame recursion prevention.
(In reply to comment #29)
> No, the bug isn't specific to the lolcats site. We do need to fix how we
> implement frame recursion prevention.
> 

What about bug 420986
(In reply to comment #30) 
> What about bug 420986
> 

Not related, that's a tech-evangelism bug about the change of the userAgent string + (maybe) about getElementById changes. This is about frame recursion, which anyhow shouldn't occur on this site anymore as per comment #27.
Summary: lolcats website makes firefox use 1GB+ of RAM → lolcats website makes firefox use 1GB+ of RAM due to iframe recursion
Duplicate of this bug: 431968
Duplicate of this bug: 490205
Flags: wanted1.9.2?
Flags: wanted1.9.2?
The testcase now uses less memory, so I think we can mark this as WORKSFORME.
Adding to MemShrink.
Whiteboard: [MemShrink]
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.