642629 - Sometimes FF4 jumps to 100% CPU with panel open and it is tried to be closed/tab changed

Status: RESOLVED FIXED

(Cloud Services :: Share: Firefox Client, defect)

Description

[James Burke]

There seems to be a case that involves the share panel where the CPU spikes when trying to close the panel at some point. A bit hard to reproduce, but a few people have seen it.

So, first step is to try reproduce, then do some logging of what is going on: is it share-specific or a general panel use issue in Firefox 4?

Comment 1

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: trace from OS X instruments thread service

Comment 2

[Philipp von Weitershausen [:philikon]]

Comment on attachment 520349 [details]
trace from OS X instruments thread service

Bryan was able to observe the problem reproducibly, so we looked at the threads in Apple Instruments. Between 0:25 and 1:18, the UI was pretty much deadlocked, the native event loop was not spun.

Comment 3

[Philipp von Weitershausen [:philikon]]

How Bryan was able to reproduce this well:

1. Start out in tab A
2. Go to tab B and invoke the F1 sharing panel
3. Try to go to tab A. Observe Firefox locking up.

If you can't reproduce immediately, exchange tab A for B.

Comment 4

[Richard Newman [:rnewman]]

I could only repro Philipp's steps with lots of tabs open (many of them empty).

Watching with Instruments, I managed to get stalls for a couple of seconds when switching tabs. The stall was co-incident with incoming network traffic and a precipitous drop in memory consumption mid-way through a spike -- a GC, to you and me.

http://twinql.com/jpg/f1.png

My first guess would be that some activity involved in creating the panel, or some work done when switching tabs (updating the panel to the new page?), creates a ton of garbage. The stall you're seeing is GC.

I will now see if I can get CPU to spike when closing the panel.

Comment 5

[Richard Newman [:rnewman]]

Got some spiking when closing tabs, but managed to crash Instruments, so no more pretty graphs :D

Looks like F1 does a _lot_ of work for something that puts a little box on the screen. Philipp, you might get interesting results if you run against your JS allocation tracking patch, with verbose GC logging.

Instruments is a pretty blunt tool for figuring out what's going on; your log output should have a much better chance of confirming or denying my hypothesis.

Comment 6

[Bryan Clark (DevTools PM) [:clarkbw]]

Starting to see more comments about this issue: http://feedback.mozillalabs.com/forums/107731-mozilla-f1/suggestions/1625151-f1-causes-cpu-to-hit-100-utilization

Any progress on debugging?

Comment 7

[Philipp von Weitershausen [:philikon]]

Not yet. So far we've only observed this in OS X, right? It wouldn't surprise me if this is an OS X platform bug. If we can confirm this, we should create a minimal reproducible test case and rope in some OS X hackers.

Comment 8

[Johan Larsson]

I'm seeing this problem as well and this is how Im able to reproduce it:

1. Invoke the F1 sharing panel in any tab
2. Watch the cpu-utilization graph soar and wait for about 40s until it calms down.

I'm using F1 0.8.2 in FF4 Final on OS X 10.6.6.

Comment 10

[:gerard-majax]

As reported in 645543, it also happens under Linux/amd64. Sometimes it works, sometimes it fails. I'm also using Mozilla F1 0.8.2, but it's been a while, maybe since a couple of 0.7 releases, that it has this behavior.

Comment 11

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: debug build trace from OS X instruments thread service

I keep hitting this bug so I tried to reproduce it on the debug build.  This is a trace of the freeze up happening on the latest try server builds using the debug build.

At 06 - 11 seconds is when the freeze occurs.  On the debug builds the freeze does not hang as long as on a regular build (of course!)

STR:
1) open up server tabs (~20)
2) at least 2 or 3 should have actual web content pages
3) open F1 on the web content pages
4) switch tabs back and forth between various tabs
5) freezing occurs after switching through all the tabs 3 times or so

Comment 12

[:gerard-majax]

I wonder wether it might be linked to the thumbnail. I just noticed that when it uses so much CPU, just after the popup opens, the title of the page you're sharing is good, but the thumbnail is the one from the previous sharing.

Comment 13

[Shane Caraveo (:mixedpuppy)]

some memory dumps on issues I think may be related....

1. at one point we changed the panel to close immediately after a share.  to get error results, we post the result back to chrome which stores that result on the tab object.  It is then posted back to the web content so the web content can update.

2. sometime after that change, I started hearing about 2 problems.  cpu usage or freezing/lockup and an issue with hundreds of bookmarks being added per single share.  

The bookmark issue indicates some kind of loop gone out of control, which I think would cause the cpu usage.  The postmessage back and forth of the share result could be a potential source of that loop.  

3. jrburke has a suspicion that we are not removing a message handler that we install on web content, and that it is getting called more than once after the first share.  If so, this could also be a cause of the multiple bookmark issue.

I'll look at this again and see if there is a potential for this to be the cause.

Comment 14

[Kumar McMillan [:kumar]]

This happened to me when I tried to share this slide deck on Twitter:
https://docs.google.com/present/view?id=df9sn445_206ff3kn9gs&pli=1

I don't know if it's reproducible and I don't really want to try because I had to force quit Firefox 4 last time :(  Good luck.

Comment 15

[Shane Caraveo (:mixedpuppy)]

This bug is likely caused by bug 646598, but I do not yet have proof of that.

Comment 16

[Aru Sahni]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

Running F1 v0.8.2.  Sometimes (usually after my browser session has been active for several hours), the sharing panel appearing causes my CPU utilization (on a dual core system) to hit %50 and stay there.  Sometimes, I've been successful in dismissing the panel, but, more often than not, I have to manually kill the process.

Comment 17

[Shane Caraveo (:mixedpuppy)]

so far, it is looking like bug 646598 fixed this issue, we'll look at pushing a hotfix for the existing addon.

Comment 18

[Bryan Clark (DevTools PM) [:clarkbw]]

A new version of the F1 add-on is out, please update if you're using the add-on and experiencing this problem.  You may have to restart after updating to clear up the problem (even though the add-on doesn't require a restart).

Comment 19

[Shane Caraveo (:mixedpuppy)]

We have not heard new reports of this issue, and those people I have direct contact with that had the problem no longer experience it.  I believe this is resolved by bug 646598.