828761 - Firefox consumes >150% CPU, won’t load websites

Status: RESOLVED DUPLICATE of bug 828632

(Firefox :: Untriaged, defect)

Description

[Mathias Schäfer]

Attachment: Screenshot of FF and Mac OS activity monitor

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.101 Safari/537.11

Steps to reproduce:

- Fresh install of Firefox 18
- Fresh profile (removed ~/Library/Application Support/Firefox completely)
- Start Firefox for the first time
- Don’t import anything from other browsers, don’t make default browser, don’t ask again…


Actual results:

- Firefox tries to load mozilla.org start page, but there’s no progress
- CPU usage quickly rises to >150%
- UI is still responsive, I can enter another URL, access the menu, open/close tabs and so on. But websites won’t load (empty page, Connecting…, Waiting for domain.tld…).



Expected results:

Load the websites normally, don’t consume so much CPU ;)

- This problem occurred right after the update to 18. I tried fresh install/fresh profile then, but the same.
- I didn’t have this problem with 17.
- A recent Firefox Nightly works fine: 21.0a1 (2013-01-09)

- I have a development stack with XCode and gdb installed and I can compile Firefox from source if that helps. Let me know how I can provide more info.

Comment 1

[(dormant account)]

Benoit, can you make a try build of 18 that Mathias can use with a profiler?

Comment 2

[Mathias Schäfer]

I’ve compiled from http://hg.mozilla.org/releases/mozilla-release and now have a debug-enabled build that shows the problem. (I’ve also compiled from mozilla-central to verify that the bug doesn’t show up in this branch.)
I’ve recorded a profile and memory allocations with Instruments from XCode, if that may help:
http://molily.de/assets/ff18.trace.tar.bz2
http://molily.de/assets/ff18-mem.trace.tar.bz2
I’ve also installed Benoit’s Profiler Addon. That’s a bit tricky since FF doesn’t open a web page so the profiler can’t upload any data…
Disclaimer: I’ve just an ordinary web dev that has no clue of debugging real applications, so tell me how I can provide useful data..

Comment 3

[Brendan Eich [:brendan]]

See also https://gist.github.com/4498203 from the reporter.

/be

Comment 4

[Steven Michaud [:smichaud] (Retired)]

> See also https://gist.github.com/4498203 from the reporter.

What's reported there is harmless, and can't be the cause of this bug.  It may be a symptom, though.

I haven't yet looked at the traces from comment #2.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Mathias, please try creating a new account on your Mac, and running FF 18 from there.

Comment 6

[Benoit Girard (:BenWa)]

(In reply to Taras Glek (:taras) from comment #1)
> Benoit, can you make a try build of 18 that Mathias can use with a profiler?

That wont be needed. The instrument profile will be sufficient. Mathias did you build with a particular mozconfig? If so can you tell me what options you used?

Look at the profile most of the work is coming from Apple System Log (ASL) / syslog. From our end a decent chunk is coming from nsOSXSystemProxySettings so that my be the suspect on our side.

Mathias can you check through all the logs from the 'Console' app and see if there's any spew?

Comment 7

[Benoit Girard (:BenWa)]

Also can you try the following:
1) Run firefox
2) Type the following in console to start LLDB (or use GDB if you're move comfortable with that):
lldb -n firefox
break set -n objc_autoreleaseNoPool
cont
3) When the breakpoint is hit type 'bt'
4) use 'cont'+'bt' a few types to get a few backtrace for the error.

Comment 8

[Mathias Schäfer]

