Last Comment Bug 746644 - Massive memory leak when opening web page (thegeekstuff.com) and 'javascript.options.strict' enabled
: Massive memory leak when opening web page (thegeekstuff.com) and 'javascript....
Status: RESOLVED FIXED
[MemShrink:P3]
: hang, mlk, regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: 12 Branch
: All All
: -- critical with 1 vote (vote)
: mozilla16
Assigned To: general
:
Mentors:
http://www.thegeekstuff.com
Depends on: 634444
Blocks: 675221
  Show dependency treegraph
 
Reported: 2012-04-18 10:29 PDT by Henrik Skupin (:whimboo)
Modified: 2012-08-21 11:19 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
-
affected
-
affected
-
affected


Attachments

Description Henrik Skupin (:whimboo) 2012-04-18 10:29:48 PDT
There is a massive memory leak in Firefox starting with Firefox 12 when opening the following web page while 'javascript.options.strict' is enabled. In case of Windows it will freeze your machine in a couple of seconds so you are forced to do a restart. On OS X I got about 2.5GB of memory usage out of my 8GB.

Steps:
1. Enable 'javascript.options.strict' in about:config
2. Open http://www.thegeekstuff.com/2010/06/vmware-esxi-installation-guide/

Given that I have a kinda bad internet connection, would someone else mind to test for a regression range? Once we have two builds I can do a hg bisect.
Comment 1 Henrik Skupin (:whimboo) 2012-04-18 10:34:16 PDT
Actually it happens for all the pages on this domain.
Comment 2 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 10:37:38 PDT
Are you sure it's a regression?

Also, are you sure it's a leak as opposed to "tons of warnings generated, each one taking up a lot of space"?
Comment 3 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 10:38:27 PDT
And iirc we have existing bugs on what happens when a large script that's all on one line generates lots of warnings (each warning containing the entire script as the line of code the warning is on).
Comment 4 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-18 10:42:08 PDT
FWIW, I can reproduce this in Firefox 11 as well, but it recovers after a few seconds. In Firefox 12b6 it never seems to recover.
Comment 5 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 10:45:44 PDT
Do 11 and 12 generate the same sets of warnings on this page?
Comment 6 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-18 10:48:23 PDT
Further testing:
 * Firefox 11 recovers after a few seconds
 * Firefox 12b1 never recovers

Will now check Nightly from between 11 and 12.

(In reply to Boris Zbarsky (:bz) from comment #5)
> Do 11 and 12 generate the same sets of warnings on this page?

I'm not seeing any warnings on either build, just spiking memory. In Firefox 11 it spikes to about 200MB, in Firefox 12 about 800MB.
Comment 7 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 10:50:11 PDT
Well, the memory is spiking because strict mode generates warnings to the console.....
Comment 8 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-18 10:51:33 PDT
Ah, I'm not running this in a console...I'm running it native (like a user). Let me check...
Comment 9 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-18 10:53:03 PDT
(In reply to Boris Zbarsky (:bz) from comment #7)
> Well, the memory is spiking because strict mode generates warnings to the
> console.....

Maybe I'm not doing it right...tried starting it from a terminal window on Windows 7 and I still get no warnings.
Comment 10 Henrik Skupin (:whimboo) 2012-04-18 10:57:37 PDT
(In reply to Boris Zbarsky (:bz) from comment #2)
> Are you sure it's a regression?

Yes, it is. It's something new which started with Firefox 12 as mentioned above. Compared to Anthony I cannot reproduce it on 11 even my release was on 10 before (when I have filed this bug)

> Also, are you sure it's a leak as opposed to "tons of warnings generated,
> each one taking up a lot of space"?

I know about this bug. I have filed it a long time ago. But this seems to be unrelated to it and is really new. I will try to narrow it down. It can take a bit for me due to the slow connection.
Comment 11 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 11:10:08 PDT
I meant the web console, no the OS console....

Henrik, on your Mac where you can reproduce the bug, what warnings do you see?  How do those compare to a 10 or 11 Mac build?
Comment 12 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-18 11:11:55 PDT
Speaking to the memory spike, the regression range is in Firefox 12.0a1 2012-01-12.

Firefox 12.0a1 2012-01-11: 200MB usage when loading URL
Firefox 12.0a1 2012-01-12: 800MB usage when loading URL
Comment 13 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-18 11:13:35 PDT
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #12)
> Speaking to the memory spike, the regression range is in Firefox 12.0a1
> 2012-01-12.
> 
> Firefox 12.0a1 2012-01-11: 200MB usage when loading URL
> Firefox 12.0a1 2012-01-12: 800MB usage when loading URL

Additionally, Firefox 12.0a1 2012-01-12 generated a crash after hanging for a minute:
http://crash-stats.mozilla.com/report/index/bp-ae10c506-7135-45de-9cb5-530ec2120418
Comment 14 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 11:14:37 PDT
Anthony, what are the changeset IDs for those builds?
Comment 15 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-18 11:16:28 PDT
(In reply to Boris Zbarsky (:bz) from comment #14)
> Anthony, what are the changeset IDs for those builds?

Firefox 12.0a1 2012-01-12 built from http://hg.mozilla.org/mozilla-central/rev/8ffdb4c7404a
Comment 16 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2012-04-18 11:18:24 PDT
Regression range please - you could tell the last good changeset and first bad changeset
Comment 17 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 11:19:58 PDT
> Firefox 12.0a1 2012-01-12 built from http://hg.mozilla.org/mozilla-central/rev/8ffdb4c7404a

And the other?
Comment 18 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-04-18 11:21:46 PDT
(In reply to Olli Pettay [:smaug] from comment #16)
> Regression range please - you could tell the last good changeset and first
> bad changeset

What specifically are you looking for? I've already commented the 24 hour window. Again, it is

Last Good: Firefox 12.0a1 20120111 http://hg.mozilla.org/mozilla-central/rev/e79ef0ffcb09
First Bad: Firefox 12.0a1 20120112 http://hg.mozilla.org/mozilla-central/rev/8ffdb4c7404a
Comment 19 Henrik Skupin (:whimboo) 2012-04-18 11:23:28 PDT
So I did a testrun with Nightly and checked the output in Instruments. As it looks like we are allocated a huge amount of 500k blocks in under a seconds. 

488k blocks -> 5.3GB
244k blocks -> 1.33GB
508k blocks -> 2.76GB

I haven't used this tool yet so I'm probably not the right one to analyze the data.
Comment 21 Henrik Skupin (:whimboo) 2012-04-18 11:28:19 PDT
Just to add to my Instruments investigation, all seem to happen inside nsAString_internal.
Comment 22 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 11:31:27 PDT
> I've already commented the 24 hour window.

Builds can happen at different times, so in general given two build dates what one has is a 48-hour window.  What Olli and I were looking for was the two changeset IDs, because that gives the exact set of changes that happened between the two builds, as in comment 20.  Sorry that wasn't clear...

Unfortunately, nothing in there is jumping out at me.  The XPCOM proxy changes changed the console service a little bit, but shouldn't have affected memory use that way.....
Comment 23 Henrik Skupin (:whimboo) 2012-04-18 11:33:27 PDT
Just to let you all know, I will start bisecting now.
Comment 24 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 11:40:02 PDT
The string allocations are expected, though the blocks size is a bit large.  The largest line length I see in scripts linked to directly by the site is about 25000 characters, which would translate to 50KB string allocations per warning.  But of course there are lots of scripts being loaded here indirectly...
Comment 25 Alex Keybl [:akeybl] 2012-04-18 12:55:49 PDT
Before tracking this for FF12's release, is there any reason javascript.options.strict would ever be enabled by default?
Comment 26 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 13:02:35 PDT
No, though some sufficiently-broken extensions might flip that pref...
Comment 27 Alex Keybl [:akeybl] 2012-04-18 15:07:59 PDT
(In reply to Boris Zbarsky (:bz) from comment #26)
> No, though some sufficiently-broken extensions might flip that pref...

Given that, I don't see a need to track for release.
Comment 28 Henrik Skupin (:whimboo) 2012-04-18 15:56:53 PDT
The first bad revision is:
changeset:   84179:4d03df4a60dc
user:        Benjamin Smedberg <benjamin@smedbergs.us>
date:        Wed Jan 11 11:28:21 2012 -0500
summary:     Bug 675221 part A: replace XPCOM proxies with runanble for code in XPCOM itself, r=bz
Comment 29 Henrik Skupin (:whimboo) 2012-04-18 15:58:01 PDT
Also wanted to add the link to the causing changeset:
http://hg.mozilla.org/mozilla-central/rev/4d03df4a60dc
Comment 30 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 16:30:19 PDT
Huh.  So the console service changes after all.

I wonder if we used to just sync-notify the listeners as each warning came in, and then drop the warning on the floor (unless the console is open, in which case it would hold on to the warning) whereas now we post a message to the main thread to notify the listeners async and so can end up with tons of warning messages in memory at once...
Comment 31 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 16:30:53 PDT
But again, the fundamental issue is that each message has a huge "line it happened on" string...
Comment 32 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 16:31:27 PDT
That said, once the messages are delivered on the main thread, I'd expect the memory to be freed.  If it's not, that's somewhat troubling.
Comment 33 Nicholas Nethercote [:njn] (on vacation until July 11) 2012-04-18 17:03:51 PDT
This smells an awful lot like bug 634444, except that predates Firefox 12.
Comment 34 Boris Zbarsky [:bz] (Out June 25-July 6) 2012-04-18 17:07:27 PDT
I think this bug is about a situation where all those strings end up in memory at once when they didn't use to before Firefox 12.  But the reason the strings are big is bug 634444.
Comment 35 Nicholas Nethercote [:njn] (on vacation until July 11) 2012-07-09 17:42:41 PDT
With bug 634444 fixed, is this still a problem?  I just tried to reproduce and couldn't.
Comment 36 Henrik Skupin (:whimboo) 2012-07-10 00:25:05 PDT
Works great now with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/16.0 Firefox/16.0
Comment 37 brian 2012-08-21 11:13:05 PDT
Still present in FF 14.0.1 (14.0.1+build1-0ubuntu0.11.10.3) and eventually takes down the browser.
Comment 38 Olli Pettay [:smaug] (high review load, please consider other reviewers) 2012-08-21 11:16:05 PDT
Target Milestone: --- → mozilla16
Comment 39 Ryan VanderMeulen [:RyanVM] 2012-08-21 11:17:18 PDT
(In reply to Olli Pettay [:smaug] from comment #38)
> Target Milestone: --- → mozilla16

Brian - If you would like to confirm that this is fixed, you can try out a build on the Aurora channel, which is what will eventually ship as Firefox 16.
Comment 40 brian 2012-08-21 11:19:28 PDT
(In reply to Olli Pettay [:smaug] from comment #38)
> Target Milestone: --- → mozilla16

Ack! Missed that. Sorry for the noise.

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