WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
REOPENED
160402
[GTK] WebProcess from WebKitGtk+ 2.13.4 stalls my whole desktop
https://bugs.webkit.org/show_bug.cgi?id=160402
Summary
[GTK] WebProcess from WebKitGtk+ 2.13.4 stalls my whole desktop
Andres Gomez Garcia
Reported
2016-08-01 06:34:03 PDT
Created
attachment 285009
[details]
BT from gdb I'm using WebKitGtk+ with my own JHBuild setting:
https://github.com/tanty/jhbuild-epiphany/tree/master
Epiphany 3.20.3 and WebKit 2.13.4 with one additional patch. I'm running Epiphany with the dconf key: "process-model" = "shared-secondary-process" The compilation was done with CMake args: '-DPORT=GTK -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_FLAGS_RELEASE="-O0 -g1 -DNDEBUG -DG_DISABLE_CAST_CHECKS" -DCMAKE_CXX_FLAGS_RELEASE="-O0 -g1 -DNDEBUG -DG_DISABLE_CAST_CHECKS"' After visiting several pages, eventually, the whole desktop hangs, presumably, because of the WebProcess The kernel keeps being responsive and the "ping" command, more or less, responds but, for example, I'm unable to ssh in from another machine. After suffering the same problem several times, I was able to get a BT by launching ephy and the webprocess from SSHed session and attaching gdb. While the desktop being completely stalled, still I was able to make reach a Ctrl+C in the GDB of the WebProcess. That made the machine responsive again but my X session was completely torn down. This bug is not reproducible in a predictable way.
Attachments
BT from gdb
(75.65 KB, text/plain)
2016-08-01 06:34 PDT
,
Andres Gomez Garcia
no flags
Details
Additionally applied patch
(996 bytes, patch)
2016-08-01 06:34 PDT
,
Andres Gomez Garcia
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Andres Gomez Garcia
Comment 1
2016-08-01 06:34:38 PDT
Created
attachment 285010
[details]
Additionally applied patch
Michael Catanzaro
Comment 2
2016-08-01 07:01:53 PDT
It's probably
bug #126122
; let's assume so until proven otherwise. The relevant change is that every page uses AC mode now, so we can expect it to happen way more often that before. *** This bug has been marked as a duplicate of
bug 126122
***
Andres Gomez Garcia
Comment 3
2016-08-01 07:29:24 PDT
(In reply to
comment #2
)
> It's probably
bug #126122
; let's assume so until proven otherwise. The > relevant change is that every page uses AC mode now, so we can expect it to > happen way more often that before. > > *** This bug has been marked as a duplicate of
bug 126122
***
I really don't think this is the same bug, if I'm understanding it correctly. The hang doesn't come because of an excessive use of the memory, the memory doesn't grow, as far as I can see. Checking the BT, it seems like an interlocking problem. I recommend reopening, unless you find a more suitable DUPLICATED.
Carlos Garcia Campos
Comment 4
2016-08-01 07:41:56 PDT
No, the tiled backing store used by coordinated graphics already limits the tiles to the visible area. The switch to threaded compositor fixed
bug #126122
, that should still be left open until we remove the option to build without the threaded compositor. This must be a different issue.
Carlos Garcia Campos
Comment 5
2016-08-01 22:53:41 PDT
The bt looks like an infinite loop in RenderBlock::paintChildren(). Do you remember which website you were visiting when this happened?
Andres Gomez Garcia
Comment 6
2016-08-02 02:24:11 PDT
(In reply to
comment #5
)
> The bt looks like an infinite loop in RenderBlock::paintChildren(). Do you > remember which website you were visiting when this happened?
No, I'm sorry, but it was visiting all the tabs in my saved session to force the load of all of them. I can pass you the session file if you want.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug