1067510 - iframe javascript memory leak

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Jordan Blumenthal]

Attachment: debug_1.jpg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36

Steps to reproduce:

Many embedded iframes eventually slow Firefox to a crawl.  I'm thinking this is a javascript engine/garbage collection issue.

Use case:

1) Visit: http://www-stage.wongdoody.com/mangles
2) Click on any of the words in the clouds.
3) Laugh at hilarious video(s)
4) Repeat about 12-20 times (dependent on RAM)
5) Eventually FF performance significantly degrades to the point where the program becomes unresponsive





Actual results:

This can be viewed here:

http://www-stage.wongdoody.com/mangles

Click through about 12-16 (depending on RAM) and see what happens, after awhile performance slows down and eventually you get the "script is unrespsonsive" error window.

This is not happening on any other browsers, it's specific to Firefox and is confirmed to be happening on all versions and OS we tested on.  

My post on stackoverflow for more detailed explanation:

http://stackoverflow.com/questions/25816657/firefox-javascript-and-iframe-performance-with-jquery



Expected results:

Ideally, embedding any number of iframes would trigger js garbage collection, but that does not seem to be happening.

Comment 1

[Boris Zbarsky [:bzbarsky]]

I can't reproduce the problem in a current nightly (on Mac, though).  Memory usage is stable as I watch the videos, and in particular when a video ends memory usage drops to the level it was at before the video started.

Jordan, do you see the problem in safe mode?

Comment 2

[Jordan Blumenthal]

Unfortunately I do see the problem, even in safe mode.  And I can confirm this is still happening in Safe Mode, on Windows 7 at least.  I know the issue was happening across multiple OS including OSX.  Perhaps the issue was cleared up on a nightly build?

Thanks.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Jordan, what exact Firefox version are you using?  I just tried the Firefox 32 release (still on Mac) and I still don't see the sort of issue you describe....

When you get this problem, what does about:memory have to say?

Comment 4

[Jordan Blumenthal]

I'm also using Firefox 32 release. 

Here's what I'm getting:

  377.05 MB ── private
  393.37 MB ── resident
  784.43 MB ── vsize
1,805.94 MB ── vsize-max-contiguous


190.05 MB (100.0%) -- js-main-runtime

If you want I can export the full memory measurement.  Physical memory isn't showing huge issues, but javascript performance is really, really poor after a certain # of clicks.  I'm using jQuery javascript library.

Comment 5

[Jordan Blumenthal]

It might not be a memory leak then, and something that I'm doing that's causing problems for the JS engine.

Comment 6

[Jordan Blumenthal]

Marking this as invalid, it's an issue with firefox and vimeo js embeds which are causing performance issues.  Confirmed not a memory leak.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Jordan, I have yet to reproduce the sort of slow script dialog, or any particular performance issue on that site in Firefox 32 (still on Mac, in case that matters).  If you have reliable steps to reproduce, they would be very much appreciated.

Comment 8

[Jordan Blumenthal]

Unfortunately I can confirm this is still happening on multiple machines, all on 32.0 and 32.0.1, but now I'm interested as to why the error cannot be replicated.  All of our test cases happen on Windows, so perhaps that may point us to the cause of the issue?

Here are the steps I used to replicate this morning:

visit:

http://www-stage.wongdoody.com/mangles

Click through 20 or so of the mangle items (wingdaddy, wandduty, etc)

Eventually after going through a bunch of them (literally, 20+), you should see decreased performance.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Just to be clear:  Are you clicking through some of those items more than once?  Because I only see 14 items there...

Comment 10

[Jordan Blumenthal]

Yep, that's the idea.  We were testing what would happen if we added 20+ and we found this weird slowdown issue.

Comment 11

[Jordan Blumenthal]

Also if you have someone with a windows box running 32.0 that may help, most of our test cases are on windows.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Alice0775, are you able to reproduce this?

Comment 13

[Alice0775 White]

(In reply to Boris Zbarsky [:bz] from comment #12)
> Alice0775, are you able to reproduce this?

I can reproduce the high CPU usage and unrespsonsive script dialog after 15-20 times(click word and watch video).

https://hg.mozilla.org/releases/mozilla-release/rev/1727a19db430
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140911151253

Comment 14

[Alice0775 White]

Unrespsonsive script dialog says:

Script: http://ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.min.js:3

Comment 15

[Alice0775 White]

In Google Chrome37, video player would not launch when I click a word after I repeat the step more than 20 times.

So, I think this is the site problem.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Jordan, it might help to have the site use unminified scripts in terms of figuring out what's going on here.

Comment 17

[Jordan Blumenthal]

This is confirmed as my error, jQuery wasn't wiping away the bindings, so on each call the event handlers were piling up.  Sorry to waste your time, my apologies.

Comment 18

[Jordan Blumenthal]

This is confirmed as my error, jQuery wasn't wiping away the bindings, so on each call the event handlers were piling up.  Sorry to waste your time, my apologies.