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.
Created attachment 285010 [details] Additionally applied patch
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 ***
(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.
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.
The bt looks like an infinite loop in RenderBlock::paintChildren(). Do you remember which website you were visiting when this happened?
(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.