(In reply to Steven Michaud from comment #5)
> Mathias, please try creating a new account on your Mac, and running FF 18
> from there.

New account ”firefoxtester“, same problem. Screenshot: http://img.ly/images/6597689/full

Comment 9

[Mathias Schäfer]

(In reply to Benoit Girard (:BenWa) from comment #6)
> (In reply to Taras Glek (:taras) from comment #1)
> Mathias did you build with a particular mozconfig?

For the Instruments profile I used a build with this .mozconfig boilerplate
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Mac_OS_X_Prerequisites#.C2.A04._Configure_source_tree_for_build_options

I later recompiled with ac_add_options --enable-profiling to try the profiler addon according to
https://developer.mozilla.org/en-US/docs/Performance/Profiling_with_the_Built-in_Profiler#Running_the_profiler
(Did’t know if this is included in --enable-debug, so I just rebuilt.)

> can you check through all the logs from the 'Console' app and see if
> there's any spew?

This is the whole output of a session of my local build:
http://molily.de/assets/ff18-session.txt.bz2

> Also can you try the following: …

Like this? http://molily.de/assets/ff18-lldb.txt

Comment 10

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #8)

Thanks for testing.

In comment #7 Benoit mentioned nsOSXSystemProxySettings.  Have you altered any of these settings, and if so did you set them for all users?

Comment 11

[Benoit Girard (:BenWa)]

(In reply to Mathias Schäfer from comment #9)
> (In reply to Benoit Girard (:BenWa) from comment #6)
> > (In reply to Taras Glek (:taras) from comment #1)
> > Mathias did you build with a particular mozconfig?
> 
> For the Instruments profile I used a build with this .mozconfig boilerplate
> https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/
> Mac_OS_X_Prerequisites#.C2.A04._Configure_source_tree_for_build_options

Alright next time if you profile you want 'disable-debug, enable-optimize, enable-profiling' otherwise the profile collected wont reflect true release performance.

> 
> I later recompiled with ac_add_options --enable-profiling to try the
> profiler addon according to
> https://developer.mozilla.org/en-US/docs/Performance/
> Profiling_with_the_Built-in_Profiler#Running_the_profiler
> (Did’t know if this is included in --enable-debug, so I just rebuilt.)
> 
> > can you check through all the logs from the 'Console' app and see if
> > there's any spew?
> 
> This is the whole output of a session of my local build:
> http://molily.de/assets/ff18-session.txt.bz2
> 
> > Also can you try the following: …
> 
> Like this? http://molily.de/assets/ff18-lldb.txt

The CC thread is running into an error that's prevent the breakpoint we're interested. I don't understand why we would see this error.

Comment 12

[Mathias Schäfer]

(In reply to Steven Michaud from comment #10)
> (In reply to comment #8)
> 
> In comment #7 Benoit mentioned nsOSXSystemProxySettings.  Have you altered
> any of these settings, and if so did you set them for all users?

Good catch! That’s the cause. Some Chrome plugin (“Proxy Switchy”) had set an automatic proxy configuration. (At least I cannot remember to have set this myself. o_O) It pointed to a SwitchyAuto.pac file in the Chrome plugin directory (file://Users/…). I’m not using this plugin any longer, so this file doesn’t seem to exist.

After removing this erroneous proxy config, the normal release build and my debug build work fine. :)

Don’t know if there’s still something to change in Firefox or if this bug can be marked as resolved. Thanks for your help anyway!

Comment 13

[(dormant account)]

Possible regression from recent proxy work? :(

Comment 15

[Andrew McCreight [:mccr8]]

I think the basic idea behind this assertion is that while the JS runtime is single threaded, due to CC thread hijinx the definition of what is the main thread varies depending on whether the CC is running or not.

When we're transitioning from the main thread to the CC thread, the main thread runs nsXPConnect::NotifyLeaveMainThread, then stops, then the CC thread starts and runs NotifyEnterCycleCollectionThread. For some reason, we're hitting an assert in the CC thread, saying we never ran the leave thread operation.

I'm not sure how you'd hit that assertion. Seems pretty bizarre. Maybe JS is running when it shouldn't be?

Comment 16

[Brendan Eich [:brendan]]

(In reply to Andrew McCreight [:mccr8] from comment #15)
> I'm not sure how you'd hit that assertion. Seems pretty bizarre. Maybe JS is
> running when it shouldn't be?

Proxy AutoConfig is involved. This seems worth investigating - please cc: me on any new bug.

/be

Comment 17

[Patrick McManus [:mcmanus]]

matthias - given that you say nightly-21 doesn't cause you this problem can you litmus test the try build being made in https://bugzilla.mozilla.org/show_bug.cgi?id=828632#c8 

That's 18 based plus some patches that didn't make it past 19 for release.

Comment 18

[Mathias Schäfer]

Unfortunately I can’t set up the problem again. After removing the .pac URL from the system network configuration, FF18 worked fine. I thought it was the missing .pac file that caused it, but when I add a file:/// URL that leads to a non-existing file, FF still works. Same with URLs that leads valid or invalid .pac files. Fresh profile, new account, restart, doesn’t change anything. The Chrome plugin the .pac file originated from doesn’t have this file any longer.