Closed Bug 742420 Opened 14 years ago Closed 12 years ago

plugin-container eats 100% CPU on Nightly/OSX

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: gw280, Unassigned)

References

Details

Attachments

(1 file)

Instruments trace for plugin-container
471.58 KB, application/x-bzip2
Details
Running Nightly 14.0a1 (2012-04-03), I have plugin-container on my system munching its way through 100% CPU. Tabs open are: Facebook, CrackBerry, dailymile, Twitter.
Instruments trace for plugin-container
This doesn't mean much by itself. How does this compare with performance (loading the same page set) in earlier Firefox versions, in Safari and in Chrome? Is performance significantly different on different versions of OS X? Or with different versions of your plugins? As I hope and assume you're aware, plugin-container is the process that runs plugins. Each type of plugin gets its own plugin-container process. Poor performance in a plugin will translate into poor performance by its plugin-container process.
Finally, you need to give us STR for loading your page set (minimally which plugins to install and which pages to visit). And more detailed STR if just loading the various pages isn't enough (by itself) to reproduce the performance problems you report. Note that all the pages should be publicly accessible.
With the same page set, Safari is using <1% of the CPU. The only plugin that appears to be actively loaded is Flash. The plugin process itself is using <1% CPU. Not sure if perf is significantly different to different versions of OS X or Firefox, but the trace looks like all the plugin-container is doing is switching threads constantly.
I do not know how to reproduce, but I still have the nightly session open.
I saw this yesterday as well.
(In reply to comment #4) > The plugin process itself is using <1% CPU. What does this mean? The "plugin process" is plugin-container.
(Following up comment #7) Oops. Now I realize you're referring to the Safari plugin process.
(In reply to Steven Michaud from comment #8) > (Following up comment #7) > > Oops. Now I realize you're referring to the Safari plugin process. Yep, and also just realised that I have two plugin-container processes associated with Nightly; one has the process name of "Nightly Plugin Process (Shockwave Flash)" which is, like Safari, using < 1% of CPU, and the other has no name and is using 100% CPU.
There's no userspace calls at all in the instrumentation trace which is interesting. Attaching gdb and getting a backtrace shows the following: (gdb) bt #0 0x00007fff8a39936e in spin_lock$VARIANT$mp () #1 0x00000001038c4b15 in arena_malloc () Previous frame inner to this frame (gdb could not unwind past this frame)
(Unfortunately I'm not running a profiling build so that's all I can unwind)
> the other has no name and is using 100% CPU. Benoit, do you have any ideas about this? George, your stack frame isn't much use, and looks partially corrupt (at least for the main thread). Do you get useful information for the other threads (if you use "thread apply all bt")? If so please attach the trace (don't just paste it into a comment). > (Unfortunately I'm not running a profiling build so that's all I can unwind) On second thought, even "thread apply all bt" will probably contain lots of spurious symbols. Only attach the output if it looks useful.
The plugin-container process is single threaded
> There's no userspace calls at all in the instrumentation trace which is > interesting. That may be because the build you're using (not a profiling build) has its symbols stripped. > The plugin-container process is single threaded Oh, OK.
I've got George to run a nightly-profiling build where he will be able to unwind in debug. My best, purely speculative, theory is: Something somehow spawned a flash plugin instance by error. Said process blocks on waiting for firefox to setup IPC during the plugin process which will never happen. This would explain why the process doesn't get a name in Activity monitor which happens later during init. 100% usage is explained by use waiting on a spin lock.
Unfortunately this is not easy to reproduce. As soon as I can get the container process to spawn in the same way again I'll update this bug.
I've been seeing 100% CPU usage from Nightly at random in the past few days. Closing my newer tabs (those that might be related) doesn't seem to help. The nightly process must be force-quit and restarted to remove the problem.
Michael (and others who've seen this problem and want to comment here): What we really need is a reliable way to reproduce this problem, and detailed steps-to-reproduce to tell us how.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INVALID
Why is this flagged invalid? I am seeing exactly the same thing ever since I switched to nightly.
743678 is a different bug, as that’s not e10s-specific. I’ve never seen this in Firefox until I switched to nightly about half a month ago.
Because this is a general 'Something whent bad and I don't know what and I can no longer reproduce it'. If you experience a similar issue the root cause may be very different so please file a bug with as much information as you can provide.
I just noticed the original report was way back from 2012-04-03, and I’m running 2014-07-03, which means this bug has been present in e10s for the past 2 years... and closed as invalid even though it is still present and unfixed...
I just noticed the original report was way back from 2012-04-03, and I’m running 2014-07-03, which means this bug has been present in e10s for the past 2 years... and closed as invalid even though it is still present and unfixed...
Ambrose, this bug is not the bug you are looking for. This bug was an un-reproducible problem with NPAPI plugins from 2012. Your problem may be the same or may be entirely different, and should be filed separately.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: