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 696871 - epiphany 3.8 hangs
epiphany 3.8 hangs
Status: RESOLVED DUPLICATE of bug 663919
Product: epiphany
Classification: Core
Component: Backend
3.8.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: Xan Lopez
Epiphany Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-03-29 20:16 UTC by Maciej (Matthew) Piechotka
Modified: 2013-08-24 10:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Maciej (Matthew) Piechotka 2013-03-29 20:16:43 UTC 
Epiphany 3.8 + webkit gtk 2.0 hangs (it happends twice today). It seems to deadlock as it does not consume resources (CPU and I/O idle systemwide). It did not happend with epiphany 3.7.92 + webkit 1.11.x:

+ Trace 231695

Thread 1 (Thread 0x7f0b1cfaf900 (LWP 7908))

  • #0 select
    at ../sysdeps/unix/syscall-template.S line 81
  • #1 g_spawn_sync
    at gspawn.c line 345
  • #2 WebKit::PluginProcessProxy::scanPlugin
    at Source/WebKit2/UIProcess/Plugins/unix/PluginProcessProxyUnix.cpp line 87
  • #3 WebKit::NetscapePluginModule::getPluginInfo
    at Source/WebKit2/Shared/Plugins/Netscape/x11/NetscapePluginModuleX11.cpp line 131
  • #4 WebKit::PluginInfoStore::loadPlugin
    at Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp line 106
  • #5 loadPluginsIfNecessary
    at Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp line 97
  • #6 WebKit::PluginInfoStore::loadPluginsIfNecessary
    at Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp line 74
  • #7 WebKit::PluginInfoStore::plugins
    at Source/WebKit2/UIProcess/Plugins/PluginInfoStore.cpp line 117
  • #8 WebKit::WebProcessProxy::getPlugins
    at Source/WebKit2/UIProcess/WebProcessProxy.cpp line 304
  • #9 callMemberFunction<WebKit::WebProcessProxy, void
  • #11 WebKit::WebProcessProxy::didReceiveSyncWebProcessProxyMessage
    at DerivedSources/WebKit2/WebProcessProxyMessageReceiver.cpp line 181
  • #12 CoreIPC::Connection::dispatchSyncMessage
    at Source/WebKit2/Platform/CoreIPC/Connection.cpp line 728
  • #13 CoreIPC::Connection::dispatchMessage
    at Source/WebKit2/Platform/CoreIPC/Connection.cpp line 778
  • #14 CoreIPC::Connection::SyncMessageState::dispatchMessages
    at Source/WebKit2/Platform/CoreIPC/Connection.cpp line 187
  • #15 operator()
    at ./Source/WTF/wtf/Functional.h line 704
  • #16 WebCore::RunLoop::performWork
    at Source/WebCore/platform/RunLoop.cpp line 91
  • #17 WebCore::RunLoop::queueWork
    at Source/WebCore/platform/gtk/RunLoopGtk.cpp line 104
  • #18 g_main_dispatch
    at gmain.c line 3054
  • #19 g_main_context_dispatch
    at gmain.c line 3630
  • #20 g_main_context_iterate
    at gmain.c line 3701
  • #21 g_main_context_iteration
    at gmain.c line 3762
  • #22 g_application_run
    at gapplication.c line 1623
  • #23 main
    at ephy-main.c line 472 

	Inferior 1 [process 7908] will be detached.

Quit anyway? (y or n) Detaching from program: /usr/bin/epiphany, process 7908

What triggers the bug: No idea. It happened when the window was in background/on other workspace. (Sorry for  stacktrace outside X but I had keyboard setup problems).
Comment 1 Maciej (Matthew) Piechotka 2013-04-16 11:25:30 UTC 
It happens usually during loggin in. Possibly timeout due to I/O?
Comment 2 Maciej (Matthew) Piechotka 2013-06-22 09:34:21 UTC 
(In reply to comment #1)
> It happens usually during loggin in. Possibly timeout due to I/O?

I can reproduce it every time during first run in a session. The time to start the browser after session starts or if it is first logging in after boot doesn't seems to matter.
Comment 3 Maciej (Matthew) Piechotka 2013-08-09 20:56:06 UTC 
(In reply to comment #2)
> (In reply to comment #1)
> > It happens usually during loggin in. Possibly timeout due to I/O?
> 
> I can reproduce it every time during first run in a session. The time to start
> the browser after session starts or if it is first logging in after boot
> doesn't seems to matter.

Hmm. It happens during first entry on heavy JS site such as Google+ every time when I open Web for the first time in session.
Comment 4 Maciej (Matthew) Piechotka 2013-08-24 10:22:28 UTC 

*** This bug has been marked as a duplicate of bug 663919 ***