Closed Bug 620218 Opened 9 years ago Closed 9 years ago

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

Categories

(DevTools :: General, defect, critical)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 634444

People

(Reporter: whimboo, Unassigned)

References

()

Details

(Keywords: hang)

Attachments

(1 file)

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.
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.
Summary: Loading Google Chrome releases blog post hangs browser while using >1GB of additional memory → Loading a web page hangs browser (>1GB of additional memory usage) with Firebug and Mozmill installed
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.
Hi Henrik, please cc odvarko@gmail.com 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.
Depends on: 610793, 619749
(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
(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
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
(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?
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
Yes, at some places we are using the nsIConsoleService service to log messages (logStringMessage), but that's all as far as I can find.
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
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
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.
> 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.
(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
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
(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.
I can reproduce it without Mozmill now. Thanks Nils. Updating summary. What's the best component for this bug?
OS: Mac OS X → All
Hardware: x86 → All
Summary: Loading a web page hangs browser (>1GB of additional memory usage) with Firebug and Mozmill installed → Loading a web page hangs browser (>1GB of additional memory usage) with Firebug installed and js strict warnings enabled
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.
Summary: Loading a web page hangs browser (>1GB of additional memory usage) with Firebug installed and js strict warnings enabled → Loading a web page hangs browser (>1GB of additional memory usage) when javascript.options.strict enabled and any console service is attached
Blocks: 624408
No longer blocks: 624408
Duplicate of this bug: 624408
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".
Component: General → Developer Tools
QA Contact: general → developer.tools
(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.
FWIW, we are no longer setting javascript.options.strict in our next version of mozmill.
I'm marking this as a dup of bug 634444, even though this bug existed earlier, because the discussion in that bug is clearer.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 634444
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.