Closed Bug 1059775 Opened 7 years ago Closed 7 years ago

[e10s] plugin-container process running without Firefox at 100%

Categories

(Core :: DOM: Content Processes, defect, P3)

32 Branch
x86_64
All
defect

Tracking

()

RESOLVED WORKSFORME
Tracking Status
e10s m4+ ---

People

(Reporter: whimboo, Assigned: jimm)

References

Details

Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20140827030202 CSet: 0753f7b93ab7

I started to run tests for Nightly with e10s enabled. So today I have seen a strange plugin-container process running without any active nightly build:
     
$ ps -ef | grep 22188
henrik   22188  1965 99 12:33 ?        02:52:04 /mozilla/bin/nightly/plugin-container -greomni /mozilla/bin/nightly/omni.ja -appomni /mozilla/bin/nightly/browser/omni.ja -appdir /mozilla/bin/nightly/browser 22117 true tab

$ ps -ef | grep firefox
henrik   15042  1965  7 Aug24 ?        07:37:43 /mozilla/bin/aurora/firefox

$ ps -ef | grep 1965
henrik    1965  1956  0 Aug24 ?        00:00:28 init --user

top with 100% cpu load:
22188 henrik    20   0 1015940 353000  47704 R 100.4  2.2 171:56.74 Web Content                                                                                 

I started this Firefox process via the unity dock by clicking on the Nightly icon. Not sure if there was an unexpected shutdown or so, but this plugin-container process kept running and taking up 100% cpu load all the time.
Summary: plugin-container process running without Firefox at 100% → [e10s] plugin-container process running without Firefox at 100%
This has nothing at all to do with plugins.
Component: Plug-ins → DOM: Content Processes
I'm not sure whether this is interesting yet until the basic plugin work (like the content processes sharing one plugin process via the main process) is actually done - johns?
Flags: needinfo?(jschoenick)
nvm
Flags: needinfo?(jschoenick)
Assignee: nobody → jmathies
Blocks: old-e10s-m2
Priority: -- → P3
Using e10s for about 24 hours now on windows and slightly similar experience, in that plugin-container.exe gets to 100% and memory grows to 1+GB, *but* Firefox is running. As best I can tell it only happens after session restore using Session Manager addon. I'm OK, firefox.exe and plugin-container.exe are steady state and nominal until session is restored. Some time after session restore firefox.exe goes from say 1GB down to 400MB but plugin-container.exe grows from 300MB to 1+GB, and CPU loops at about 1.5-1.7GB.
Move old M2 P3 bugs to M4 (because tracking-e10s=m5+ flag doesn't exist yet).
No longer blocks: old-e10s-m2
Depends on: e10s-plugin-ipc
Duplicate of this bug: 1091635
OS: Linux → All
(In reply to Wayne Mery (:wsmwk) from comment #4)
> Using e10s for about 24 hours now on windows and slightly similar
> experience, in that plugin-container.exe gets to 100% and memory grows to
> 1+GB, *but* Firefox is running. As best I can tell it only happens after
> session restore using Session Manager addon. I'm OK, firefox.exe and
> plugin-container.exe are steady state and nominal until session is restored.
> Some time after session restore firefox.exe goes from say 1GB down to 400MB
> but plugin-container.exe grows from 300MB to 1+GB, and CPU loops at about
> 1.5-1.7GB.

Hey Wayne, curious how your experience is these days with e10s?
Flags: needinfo?(vseerror)
I've not had sufficient experience lately.  I didn't enable it for a long time, until recently but then it became it was disabled as a result of blocked graphics driver for direct2d.  irrc that requirement was recently removed, correct?
Flags: needinfo?(jmathies)
Yes that was changed in bug 1089008, which landed this weekend.
Flags: needinfo?(jmathies)
Flags: needinfo?(vseerror)
I'm going to close this out since we haven't had any reports post all the plugin landings over the last month or so. If anyone runs into this again please reopen.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.