620218 - Loading a web page hangs browser (>1GB of additional memory usage) when javascript.options.strict enabled and any console service is attached

Status: RESOLVED DUPLICATE of bug 634444

(DevTools :: General, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b9pre) Gecko/20101217 Firefox/4.0b9pre ID:20101217030324

Seen this today while reading some posts on the Google Chrome Releases blog. Loading the page given in the URL field uses about 1GB of memory (that's the remaining physical memory on my box) and hang the browser for about 15 seconds.

Looks like it is related to some Javascript code, which get run on this site. Disabling JS solves this issue.

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

This issue can be seen with Firebug v1.7 and Mozmill installed within a profile. Follow this steps in a fresh profile to reproduce the hang and memory usage as given in comment 0:

1. Install the latest version of Firebug: http://getfirebug.com/releases/firebug/1.7X/
2. Install the latest alpha version of Firebug 1.7
3. Install Mozmill: https://addons.mozilla.org/en/firefox/addon/9018/
4. Restart the browser
5. Load the URL

After step 5 you will notice the hang and high memory usage.

Comment 2

[Chris Boerger]

I've noticed over 1GB of memory allocated to Minefield recently. I do not have the Mozmill extension installed but I do have the latest Firebug 1.7.x extension and use a very javascript-heavy website.

Comment 3

[John J. Barton]

Hi Henrik, please cc [e-mail] on Firebug issues, thanks.

We can't do any work on JS debug for now on FF4.0, it's just broken we have to wait.

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to comment #2)
> I've noticed over 1GB of memory allocated to Minefield recently. I do not have
> the Mozmill extension installed but I do have the latest Firebug 1.7.x
> extension and use a very javascript-heavy website.
We need a separate test case (perhaps separate bug) for this one, it looks like a different problem (if problem at all, of course in case of heavy pages, the memory consumption grows, even if >1GB sounds too much to me)


(In reply to comment #1)
> After step 5 you will notice the hang and high memory usage.
I can reproduce the problem only if both Firebug and Mozmill are installed. The problem occurs even if Firebug is entirely disabled (including interception of network responses). The memory is consumed during page load and dropped just after the page is loaded.

So, my guess is that there is a collision between these two extensions. However so far, I don't have any ideas what could be wrong on the Firebug side.

Is Mozmill somehow inspecting/exploring the chrome space?

Clint, is there anything Mozmill does during page load?

Honza

Comment 5

[Chris Boerger]

(In reply to comment #4)
> So, my guess is that there is a collision between these two extensions.
I don't think you should limit your bug hunt to this scenario. I have never installed the Mozmill extension yet I have experienced the >1GB memory footprint. The problem also manifested itself after a nightly build update (which one I do not recall) not after a Firebug update - meaning I had been using the current version of Firebug prior to the large memory footprint issue.

Hope that helps.

Chris

Comment 6

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Do you have a specific steps-to-reproduce (something like you can see in Comment #1) that I could follow to reproduce the problem on my machine?
Honza

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to comment #4)
> Is Mozmill somehow inspecting/exploring the chrome space?

We check for load, DOMContentLoaded, and beforeunload events. That's everything. See: https://github.com/mozautomation/mozmill/blob/hotfix-1.5.2/mozmill/mozmill/extension/resource/modules/init.js#L58

Jan, even with Firebug disabled, are there still some components, which are active?

Comment 8

[Jan Honza Odvarko [:Honza] (always need-info? me)]

So, after some time debugging the debugger I noticed that the problem is somehow related to the nsIConsoleService.

If Firebug registers a listener to it, the problem appears. Note that just the registration itself causes the problem. Even if the observer method (called when an error happens) is empty the problem is there.

Does Mozmill touches the nsIConsoleService?

Honza

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Yes, at some places we are using the nsIConsoleService service to log messages (logStringMessage), but that's all as far as I can find.

Comment 10

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Attachment: Test extension for bug reproduction

I am attaching a test extension that does nothing but registering a console listener.

Please, repeat steps from comment #1 and use this extension instead of Firebug. The bug is clearly reproducible. If you disable Mozmill, the problem is gone.

The next step: can you take a look at Mozmill code and step by step find the place which causes the problem? It looks to me as a platform bug, but somebody should check Mozmill first.

Honza

Comment 11

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Boris, I know it could be a problem with Mozmill, but asking in advance if you have any ideas about what could be wrong...

Honza

Comment 12

[Nils Maier [:nmaier]]

In short: You set javascript.options.strict, which spams nsIConsoleService and it's listeners.

LogMessage is called some 7325 times during page load with strict mode turned on but only 31 times when it is off.
You can observe this behavior with any (js) console listener, e.g. WebConsole or ErrorConsole if strict mode is turned on (no need to install mozmill).
Strict mode makes http://www.blogger.com/static/v1/widgets/512629240-widgets.js blogger script spit out an enormous amount of deprecation warnings (e.g. octal literals and octal escape sequences are deprecated).
This isn't that bad if no listener is around to consume this, but there is still a higher CPU load observable, and some short freezing.
Once a listener is around, marshaling between js and c++ land is performed I guess, which causes the high memory consumption. If the listener happens to  display the messages (*Console), this will result in a long freeze of the application.

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Once a listener is around, marshaling between js and c++ land is performed I
> guess, which causes the high memory consumption.

Possibly, but more likely the listener is just holding to all the messages.

Comment 14

[Nils Maier [:nmaier]]

(In reply to comment #13)
> > Once a listener is around, marshaling between js and c++ land is performed I
> > guess, which causes the high memory consumption.
> 
> Possibly, but more likely the listener is just holding to all the messages.

The only candidate would be the HUDServiceObserver from HUDService.jsm (WebConsole). That thing is lazily-loaded and hence doesn't attach a listener until you actually open the WebConsole. So there is no other listener holding messages.

The debugger verifies this:
javascript.options.strict=true.

There are no listeners, as of snapshotCount[1], when run in a clean profile and the memory consumption is by far lower; also there are less short freezes.

Add the test extension from attachment #1 [details] [diff] [review] that adds an listener with an empty observe body, i.e. not holding or even touching messages, and the listener count (snapshotCount) goes accordingly to 1 and you can observe the memory peek.

[1] http://mxr.mozilla.org/mozilla-central/source/xpcom/base/nsConsoleService.cpp#172

Comment 15

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Rob, Kevin, I have cc-ed you since HUD is now involved in this bug and you could have some more ideas what is wrong.

One thing I don't understand why the bug is only reproducible when Mozmill is installed. Is somebody willing to check Mozmill?

Honza

Comment 16

[Nils Maier [:nmaier]]

(In reply to comment #15)
> Rob, Kevin, I have cc-ed you since HUD is now involved in this bug and you
> could have some more ideas what is wrong.

To repeat: it is NOT caused by the HUD. The HUD observer isn't registered until you open the HUD UI the first time. HUD was merely a candidate in my investigation, but I ruled it out.

> One thing I don't understand why the bug is only reproducible when Mozmill is
> installed. Is somebody willing to check Mozmill?

It is not. You don't have to install mozmill. And it's not even mozmill code that triggers this, it's just that mozmill toggles javascript.options.strict.

Alternative steps to reproduce without mozmill:
* Clean profile
* Set javascript.options.strict to true
* Either install the test extension from attachment #1 [details] [diff] [review], or open the ErrorConsole or WebConsole and load the URL.

The culprit is javascript.options.strict causing a massive storm of strict/deprecation warnings in conjunction with any console listener (even a no-op listener). 7325 messages instead of 31 for the example URL.
Opening Error/WebConsole, however, will additionally freeze your browser for a long period of time as both consoles have problems dealing with the message storm. The no-op listener from attachment #1 [details] [diff] [review] just causes slight freezes and the high memory consumption.

So you can trigger this in clean profile without any extensions, just by setting that pref to true and opening any of the two built-in consoles and loading an affected URL.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I can reproduce it without Mozmill now. Thanks Nils. Updating summary. What's the best component for this bug?

Comment 18

[John J. Barton]

I further updated the summary since Firebug is not involved here.

Since trunk has support for the vastly superior 'use strict and since jslint is freely and widely available, javascript.options.strict should either be deleted or it should DEBUG builds only. This misfeature has cause me a lot of grief in the past.

Comment 20

[Rob Campbell [:rc] (:robcee)]

There is probably some performance analysis and tuning we can do with the Web Console so we're not bogging down under the onslaught of these messages. I'll move it to devtools.

For Firebug, you may want to open an issue around "7000+ strict warnings makes the console slow".

Comment 21

[John J. Barton]

(In reply to comment #20)
> For Firebug, you may want to open an issue around "7000+ strict warnings makes
> the console slow".

Just based on trying FF4.0b9pre for a few days, it definitely feels like logging is significantly slower than on FF3.6. I have no idea why.

Comment 22

[cmtalbert]

FWIW, we are no longer setting javascript.options.strict in our next version of mozmill.

Comment 23

[Nicholas Nethercote [inactive]]

I'm marking this as a dup of bug 634444, even though this bug existed earlier, because the discussion in that bug is clearer.