After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 706210 - Plugin process scans plugins each time a new tab is opened
Plugin process scans plugins each time a new tab is opened
Status: RESOLVED NOTGNOME
Product: epiphany
Classification: Core
Component: Backend
git master
Other Linux
: Normal normal
: ---
Assigned To: Xan Lopez
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-08-17 16:36 UTC by Claudio Saavedra
Modified: 2014-04-08 11:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Claudio Saavedra 2013-08-17 16:36:15 UTC 
I noticed ephy was freezing for a pretty long tme when starting a session with many tabs already open. Later, I noticed that during the freeze, many times I'd see the plugin process scanning, once an again, the same plugins.

Then I opened a new tab and ephy froze for a little bit. A buch of child processes are forked out of ephy. 

So I presume that what is happening here is that, on restoring a session with N tabs, we are scanning the M existing plugins N times. Given that the scanning API (as far as I remember) is synchronous, we lock for N*M calls to the plugin process.

We really need to fix this before 3.10. Not the synchronous nature of the scan, but the fact that each new tab causes ephy webkit to scan the plugins.
Comment 1 Claudio Saavedra 2013-08-17 16:44:04 UTC 
The stacktrace is not very helpful in finding out why this happens:

+ Trace 232390

  • #0 g_spawn_sync
    at gspawn.c line 255
  • #1 WebKit::PluginProcessProxy::scanPlugin(WTF::String const&, WebKit::RawPluginMetaData&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #2 WebKit::NetscapePluginModule::getPluginInfo(WTF::String const&, WebKit::PluginModuleInfo&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #3 WebKit::PluginInfoStore::loadPlugin(WTF::Vector<WebKit::PluginModuleInfo, 0ul, WTF::CrashOnOverflow>&, WTF::String const&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #4 WebKit::PluginInfoStore::loadPluginsIfNecessary()
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #5 WebKit::PluginInfoStore::plugins()
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #6 WebKit::WebProcessProxy::getPlugins(bool, WTF::Vector<WebCore::PluginInfo, 0ul, WTF::CrashOnOverflow>&, WTF::Vector<WebCore::PluginInfo, 0ul, WTF::CrashOnOverflow>&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #7 WebKit::WebProcessProxy::didReceiveSyncWebProcessProxyMessage(CoreIPC::Connection*, CoreIPC::MessageDecoder&, WTF::OwnPtr<CoreIPC::MessageEncoder>&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #8 CoreIPC::Connection::dispatchSyncMessage(CoreIPC::MessageDecoder&)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #9 CoreIPC::Connection::dispatchMessage(WTF::PassOwnPtr<CoreIPC::MessageDecoder>)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #10 CoreIPC::Connection::dispatchOneMessage()
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #11 WebCore::RunLoop::performWork()
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #12 WebCore::RunLoop::queueWork(WebCore::RunLoop*)
    from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.25
  • #13 g_idle_dispatch
  • #14 g_main_dispatch
    at gmain.c line 3065
  • #15 g_main_context_dispatch
    at gmain.c line 3641
  • #16 g_main_context_iterate
    at gmain.c line 3712
  • #17 g_main_context_iteration
    at gmain.c line 3773
  • #18 g_application_run
    at gapplication.c line 1635
  • #19 main
    at ephy-main.c line 489 






Comment 2


Claudio Saavedra





          2013-08-17 16:58:14 UTC
        



Okay, I think might happen when the plugin scan fails. In that case, every time information about plugins is needed, the web process asks for it again and again. The seemingly offending method:

void WebPlatformStrategies::populatePluginCache()
{
    if (m_pluginCacheIsPopulated)
        return;

    ASSERT(m_cachedPlugins.isEmpty());
    
    // FIXME: Should we do something in case of error here?
    if (!WebProcess::shared().parentProcessConnection()->sendSync(Messages::WebProcessProxy::GetPlugins(m_shouldRefreshPlugins), Messages::WebProcessProxy::GetPlugins::Reply(m_cachedPlugins, m_cachedApplicationPlugins), 0))
        return;

    m_shouldRefreshPlugins = false;
    m_pluginCacheIsPopulated = true;
}

In that case this is a WK bug.






Comment 3


Carlos Garcia Campos





          2014-04-08 11:01:57 UTC
        



WebKit now uses a plugin cache, so this is not a problem anymore