Hello. With the upgrade to webkit2gtk 2.18 (now using version 2.18.2), there are many webpages that can crash the web process (verified in Epiphany). This webpage in particular will crash the web process in Epiphany: https://www.harrypotterplatform934.com/pages/faqs Just wait 30 seconds and scroll down a bit (I don't know what triggers the bug, but I always get the crash). Thanks to fix this issue.
Hi, you need to post a backtrace when reporting crashes if you want us to investigate. That page works fine for me.
Well, I can post it, but I don't have the debug symbols, so it's useless. Here it is: Thread 1 "WebKitWebProces" received signal SIGSEGV, Segmentation fault. 0x00007fbf0dc8f507 in ?? () from /usr/lib/libwebkit2gtk-4.0.so.37 (gdb) bt #0 0x00007fbf0dc8f507 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #1 0x00007fbf0dc90eb6 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #2 0x00007fbf0dc90f26 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #3 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #4 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #5 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #6 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #7 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #8 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #9 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #10 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #11 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #12 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #13 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #14 0x00007fbf0dc90f50 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #15 0x00007fbf0d0ce4b3 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #16 0x00007fbf0d0d3075 in () at /usr/lib/libwebkit2gtk-4.0.so.37 #17 0x00007fbf0d0d359b in () at /usr/lib/libwebkit2gtk-4.0.so.37 #18 0x00007fbf09674b14 in WTF::RunLoop::performWork() () at /usr/lib/libjavascriptcoregtk-4.0.so.18 #19 0x00007fbf096ad3fa in () at /usr/lib/libjavascriptcoregtk-4.0.so.18 #20 0x00007fbf09b6d0be in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0 #21 0x00007fbf09b6ef69 in () at /usr/lib/libglib-2.0.so.0 #22 0x00007fbf09b6ff42 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0 #23 0x00007fbf096ade5a in WTF::RunLoop::run() () at /usr/lib/libjavascriptcoregtk-4.0.so.18 #24 0x00007fbf0d0dd0ab in WebProcessMainUnix () at /usr/lib/libwebkit2gtk-4.0.so.37 #25 0x00007fbf0c0b0f6a in __libc_start_main () at /usr/lib/libc.so.6 #26 0x000055d2159b689a in _start ()
You're right, it's useless. You'll obviously need to install debug symbols if you want us to be able to investigate the crash.
Hey Anthony, I can't reproduce this crash either here (2.18.2 and SVN trunk). When I start scrolling a subscribe banner appears on top of the page and always remains visible. Maybe that's what triggers the crash for you. Can you report this downstream to the ArchLinux folks? It would be interesting to know if other ArchLinux users are also affected by this issue.
That's a waste of time; it's clearly a WebKit bug, not an Arch bug. But anyway, without a backtrace, there's nothing to do here, sorry.
(In reply to Michael Catanzaro from comment #5) > That's a waste of time; it's clearly a WebKit bug, not an Arch bug. Until proven otherwise, you don't know what it is. I didn't say it is an Arch bug. I advised to report this downstream, which is different.
AFAIK there are mainly two things that can cause crashes on "many webpages" 1) Broken GPU drivers Please try to start the browser with AC disabled, to do that export this variable before executing the browser from the terminal export WEBKIT_DISABLE_COMPOSITING_MODE=1 2) JSC JIT on a not well supported platform Are you maybe using a 32-bit platform? Try to disable the JIT at run-time by exporting this on a terminal before starting the browser: export JavaScriptCoreUseJIT=0 Let us know if any of this two workarounds helps.
The crash is in /usr/lib/libwebkit2gtk-4.0.so.37... that does not prove, but strongly suggests that it's a WebKit bug. It would be extremely unusual for such a crash to not be a WebKit bug. (It also suggests that this is probably not a JIT bug, but no harm in trying that environment variable anyway.) I can all but guarantee that the only response to a downstream bug report would be "please report upstream." On the Arch bugtracker specifically, but also on pretty much every other distribution's bugtracker. So I would not recommend reporting it anywhere else. The best path forward here would be to post a quality backtrace, then we can reopen the bug and maybe take a look.
Here's the backtrace: #0 0x00007f11dfb0d6d7 in WebCore::CoordinatedGraphicsLayer::transformedVisibleRect() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:890 #1 0x00007f11dfb0ed29 in WebCore::CoordinatedGraphicsLayer::updateContentBuffers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:968 #2 0x00007f11dfb0edb3 in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:940 #3 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #4 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #5 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #6 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #7 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #8 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #9 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #10 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #11 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #12 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #13 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #14 0x00007f11dfb0eddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #15 0x00007f11df097507 in WebKit::CompositingCoordinator::flushPendingLayerChanges() () at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CompositingCoordinator.cpp:123 #16 0x00007f11df09c0eb in WebKit::CoordinatedLayerTreeHost::layerFlushTimerFired() () at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:204 #17 0x00007f11df09c2d8 in WebKit::CoordinatedLayerTreeHost::renderNextFrame() () at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:178 #18 0x00007f11dc923550 in WTF::RunLoop::performWork() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #19 0x00007f11dc923550 in WTF::RunLoop::performWork() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/RunLoop.cpp:106 #20 0x00007f11dc94be09 in _FUN() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:68 #21 0x00007f11dc94be09 in _FUN() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:70 #22 0x00007f11d7e972da in g_main_context_dispatch (context=0x5eb800) at gmain.c:3148 #23 0x00007f11d7e972da in g_main_context_dispatch (context=context@entry=0x5eb800) at gmain.c:3813 #24 0x00007f11d7e97698 in g_main_context_iterate (context=0x5eb800, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3886 #25 0x00007f11d7e979c2 in g_main_loop_run (loop=0x83f6b0) at gmain.c:4082 #26 0x00007f11dc94c810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #27 0x00007f11df0a5859 in WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) () at /run/build-runtime/webkitgtk4/Source/WebKit/Shared/unix/ChildProcessMain.h:61 #28 0x0000003753a20291 in __libc_start_main (main= 0x400bd0 <main()>, argc=2, argv=0x7ffeb27bb388, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffeb27bb378) at /usr/src/debug/glibc/2.24-r0/git/csu/libc-start.c:289 #29 0x0000000000400c5a in _start () at ../sysdeps/x86_64/start.S:120
Thanks. Even better if you could get a backtrace with 'bt full'.
"thread apply all bt full" even better. Check: https://trac.webkit.org/wiki/WebKitGTK/Debugging#Gettingabacktracefromacoredump
Here's the complete backtrace: Thread 27 (Thread 0x7f50f244d700 (LWP 181)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50f418d700, timeout=<optimized out>, context=0x7f50f4003e30) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50f418d700 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f50f4003e30, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50f418d700 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50f4303c70) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f50f244d700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f50f244d700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139985638708992, -1270168254981307517, 140723383535518, 140723383535519, 139985638708992, 139985667780544, 1224574728515912579, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 26 (Thread 0x7f50d1dff700 (LWP 175)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50c4001330, timeout=<optimized out>, context=0x7f50c40008c0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50c4001330 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f50c40008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50c4001330 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50c4001200) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f50d1dff700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f50d1dff700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139985095227136, -1270168254981307517, 140723383543806, 140723383543807, 0, 237624242240, 1224652597346730883, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 25 (Thread 0x7f50d43ff700 (LWP 166)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50cc001330, timeout=<optimized out>, context=0x7f50cc0008c0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50cc001330 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f50cc0008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50cc001330 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50cc001200) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f50d43ff700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f50d43ff700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139985135073024, -1270168254981307517, 140723383543806, 140723383543807, 0, 237624242240, 1224658919538590595, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 24 (Thread 0x7f50f1c4c700 (LWP 130)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=2, fds=0x7f50e8001340, timeout=<optimized out>, context=0x7f50e8001200) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 2 allocated_nfds = 2 fds = 0x7f50e8001340 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f50e8001200, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 2 allocated_nfds = 2 fds = 0x7f50e8001340 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50e80010c0) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f50f1c4c700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f50f1c4c700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139985630316288, -1270168254981307517, 140723383543198, 140723383543199, 139985630316288, 139985667780944, 1224582427781661571, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 22 (Thread 0x7f510943b700 (LWP 119)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50e4001670, timeout=<optimized out>, context=0x7f50e40013b0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50e4001670 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f50e40013b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50e4001670 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50e4001540) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f510943b700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f510943b700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139986024511232, -1270168254981307517, 140723383543646, 140723383543647, 139986024511232, 18543392, 1224247051502257027, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 21 (Thread 0x7f50f144b700 (LWP 118)): #0 0x000000375420d498 in pthread_cond_timedwait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x00007f516bf6136a in WTF::ThreadCondition::timedWait(WTF::Mutex&, double) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:587 #2 0x00007f516bf36c13 in WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ParkingLot.cpp:598 #3 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ParkingLot.h:85 #4 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Condition.h:81 #5 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Condition.h:121 #6 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/AutomaticThread.cpp:207 #7 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #9 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #10 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #11 0x0000003754207404 in start_thread (arg=0x7f50f144b700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f50f144b700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139985621923584, -1270168254981307517, 140723383542126, 140723383542127, 139985621923584, 139985667781344, 1224581328806904707, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #12 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 20 (Thread 0x7f50da7fc700 (LWP 113)): #0 0x000000375420d498 in pthread_cond_timedwait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x00007f516bf6136a in WTF::ThreadCondition::timedWait(WTF::Mutex&, double) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:587 #2 0x00007f516bf36c13 in WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ParkingLot.cpp:598 #3 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ParkingLot.h:85 #4 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Condition.h:81 #5 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Condition.h:121 #6 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/AutomaticThread.cpp:207 #7 0x00007f516bf27066 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #9 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #10 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #11 0x0000003754207404 in start_thread (arg=0x7f50da7fc700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f50da7fc700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139985239918336, -1270168254981307517, 140723383542670, 140723383542671, 0, 237624242240, 1224627585067811715, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #12 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 11 (Thread 0x7f50f3fff700 (LWP 43)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=2, fds=0x7f50ec001330, timeout=<optimized out>, context=0x7f50ec0008c0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 2 allocated_nfds = 2 fds = 0x7f50ec001330 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f50ec0008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 2 allocated_nfds = 2 fds = 0x7f50ec001330 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50ec001200) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f50f3fff700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f50f3fff700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139985667749632, -1270168254981307517, 140723383548190, 140723383548191, 0, 237624242240, 1224578105433949059, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 10 (Thread 0x7f5108c3a700 (LWP 40)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50f80010c0, timeout=<optimized out>, context=0x11a6320) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50f80010c0 #2 0x00007f51674ad626 in g_main_context_iterate (context=context@entry=0x11a6320, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50f80010c0 #3 0x00007f51674ad74c in g_main_context_iteration (context=context@entry=0x11a6320, may_block=may_block@entry=1) at gmain.c:3947 retval = <optimized out> #4 0x00007f5158d3f0cd in dconf_gdbus_worker_thread (user_data=0x11a6320) at dconf-gdbus-thread.c:82 context = 0x11a6320 #5 0x00007f51674d54f5 in g_thread_proxy (data=0x11cda80) at gthread.c:784 thread = 0x11cda80 #6 0x0000003754207404 in start_thread (arg=0x7f5108c3a700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f5108c3a700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139986016118528, -1270168254981307517, 140723383546942, 140723383546943, 0, 237624242240, 1224245950380016515, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #7 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 8 (Thread 0x7f510affb700 (LWP 38)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=2, fds=0x7f5100001730, timeout=<optimized out>, context=0x7f51000008c0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 2 allocated_nfds = 2 fds = 0x7f5100001730 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f51000008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 2 allocated_nfds = 2 fds = 0x7f5100001730 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f5100001600) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f510affb700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f510affb700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139986053609216, -1270168254981307517, 140723383549646, 140723383549647, 0, 237624242240, 1224241657023333251, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 7 (Thread 0x7f510b7fc700 (LWP 37)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f50fc001730, timeout=<optimized out>, context=0x7f50fc0008c0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50fc001730 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f50fc0008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f50fc001730 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f50fc001600) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f510b7fc700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f510b7fc700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139986062001920, -1270168254981307517, 140723383549582, 140723383549583, 0, 237624242240, 1224242755998090115, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 6 (Thread 0x7f510bffd700 (LWP 36)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f5104001730, timeout=<optimized out>, context=0x7f51040008c0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f5104001730 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f51040008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f5104001730 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f5104001600) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f510bffd700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f510bffd700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139986070394624, -1270168254981307517, 140723383549582, 140723383549583, 0, 237624242240, 1224243852825363331, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 5 (Thread 0x7f5158cd5700 (LWP 35)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f5150001330, timeout=<optimized out>, context=0x7f51500008c0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f5150001330 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x7f51500008c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f5150001330 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x7f5150001200) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #5 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/generic/WorkQueueGeneric.cpp:44 #6 0x00007f516bf61784 in call() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:101 #7 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #8 0x00007f516bf3a78b in WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Threading.cpp:129 #9 0x00007f516bf60859 in wtfThreadEntryPoint() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/ThreadingPthreads.cpp:228 #10 0x0000003754207404 in start_thread (arg=0x7f5158cd5700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f5158cd5700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139987358930688, -1270168254981307517, 140723383549582, 140723383549583, 0, 237624242240, 1224351454641030019, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #11 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 4 (Thread 0x7f5159745700 (LWP 32)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=3, fds=0x7f514c0010c0, timeout=<optimized out>, context=0x1073070) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 3 allocated_nfds = 3 fds = 0x7f514c0010c0 #2 0x00007f51674ad626 in g_main_context_iterate (context=0x1073070, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 3 allocated_nfds = 3 fds = 0x7f514c0010c0 #3 0x00007f51674ad9c2 in g_main_loop_run (loop=0x107d800) at gmain.c:4082 __func__ = "g_main_loop_run" #4 0x00007f5167a96896 in gdbus_shared_thread_func (user_data=0x107d750) at gdbusprivate.c:275 data = 0x107d750 #5 0x00007f51674d54f5 in g_thread_proxy (data=0x102db70) at gthread.c:784 thread = 0x102db70 #6 0x0000003754207404 in start_thread (arg=0x7f5159745700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f5159745700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139987369875200, -1270168254981307517, 140723383545550, 140723383545551, 0, 237624242240, 1224352768901022595, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #7 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 3 (Thread 0x7f5159f46700 (LWP 31)): #0 0x0000003753adf56d in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f51674ad626 in g_main_context_iterate (priority=<optimized out>, n_fds=1, fds=0x7f51540008e0, timeout=<optimized out>, context=0x10707f0) at gmain.c:4187 ret = <optimized out> errsv = <optimized out> poll_func = 0x7f51674bd360 <g_poll> max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f51540008e0 #2 0x00007f51674ad626 in g_main_context_iterate (context=context@entry=0x10707f0, block=block@entry=1, dispatch=d ispatch@entry=1, self=<optimized out>) at gmain.c:3881 max_priority = 2147483647 timeout = -1 some_ready = <optimized out> nfds = 1 allocated_nfds = 1 fds = 0x7f51540008e0 #3 0x00007f51674ad74c in g_main_context_iteration (context=0x10707f0, may_block=may_block@entry=1) at gmain.c:3947 retval = <optimized out> #4 0x00007f51674ad791 in glib_worker_main (data=<optimized out>) at gmain.c:5742 #5 0x00007f51674d54f5 in g_thread_proxy (data=0x102dad0) at gthread.c:784 thread = 0x102dad0 #6 0x0000003754207404 in start_thread (arg=0x7f5159f46700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f5159f46700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139987378267904, -1270168254981307517, 140723383545134, 140723383545135, 0, 237624242240, 1224353867875779459, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #7 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 2 (Thread 0x7f515c155700 (LWP 22)): #0 0x000000375420d498 in pthread_cond_timedwait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225 #1 0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/x86_64-unknown-linux/bits/gthr-default.h:871 #2 0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:166 #3 0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:106 #4 0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:274 #5 0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:285 #6 0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /usr/include/c++/6.2.0/condition_variable:300 #7 0x00007f516bf6c468 in bmalloc::Scavenger::threadRunLoop() () at /run/build-runtime/webkitgtk4/Source/bmalloc/bmalloc/Scavenger.cpp:149 #8 0x00007f516329ff6f in std::execute_native_thread_routine(void*) (__p=0xfde390) at ../../../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libstdc++-v3/src/c++11/thread.cc:83 __t = {_M_t = {<std::_Tuple_impl<0ul, std::thread::_State*, std::default_delete<std::thread::_State> >> = {<std::_Tuple_impl<1ul, std::default_delete<std::thread::_State> >> = {<std::_Head_base<1ul, std::default_delete<std::thread::_State>, true>> = {<std::default_delete<std::thread::_State>> = {<No data fields>}, <No data fields>}, <No data fields>}, <std::_Head_base<0ul, std::thread::_State*, false>> = {_M_head_impl = 0xfde390}, <No data fields>}, <No data fields>}} #9 0x0000003754207404 in start_thread (arg=0x7f515c155700) at /usr/src/debug/glibc/2.24-r0/git/nptl/pthread_create.c:456 __res = <optimized out> pd = 0x7f515c155700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139987413980928, -1270168254981307517, 140723383549934, 1407233835499 35, 0, 237624242240, 1224359632258761603, -1283001481460022397}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #10 0x0000003753ae827f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105 Thread 1 (Thread 0x7f515c159900 (LWP 21)): #0 0x00007f516f1236d7 in WebCore::CoordinatedGraphicsLayer::transformedVisibleRect() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:890 #1 0x00007f516f124d29 in WebCore::CoordinatedGraphicsLayer::updateContentBuffers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:968 #2 0x00007f516f124db3 in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:940 #3 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #4 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #5 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #6 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #7 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #8 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #9 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #10 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #11 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #12 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #13 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #14 0x00007f516f124ddc in WebCore::CoordinatedGraphicsLayer::updateContentBuffersIncludingSubLayers() () at /run/build-runtime/webkitgtk4/Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:943 #15 0x00007f516e6ad507 in WebKit::CompositingCoordinator::flushPendingLayerChanges() () at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CompositingCoordinator.cpp:123 #16 0x00007f516e6b20eb in WebKit::CoordinatedLayerTreeHost::layerFlushTimerFired() () at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:204 #17 0x00007f516e6b22d8 in WebKit::CoordinatedLayerTreeHost::renderNextFrame() () at /run/build-runtime/webkitgtk4/Source/WebKit/WebProcess/WebPage/CoordinatedGraphics/CoordinatedLayerTreeHost.cpp:178 #18 0x00007f516bf39550 in WTF::RunLoop::performWork() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/Function.h:56 #19 0x00007f516bf39550 in WTF::RunLoop::performWork() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/RunLoop.cpp:106 #20 0x00007f516bf61e09 in _FUN() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:68 #21 0x00007f516bf61e09 in _FUN() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:70 #22 0x00007f51674ad2da in g_main_context_dispatch (context=0x104c8f0) at gmain.c:3148 dispatch = 0x7f516bf61e20 <_FUN()> prev_source = 0x0 was_in_call = 0 user_data = 0x7f515b8f9000 callback = 0x7f516bf61e00 <_FUN()> cb_funcs = <optimized out> cb_data = 0x11bc2e0 need_destroy = <optimized out> source = 0x11bc250 current = 0x107af50 i = 0 #23 0x00007f51674ad2da in g_main_context_dispatch (context=context@entry=0x104c8f0) at gmain.c:3813 #24 0x00007f51674ad698 in g_main_context_iterate (context=0x104c8f0, block=block@entry=1, dispatch=dispatch@entry= 1, self=<optimized out>) at gmain.c:3886 max_priority = 100 timeout = 0 some_ready = 1 nfds = 4 allocated_nfds = 4 fds = <optimized out> #25 0x00007f51674ad9c2 in g_main_loop_run (loop=0x11bc230) at gmain.c:4082 __func__ = "g_main_loop_run" #26 0x00007f516bf62810 in WTF::RunLoop::run() () at /run/build-runtime/webkitgtk4/Source/WTF/wtf/glib/RunLoopGLib.cpp:96 #27 0x00007f516e6bb859 in WebKit::ChildProcessMain<WebKit::WebProcess, WebKit::WebProcessMain>(int, char**) () at /run/build-runtime/webkitgtk4/Source/WebKit/Shared/unix/ChildProcessMain.h:61 #28 0x0000003753a20291 in __libc_start_main (main= 0x400bd0 <main()>, argc=2, argv=0x7ffcb749c2b8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffcb749c2a8) at /usr/src/debug/glibc/2.24-r0/git/csu/libc-start.c:289 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -1270168804309302397, 4197424, 140723383550640, 0, 0, 1271732670176199555, -1283011358323997821}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7ffcb749c2d0, 0x3753824168}, data = {prev = 0x0, cleanup = 0x0, canceltype = -1219902768}}} not_first_call = <optimized out> #29 0x0000000000400c5a in _start () at ../sysdeps/x86_64/start.S:120
Hi, I'm also affected by this bug on a 32bit platform with webkit2gtk 2.18.3 and can confirm that disabling jit solves the problem for me.
Created attachment 336663 [details] Better backtrace Here's a better backtrace We have 291 reports of this in Fedora.
Hi, for me the problem was, that I build a i686 webkit2gtk in a chroot on a x86_64 system and I did not use "setarch i686" to run commands in the chroot. This was the reason for cmake to think it was building on x86_64 and set CMAKE_HOST_SYSTEM to x86_64. The build worked fine and the resulted webkit2gtk worked but it crashed WebCore::CoordinatedGraphicsLayer::transformedVisibleRect when it was run without WEBKIT_DISABLE_COMPOSITING_MODE=1. After building with "setarch i686" I had no problems.
Hey mcatanzaro, can you post the downstream Fedora bug report here? If there are other webpages mentioned there that can crash the browser it would be helpful for me to try to isolate the crash situation in a test.
The crash happens basically because m_coordinator is null at FloatRect rect = m_cachedInverseTransform.clampedBoundsOfProjectedQuad(FloatQuad(m_coordinator->visibleContentsRect())); And it happens after AC goes through on -> off -> on. > Just wait 30 seconds and scroll down a bit (I don't know what triggers the bug, but I always get the crash). We have to wait a few seconds because there is a 5s timer to free the resources when turning AC off. When AC is turned off, all CoordinatedGraphicsLayers should be destroyed, I believe. However in this page some layers are not destroyed and left with a null m_coordinator, which happens in CompositingCoordinator destructor: for (auto& registeredLayer : m_registeredLayers.values()) registeredLayer->setCoordinator(nullptr); Then, when AC is on again, those same layers are reused with m_coordinator == nullptr and results in the crash. > https://www.harrypotterplatform934.com/pages/faqs In this page in specific, the node that causes the crash is a div inside of an iframe that has css animation on translateY property (which is what triggers AC on I guess). The iframe has 0px width and 0px height though so it does not show on the screen and I'm not sure GraphicsLayers should be created for it in this case. This page however is quite big and the CSS properties are maybe changed via JS. So other pages would help understand this more easily.
(In reply to Carlos Eduardo Ramalho from comment #16) > Hey mcatanzaro, can you post the downstream Fedora bug report here? If there > are other webpages mentioned there that can crash the browser it would be > helpful for me to try to isolate the crash situation in a test. I can post the backtraces, but there's no way to know what websites triggered them. (In reply to Carlos Eduardo Ramalho from comment #17) > The crash happens basically because m_coordinator is null Hmmm, I think Miguel was looking into a different bug where this was confusing him. Maybe it's the same underlying issue. Would be good to check with him.
(In reply to Michael Catanzaro from comment #18) > I can post the backtraces, but there's no way to know what websites > triggered them. Actually the first backtrace is already attached, and the second one is not worth posting as gdb hung.
> I can post the backtraces, but there's no way to know what websites > triggered them. Ahh ok. I thought people reported it downstream in fedora bugzilla with links but it's just crash reports from fedora. Sorry for my confusion. Thanks anyway :)
Created attachment 338322 [details] Dump of Graphics Layers Dump of the Graphics Layers right before crashing. Notice I added the "coordinator" field and it shows that all iframe children have a null coordinator.
Created attachment 338326 [details] Backtrace Another backtrace, in case it helps We're up to 322 reports of this in Fedora (not too many), first occurrence was 2017-06-26
(In reply to Carlos Eduardo Ramalho from comment #17) > We have to wait a few seconds because there is a 5s timer to free the > resources when turning AC off. I was wrong in that statement. Actually we have to wait usually 13s to reproduce the crash on https://www.harrypotterplatform934.com/pages/faqs because AC is turned on every 6.5s: the JS script defines this time to make a transition a slide div (slidesjs-control) that shows up on the left side of the page below the menu. This animated transition (using translateX) triggers AC off -> on -> off every 6.5s. So the scenario is like that: 0s -> page opens 6.5 -> slidejs animation: AC off -> on -> off 11.5s -> 5s timer kicks in, discarding previous LayerTreeHost 13s -> slidejs animation: AC off -> on, then segfault in CoordinatedGraphicsLayer::transformedVisibleRect() The GraphicsLayer node that causes the crash is in a div with animation embedded in a iframe, this iframe is inserted to the DOM via JS. However there's some catch I didn't figure out yet because doing so in the same scenario in a simpler webpage does not cause the crash.
As Carlos mentions, the problem is the null compositor on some of the layers. When leaving AC, all the GraphicsLayers are destroyed except the children of the iframe containing the dialog (see the attached GraphicsLayer dump). But 5 seconds after that, the CompositingCoordinator is destroyed, setting compositor attribute to null for those layers. When scrolling the page, seems that the iframe with the dialog is added to the page again, and that causes that the surviving GraphicsLayers are added again to the GraphicsLayer tree, but their coordinator is not properly set, so the crash during the layer flush happens. I need to investigate why these GraphicsLayers are kept alive, and if it makes sense to do that, or we should be destroying them. Maybe it's an optimization speed up the rendering of constant subtrees (in which case we should just the appropriate coordinator when reattaching the subtree) or maybe it's a bug and we should just destroy them and recreate them when needed.
Created attachment 342736 [details] Patch
Comment on attachment 342736 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=342736&action=review > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > + // If the coordinators are different it means that we are attaching a layer that was created by a different > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > + // layer and its children. The dynamic AC entry and exit continues to produce bugs and require fixes that only complicate the CoordinatedGraphics stack and any future improvements. I propose WebKitGTK+ adds an API that for the specific UIProcess instance either enables or disables AC, but otherwise abandons dynamic AC entry and exit.
> The dynamic AC entry and exit continues to produce bugs and require fixes > that only complicate the CoordinatedGraphics stack and any future > improvements. I propose WebKitGTK+ adds an API that for the specific > UIProcess instance either enables or disables AC, but otherwise abandons > dynamic AC entry and exit. That would indeed simplify things, but last time we tried that we had all those excessive memory consumption problems. I think we have improved a bit since that, but still there's going to be a noticeable difference in memory usage if AC is always enabled. Anyway, we can take some measures and see.
(In reply to Miguel Gomez from comment #27) > > The dynamic AC entry and exit continues to produce bugs and require fixes > > that only complicate the CoordinatedGraphics stack and any future > > improvements. I propose WebKitGTK+ adds an API that for the specific > > UIProcess instance either enables or disables AC, but otherwise abandons > > dynamic AC entry and exit. > > That would indeed simplify things, but last time we tried that we had all > those excessive memory consumption problems. > > I think we have improved a bit since that, but still there's going to be a > noticeable difference in memory usage if AC is always enabled. Anyway, we > can take some measures and see. Fast memory usage test: * about::blank non AC 1920x0180: 86848KB * about::blank AC 1920x0180: 102396KB * webkitgtk.org non AC: 104172KB * webkitgtk.org AC: 128420KB about ~20MB increased memory. Anyway this gap will be reduced if we can get rid of the cairo rasterization.
(In reply to Miguel Gomez from comment #28) > (In reply to Miguel Gomez from comment #27) > > > The dynamic AC entry and exit continues to produce bugs and require fixes > > > that only complicate the CoordinatedGraphics stack and any future > > > improvements. I propose WebKitGTK+ adds an API that for the specific > > > UIProcess instance either enables or disables AC, but otherwise abandons > > > dynamic AC entry and exit. > > > > That would indeed simplify things, but last time we tried that we had all > > those excessive memory consumption problems. > > > > I think we have improved a bit since that, but still there's going to be a > > noticeable difference in memory usage if AC is always enabled. Anyway, we > > can take some measures and see. > > Fast memory usage test: > > * about::blank non AC 1920x0180: 86848KB > * about::blank AC 1920x0180: 102396KB > * webkitgtk.org non AC: 104172KB > * webkitgtk.org AC: 128420KB > > about ~20MB increased memory. > > Anyway this gap will be reduced if we can get rid of the cairo rasterization. Regardless of how Cairo replacement goes, I'll still move over WPE to a separate LayerTreeHost and GraphicsLayer tree implementation if future changes to CoordinatedGraphics that are addressing AC dynamic entry-exit issues conflict with other improvements.
Comment on attachment 342736 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=342736&action=review > Source/WebCore/ChangeLog:10 > + When adding new CoordinatedGraphicsLayers to the tree, check that they have the appropriate > + CompositingCoordinator. If that's not the case, set the appropriate one to the layer and its > + children and set the state of those layers so they are rendered properly. Is there a case where layers created via (already-destroyed) CompositingCoordinator#1 are added to a layer tree managed by CompositingCoordinator#2 *that are not* the root compositing layer or the view overlay layer that are set via CompositingCoordinator::setRootCompositingLayer() or CompositingCoordinator::setViewOverlayRootLayer()?
(In reply to Zan Dobersek from comment #26) > Comment on attachment 342736 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > > + // If the coordinators are different it means that we are attaching a layer that was created by a different > > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > > + // layer and its children. > > The dynamic AC entry and exit continues to produce bugs and require fixes > that only complicate the CoordinatedGraphics stack and any future > improvements. I propose WebKitGTK+ adds an API that for the specific > UIProcess instance either enables or disables AC, but otherwise abandons > dynamic AC entry and exit. It's actually revealing existing bugs in most of the cases I would say. But still, we are not going to change it. I don't think cairo is the problem either. I think we would need to move the threaded compositor to the UI process to be able to get rid of the non accelerated rendering mode. Note that we already have API to force compositing, disable it or keep it on demand (the default). Note also that this problem is not specific to GTK+, the same happens in WPE, the difference is that WPE is not used by general purpose browsers with tons of tabs opened.
Comment on attachment 342736 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=342736&action=review >>> Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 >>> + // layer and its children. >> >> The dynamic AC entry and exit continues to produce bugs and require fixes that only complicate the CoordinatedGraphics stack and any future improvements. I propose WebKitGTK+ adds an API that for the specific UIProcess instance either enables or disables AC, but otherwise abandons dynamic AC entry and exit. > > It's actually revealing existing bugs in most of the cases I would say. But still, we are not going to change it. I don't think cairo is the problem either. I think we would need to move the threaded compositor to the UI process to be able to get rid of the non accelerated rendering mode. Note that we already have API to force compositing, disable it or keep it on demand (the default). Note also that this problem is not specific to GTK+, the same happens in WPE, the difference is that WPE is not used by general purpose browsers with tons of tabs opened. WPE always remains in AC mode, it doesn't enter and exit it depending on the content. GraphicsLayer objects don't get transferred from one CompositingCoordinator to another. So no, this doesn't affect WPE.
(In reply to Zan Dobersek from comment #32) > Comment on attachment 342736 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > >>> Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > >>> + // layer and its children. > >> > >> The dynamic AC entry and exit continues to produce bugs and require fixes that only complicate the CoordinatedGraphics stack and any future improvements. I propose WebKitGTK+ adds an API that for the specific UIProcess instance either enables or disables AC, but otherwise abandons dynamic AC entry and exit. > > > > It's actually revealing existing bugs in most of the cases I would say. But still, we are not going to change it. I don't think cairo is the problem either. I think we would need to move the threaded compositor to the UI process to be able to get rid of the non accelerated rendering mode. Note that we already have API to force compositing, disable it or keep it on demand (the default). Note also that this problem is not specific to GTK+, the same happens in WPE, the difference is that WPE is not used by general purpose browsers with tons of tabs opened. > > WPE always remains in AC mode, it doesn't enter and exit it depending on the > content. GraphicsLayer objects don't get transferred from one > CompositingCoordinator to another. So no, this doesn't affect WPE. What I meant is that the memory and performance problem of being always in AC mode si not specific to GTK+, it affects WPE as well. But it's very noticeable in WebKitGTK+ because it's used in general purpose browsers with a lot of tabs opened. That requires a lot of memory because we have one gl context per tab. And it's not only the browser startup performance, but every time you open a new tab, a new gl context is created making the tab creation slow.
(In reply to Carlos Garcia Campos from comment #31) > (In reply to Zan Dobersek from comment #26) > > Comment on attachment 342736 [details] > > Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > > > + // If the coordinators are different it means that we are attaching a layer that was created by a different > > > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > > > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > > > + // layer and its children. > > > > The dynamic AC entry and exit continues to produce bugs and require fixes > > that only complicate the CoordinatedGraphics stack and any future > > improvements. I propose WebKitGTK+ adds an API that for the specific > > UIProcess instance either enables or disables AC, but otherwise abandons > > dynamic AC entry and exit. > > It's actually revealing existing bugs in most of the cases I would say. But > still, we are not going to change it. This will certainly block async scrolling for the GTK+ port, because of how the scrolling is handled. It might also collide with other improvements in composition. > I don't think cairo is the problem either. It certainly is. Whenever anything is drawn, with Cairo, a backing store has to be used. This means rasterizing into CPU memory that then gets copied over to the GPU. So you need to first waste the CPU memory to get all the backing stores updated, before you waste the GPU memory to hold all the backing store content there. Only improvement possible is leveraging mapping of GPU memory into user-space and rasterizing with Cairo into that area. The largest problem then is management of these memory areas, but I can assure you that handling regularly-occurring AC entries and exits will not help one bit. > I think we would need to move the threaded compositor to the UI > process to be able to get rid of the non accelerated rendering mode. This in no way improves the backing store memory consumption problem, as described above. If your argument is that OpenGL-and-GLX combo is still too heavy to initialize in every WebProcess, we should be looking into adopting EGL and OpenGL ES universally. But even then, with lots of tabs open, the large majority of memory is not spent on the graphics pipeline, but other things like Web content and caches. You should be looking into WebProcess management instead. > Note > that we already have API to force compositing, disable it or keep it on > demand (the default). Note also that this problem is not specific to GTK+, > the same happens in WPE, the difference is that WPE is not used by general > purpose browsers with tons of tabs opened. Explained in the previous comment.
In addition to the need to fix the memory usage problem, switching to OpenGL makes us responsible for bugs like bug #170347, which is still unfixed. Unless our graphics experts are able to successfully debug and resolve such issues on hardware we do not own, in a reasonable amount of time after bugs are reported, then I don't see any hope of switching to GPU rendering. If we switch to always-on AC mode, there will be a multitude of new such issues reported. If we're not able to handle them, then we'll just need to switch back. I don't want to veto this or anything, just point out that if we do it, it will mean increased work debugging hardware-specific issues will be required from our graphics experts, and I'm not sure if we're prepared for that. And, as we discussed in the past, always-on AC is almost certainly going to require a GPU blacklist, but I guess we don't need one until we have a bug report and want to add the first GPU to it.
(In reply to Michael Catanzaro from comment #35) > In addition to the need to fix the memory usage problem, switching to OpenGL > makes us responsible for bugs like bug #170347, Also bug #180739, also unfixed
(In reply to Carlos Garcia Campos from comment #33) > [...] > I think we would need to move the threaded compositor to the UI process to be able to get rid of the non accelerated rendering mode. That would mean exposing the UIProcess to crashes if the OpenGL drivers don't behave correctly, right? Crashing the WebProces is bad, but crashing the UIProcess is much worse... the app can't recover itself without external help. > > > > WPE always remains in AC mode, it doesn't enter and exit it depending on the > > content. GraphicsLayer objects don't get transferred from one > > CompositingCoordinator to another. So no, this doesn't affect WPE. > > What I meant is that the memory and performance problem of being always in > AC mode si not specific to GTK+, it affects WPE as well. But it's very > noticeable in WebKitGTK+ because it's used in general purpose browsers with > a lot of tabs opened. That requires a lot of memory because we have one gl > context per tab. And it's not only the browser startup performance, but > every time you open a new tab, a new gl context is created making the tab > creation slow. I guess the ideal solution would be to have a GPURenderProcess where the same gl context is shared for all the WebProcess/tabs.
As a side note, when I was investigating this bug I stabbed upon this bit in RenderLayerCompositor::computeCompositingRequirements(): // If we're back at the root, and no other layers need to be composited, and the root layer itself doesn't need // to be composited, then we can drop out of compositing mode altogether. However, don't drop out of compositing mode // if there are composited layers that we didn't hit in our traversal (e.g. because of visibility:hidden). if (layer.isRenderViewLayer() && !childState.subtreeIsCompositing && !requiresCompositingLayer(layer) && !m_forceCompositingMode && !hasAnyAdditionalCompositedLayers(layer)) { // Don't drop out of compositing on iOS, because we may flash. See <rdar://problem/8348337>. #if !PLATFORM(IOS) enableCompositingMode(false); willBeComposited = false; #endif } Adding GTK the the #if 'fixed' this bug because once the WebProcess entered AC mode, it would not leave anymore. I didn't consider submitting this as I thought it was not in the plans to do something like that and a proper fix like the one Miguel sent would be the correct approach. However, now that this discussion has come up it might be relevant... If I'm correct, doing this would still render non-AC pages if no acceleration is required, but pages that do require (even temporarily) would stay in AC mode afterwards. That would avoid special logic for dynamic on-off AC mode, since the only AC mode-switching would be OFF -> ON once if required. I may be totally wrong here though, if so do correct me.
(In reply to Zan Dobersek from comment #30) > Comment on attachment 342736 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > Source/WebCore/ChangeLog:10 > > + When adding new CoordinatedGraphicsLayers to the tree, check that they have the appropriate > > + CompositingCoordinator. If that's not the case, set the appropriate one to the layer and its > > + children and set the state of those layers so they are rendered properly. > > Is there a case where layers created via (already-destroyed) > CompositingCoordinator#1 are added to a layer tree managed by > CompositingCoordinator#2 *that are not* the root compositing layer or the > view overlay layer that are set via > CompositingCoordinator::setRootCompositingLayer() or > CompositingCoordinator::setViewOverlayRootLayer()? From the tests I've been running, this problem is only reproducible with iframes (due to their own RenderLayerCompositor), and in those cases the root node of the layer subtree added to the new compositor is always the "overflow controls host" layer.
(In reply to Zan Dobersek from comment #34) > (In reply to Carlos Garcia Campos from comment #31) > > (In reply to Zan Dobersek from comment #26) > > > Comment on attachment 342736 [details] > > > Patch > > > > > > View in context: > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > > > > + // If the coordinators are different it means that we are attaching a layer that was created by a different > > > > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > > > > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > > > > + // layer and its children. > > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes > > > that only complicate the CoordinatedGraphics stack and any future > > > improvements. I propose WebKitGTK+ adds an API that for the specific > > > UIProcess instance either enables or disables AC, but otherwise abandons > > > dynamic AC entry and exit. > > > > It's actually revealing existing bugs in most of the cases I would say. But > > still, we are not going to change it. > > This will certainly block async scrolling for the GTK+ port, because of how > the scrolling is handled. It might also collide with other improvements in > composition. Can't those be used only when in AC mode? > > I don't think cairo is the problem either. > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has > to be used. This means rasterizing into CPU memory that then gets copied > over to the GPU. So you need to first waste the CPU memory to get all the > backing stores updated, before you waste the GPU memory to hold all the > backing store content there. > > Only improvement possible is leveraging mapping of GPU memory into > user-space and rasterizing with Cairo into that area. The largest problem > then is management of these memory areas, but I can assure you that handling > regularly-occurring AC entries and exits will not help one bit. With exactly the same cairo code epiphany was unusable for most of the users when we switched to always use AC, and became usable again when we added the on demand mode. This is a fact. I would love to switch to always AC, and remove all the complexity of switching between modes, but we simply can't, at least not right now. > > I think we would need to move the threaded compositor to the UI > > process to be able to get rid of the non accelerated rendering mode. > > This in no way improves the backing store memory consumption problem, as > described above. If your argument is that OpenGL-and-GLX combo is still too > heavy to initialize in every WebProcess, we should be looking into adopting > EGL and OpenGL ES universally. The problem was not specific to GLX, it happened exactly the same in wayland using EGL. The problem is quite simple, every gl context requires quite a bit of memory and creating the context also takes some time. When you only have one web view that's not a problem, the browser might be a bit slower once at startup and the gl context only adds some more memory. But when you open epiphany (or any other WebKitGTK+ based browser) with AC always enabled, the memory required for all the gl contexts is too much for most of the users. And every time you open a tab you notice the slowdown. Moving the compositing to the UI (or to a dedicated process as Carlos suggested) would use one gl context no matter how many tabs you have, fixing the problem. > But even then, with lots of tabs open, the large majority of memory is not > spent on the graphics pipeline, but other things like Web content and > caches. You should be looking into WebProcess management instead. If we fix all those problems with cairo and WebKitGTK+ browsers are usable with AC always enabled I'm open to try again, but that's not the case right now, with our current code the amount of memory gl adds on top makes it impossible. > > Note > > that we already have API to force compositing, disable it or keep it on > > demand (the default). Note also that this problem is not specific to GTK+, > > the same happens in WPE, the difference is that WPE is not used by general > > purpose browsers with tons of tabs opened. > > Explained in the previous comment.
(In reply to Carlos Garcia Campos from comment #40) > (In reply to Zan Dobersek from comment #34) > > (In reply to Carlos Garcia Campos from comment #31) > > > (In reply to Zan Dobersek from comment #26) > > > > Comment on attachment 342736 [details] > > > > Patch > > > > > > > > View in context: > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > > > > > + // If the coordinators are different it means that we are attaching a layer that was created by a different > > > > > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > > > > > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > > > > > + // layer and its children. > > > > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes > > > > that only complicate the CoordinatedGraphics stack and any future > > > > improvements. I propose WebKitGTK+ adds an API that for the specific > > > > UIProcess instance either enables or disables AC, but otherwise abandons > > > > dynamic AC entry and exit. > > > > > > It's actually revealing existing bugs in most of the cases I would say. But > > > still, we are not going to change it. > > > > This will certainly block async scrolling for the GTK+ port, because of how > > the scrolling is handled. It might also collide with other improvements in > > composition. > > Can't those be used only when in AC mode? > Async scrolling requires constant AC mode. Other features will be used only when in AC mode, some might require that mode to be constant as well. What I don't want to waste time on is addressing the dynamic AC entry-and-exit functionality. > > > I don't think cairo is the problem either. > > > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has > > to be used. This means rasterizing into CPU memory that then gets copied > > over to the GPU. So you need to first waste the CPU memory to get all the > > backing stores updated, before you waste the GPU memory to hold all the > > backing store content there. > > > > Only improvement possible is leveraging mapping of GPU memory into > > user-space and rasterizing with Cairo into that area. The largest problem > > then is management of these memory areas, but I can assure you that handling > > regularly-occurring AC entries and exits will not help one bit. > > With exactly the same cairo code epiphany was unusable for most of the users > when we switched to always use AC, and became usable again when we added the > on demand mode. This is a fact. I would love to switch to always AC, and > remove all the complexity of switching between modes, but we simply can't, > at least not right now. > What I'm saying is that with Cairo, when in AC mode, you will have the memory overhead for the duration between the start of painting into the backing store until all that memory is copied over to the GPU. In that context, Cairo is the problem. Memory consumption in this case was 'improved' by removing the UpdateAtlas cache, and relying on bmalloc to efficiently allocate all the CPU memory into which the painting is done. But there's still spikes in memory consumption as long as painting is done, as described before. > > > I think we would need to move the threaded compositor to the UI > > > process to be able to get rid of the non accelerated rendering mode. > > > > This in no way improves the backing store memory consumption problem, as > > described above. If your argument is that OpenGL-and-GLX combo is still too > > heavy to initialize in every WebProcess, we should be looking into adopting > > EGL and OpenGL ES universally. > > The problem was not specific to GLX, it happened exactly the same in wayland > using EGL. The problem is quite simple, every gl context requires quite a > bit of memory and creating the context also takes some time. When you only > have one web view that's not a problem, the browser might be a bit slower > once at startup and the gl context only adds some more memory. But when you > open epiphany (or any other WebKitGTK+ based browser) with AC always > enabled, the memory required for all the gl contexts is too much for most of > the users. And every time you open a tab you notice the slowdown. Moving the > compositing to the UI (or to a dedicated process as Carlos suggested) would > use one gl context no matter how many tabs you have, fixing the problem. > Do you recall how much memory that was? Cause the biggest memory issue I recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some overhead, but when taken as a percentage of the whole WebProcess consumption I don't think you'd be able to mark that overhead as critical. When moving composition to a single process, you don't take into account that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is improved regarding painting, with Cairo all the memory still has to be allocated just as before. If the GL context creation overhead (in terms of memory and time) is a problem, how is this not an even bigger problem for you when AC is entered on demand, which can happen a bunch of times on a single page? > > But even then, with lots of tabs open, the large majority of memory is not > > spent on the graphics pipeline, but other things like Web content and > > caches. You should be looking into WebProcess management instead. > > If we fix all those problems with cairo and WebKitGTK+ browsers are usable > with AC always enabled I'm open to try again, but that's not the case right > now, with our current code the amount of memory gl adds on top makes it > impossible. > How much is that amount of memory? What percentage is it compared to the memory consumption of that whole WebProcess? Let's specify Web pages to test, and produce massif profiles and memory mapping dumps for comparison. Anyway, my point is, why does Epiphany have to immediately spawn a WebProcess for each tab when it's launched, when I haven't even activated that tab? And why can't a WebProcess for a given tab be shut down after the tab wasn't activated for a while? That's what I meant with 'WebProcess management'.
Comment on attachment 342736 [details] Patch I don't see any obvious problems with this code, and I guess Zan would have pointed one out if he did. We should certainly not delay fixing a major crash like this while arguing about the future.
I would be OK with always-on AC mode if (a) it actually works for our users and (b) it doesn't involve a huge memory usage increase. Surely Carlos would be fine with it under those conditions, too, right Carlos? So Zan, if you're aware of the problems we faced last time we tried this, and think you can solve them, then I'd say go ahead. But it really needs to deliver on both points (a) and (b). I am skeptical, because the last time we tried this, from 2.13.4 until we reverted it in 2.14.4, it was a disaster. AC mode failed on both counts (a) and (b), and it failed *badly*. Regarding (a), bug #170347 would need to be fixed first, as would bug #180739. The fact is that AC mode simply does not work for some users, and that we have historically fared poorly at responding to bug reports related to AC mode. We need to be prepared to respond *and resolve* an influx of reports that AC mode does not work on hardware that we do not own. I'm not sure how we can credibly continue this discussion without acknowledgment of this issue, as I expect it to create a substantial amount of new work for you and Miguel. Regarding (b), you would need to look at the difference in memory usage -- with one tab open, with 20 tabs open, and with 200 tabs open -- and then we can make a value judgment as to whether any increased memory requirement is worth the maintenance benefit of removing the mode-swapping support. Last time we tried this, we had application developers who used only one or two web views in their applications complaining about dramatically increased memory use. We need to scale way beyond that. (In reply to Zan Dobersek from comment #41) > Anyway, my point is, why does Epiphany have to immediately spawn a > WebProcess for each tab when it's launched, when I haven't even activated > that tab? And why can't a WebProcess for a given tab be shut down after the > tab wasn't activated for a while? That's what I meant with 'WebProcess > management'. I was going to suggest this as well. It would be highly desirable to have automatic tab discarding, similar to Chromium. And for tabs to not load until they are visited. That would be a WK2-level feature. Apple tried implementing this a year or two ago, but gave up and removed the code due to tricky problems I don't remember. So this would be a huge project to get working well enough to be used in Epiphany and Safari. In Epiphany, we work around lack of tab discarding by loading blank pages into all of the web views on startup, but it's not good enough as the memory usage is still significant when you have too many tabs open, using a bunch of memory to show nothing. An optimization would be to share the same web process among different tabs with the same security origin. This process model is probably needed for WebKit to remain competitive long-term. It might also be possible to create and attach the web views on demand as well, but that probably won't be useful with a per-origin process model, and it would still be just a hack. Proper solutions to these problems would be WebKit-level work.
(In reply to Zan Dobersek from comment #41) > (In reply to Carlos Garcia Campos from comment #40) > > (In reply to Zan Dobersek from comment #34) > > > (In reply to Carlos Garcia Campos from comment #31) > > > > (In reply to Zan Dobersek from comment #26) > > > > > Comment on attachment 342736 [details] > > > > > Patch > > > > > > > > > > View in context: > > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > > > > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > > > > > > + // If the coordinators are different it means that we are attaching a layer that was created by a different > > > > > > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > > > > > > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > > > > > > + // layer and its children. > > > > > > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes > > > > > that only complicate the CoordinatedGraphics stack and any future > > > > > improvements. I propose WebKitGTK+ adds an API that for the specific > > > > > UIProcess instance either enables or disables AC, but otherwise abandons > > > > > dynamic AC entry and exit. > > > > > > > > It's actually revealing existing bugs in most of the cases I would say. But > > > > still, we are not going to change it. > > > > > > This will certainly block async scrolling for the GTK+ port, because of how > > > the scrolling is handled. It might also collide with other improvements in > > > composition. > > > > Can't those be used only when in AC mode? > > > > Async scrolling requires constant AC mode. Other features will be used only > when in AC mode, some might require that mode to be constant as well. What I > don't want to waste time on is addressing the dynamic AC entry-and-exit > functionality. We won't be able to use async scrolling in GTK for now then. We have no choice right now. > > > > I don't think cairo is the problem either. > > > > > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has > > > to be used. This means rasterizing into CPU memory that then gets copied > > > over to the GPU. So you need to first waste the CPU memory to get all the > > > backing stores updated, before you waste the GPU memory to hold all the > > > backing store content there. > > > > > > Only improvement possible is leveraging mapping of GPU memory into > > > user-space and rasterizing with Cairo into that area. The largest problem > > > then is management of these memory areas, but I can assure you that handling > > > regularly-occurring AC entries and exits will not help one bit. > > > > With exactly the same cairo code epiphany was unusable for most of the users > > when we switched to always use AC, and became usable again when we added the > > on demand mode. This is a fact. I would love to switch to always AC, and > > remove all the complexity of switching between modes, but we simply can't, > > at least not right now. > > > > What I'm saying is that with Cairo, when in AC mode, you will have the > memory overhead for the duration between the start of painting into the > backing store until all that memory is copied over to the GPU. In that > context, Cairo is the problem. Yes, but the checks we did at the time were with about:blank pages. So, I believe you that cairo adds more overhead on top. > Memory consumption in this case was 'improved' by removing the UpdateAtlas > cache, and relying on bmalloc to efficiently allocate all the CPU memory > into which the painting is done. But there's still spikes in memory > consumption as long as painting is done, as described before. > > > > > I think we would need to move the threaded compositor to the UI > > > > process to be able to get rid of the non accelerated rendering mode. > > > > > > This in no way improves the backing store memory consumption problem, as > > > described above. If your argument is that OpenGL-and-GLX combo is still too > > > heavy to initialize in every WebProcess, we should be looking into adopting > > > EGL and OpenGL ES universally. > > > > The problem was not specific to GLX, it happened exactly the same in wayland > > using EGL. The problem is quite simple, every gl context requires quite a > > bit of memory and creating the context also takes some time. When you only > > have one web view that's not a problem, the browser might be a bit slower > > once at startup and the gl context only adds some more memory. But when you > > open epiphany (or any other WebKitGTK+ based browser) with AC always > > enabled, the memory required for all the gl contexts is too much for most of > > the users. And every time you open a tab you notice the slowdown. Moving the > > compositing to the UI (or to a dedicated process as Carlos suggested) would > > use one gl context no matter how many tabs you have, fixing the problem. > > > > Do you recall how much memory that was? Cause the biggest memory issue I > recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some > overhead, but when taken as a percentage of the whole WebProcess consumption > I don't think you'd be able to mark that overhead as critical. I don't remember, it was small for a single tab, but too much for many tabs. With current trunk loading about:blank in MiniBrowser I get: - Wayland no AC: UI: 17,3MB Web: 16,5MB - Wayland AC: UI: 26,5MB Web: 22,3MB - X11 no AC: UI: 12,6MB Web: 13,9MB - X11 AC: UI: 14,5MB Web: 21,1MB > When moving composition to a single process, you don't take into account > that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is > improved regarding painting, with Cairo all the memory still has to be > allocated just as before. It's fine if only tabs currently using WebGL and GStreamer use additional gl contexts, the same way it's fine right now that some tabs have AC mode enabled. > If the GL context creation overhead (in terms of memory and time) is a > problem, how is this not an even bigger problem for you when AC is entered > on demand, which can happen a bunch of times on a single page? When a page enters and leaves AC, it's a single page doing so, I insist that the problem is having Ac enabled in all the pages. Note that when a page enters AC due to a condition change, an animation ro whatever, the page is already rendered so you are seeing the contents, not a white (or even black) page. Starting epiphany with a single or even a few tabs with AC enabled, was a bit slower but acceptable. But with some more tabs the thing was very noticeable. Not to mention resizing the window. > > > But even then, with lots of tabs open, the large majority of memory is not > > > spent on the graphics pipeline, but other things like Web content and > > > caches. You should be looking into WebProcess management instead. > > > > If we fix all those problems with cairo and WebKitGTK+ browsers are usable > > with AC always enabled I'm open to try again, but that's not the case right > > now, with our current code the amount of memory gl adds on top makes it > > impossible. > > > > How much is that amount of memory? What percentage is it compared to the > memory consumption of that whole WebProcess? Let's specify Web pages to > test, and produce massif profiles and memory mapping dumps for comparison. It's not that much percentage for a single web process. If the overhead of cairo or any other thing is solved and makes this one insignificant, then I'm open to try again, but we need to fix those first. > Anyway, my point is, why does Epiphany have to immediately spawn a > WebProcess for each tab when it's launched, when I haven't even activated > that tab? And why can't a WebProcess for a given tab be shut down after the > tab wasn't activated for a while? That's what I meant with 'WebProcess > management'. We could make improvements in process management, but they are not easy at all. Any improvement there to should be done in WebKit, not in the browser side. There are things that browsers can do, though, for example epiphany delays the loads of tabs until they are activated, by using placeholder tabs consisting of about:blank with a title. But a bunch of about:blank pages was still a problem in terms of memory and startup times. As Michael suggested we also have the problem of drivers. To enable AC unconditionally we need a way to get detailed information from users having problems. I thought about adding about:gpu or whatever, to show information about the gpu, the driver, the gl context, the opengl version profile, the extensions available, etc. With the idea of using HardwareAccelerationManager.cpp to blacklist known buggy drivers. Any change in this needs to be done at the very beginning of a release cycle.
Well, as this approach seem to be problematic for Zan's plans, I'll try to fix this by destroying the CoordinatedGraphicsLayers.
(In reply to Miguel Gomez from comment #45) > Well, as this approach seem to be problematic for Zan's plans, I'll try to > fix this by destroying the CoordinatedGraphicsLayers. Don't know what approach this means taking, but with the exception of the root layer we don't own these objects.
(In reply to Michael Catanzaro from comment #43) > I would be OK with always-on AC mode if (a) it actually works for our users > and (b) it doesn't involve a huge memory usage increase. Surely Carlos would > be fine with it under those conditions, too, right Carlos? So Zan, if you're > aware of the problems we faced last time we tried this, and think you can > solve them, then I'd say go ahead. But it really needs to deliver on both > points (a) and (b). I am skeptical, because the last time we tried this, > from 2.13.4 until we reverted it in 2.14.4, it was a disaster. AC mode > failed on both counts (a) and (b), and it failed *badly*. > > Regarding (a), bug #170347 would need to be fixed first, as would bug > #180739. The fact is that AC mode simply does not work for some users, and > that we have historically fared poorly at responding to bug reports related > to AC mode. We need to be prepared to respond *and resolve* an influx of > reports that AC mode does not work on hardware that we do not own. I'm not > sure how we can credibly continue this discussion without acknowledgment of > this issue, as I expect it to create a substantial amount of new work for > you and Miguel. > On our side, we can only work against an OpenGL+GLX or OpenGLES+EGL library. Driver bugs are not ours to fix. > Regarding (b), you would need to look at the difference in memory usage -- > with one tab open, with 20 tabs open, and with 200 tabs open -- and then we > can make a value judgment as to whether any increased memory requirement is > worth the maintenance benefit of removing the mode-swapping support. Last > time we tried this, we had application developers who used only one or two > web views in their applications complaining about dramatically increased > memory use. We need to scale way beyond that. > How well do you think you scale even with AC disabled if you volunteer to spawn a WebProcess for each tab when upon launch? > (In reply to Zan Dobersek from comment #41) > > Anyway, my point is, why does Epiphany have to immediately spawn a > > WebProcess for each tab when it's launched, when I haven't even activated > > that tab? And why can't a WebProcess for a given tab be shut down after the > > tab wasn't activated for a while? That's what I meant with 'WebProcess > > management'. > > I was going to suggest this as well. It would be highly desirable to have > automatic tab discarding, similar to Chromium. And for tabs to not load > until they are visited. That would be a WK2-level feature. Apple tried > implementing this a year or two ago, but gave up and removed the code due to > tricky problems I don't remember. So this would be a huge project to get > working well enough to be used in Epiphany and Safari. > This is a current feature of the Safari browser. I don't know at what level it's implemented. > In Epiphany, we work around lack of tab discarding by loading blank pages > into all of the web views on startup, but it's not good enough as the memory > usage is still significant when you have too many tabs open, using a bunch > of memory to show nothing. > > An optimization would be to share the same web process among different tabs > with the same security origin. This process model is probably needed for > WebKit to remain competitive long-term. It might also be possible to create > and attach the web views on demand as well, but that probably won't be > useful with a per-origin process model, and it would still be just a hack. > Proper solutions to these problems would be WebKit-level work. Can you explain why this can't be done in Epiphany?
(In reply to Carlos Garcia Campos from comment #44) > (In reply to Zan Dobersek from comment #41) > > (In reply to Carlos Garcia Campos from comment #40) > > > (In reply to Zan Dobersek from comment #34) > > > > (In reply to Carlos Garcia Campos from comment #31) > > > > > (In reply to Zan Dobersek from comment #26) > > > > > > Comment on attachment 342736 [details] > > > > > > Patch > > > > > > > > > > > > View in context: > > > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > > > > > > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > > > > > > > + // If the coordinators are different it means that we are attaching a layer that was created by a different > > > > > > > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > > > > > > > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > > > > > > > + // layer and its children. > > > > > > > > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes > > > > > > that only complicate the CoordinatedGraphics stack and any future > > > > > > improvements. I propose WebKitGTK+ adds an API that for the specific > > > > > > UIProcess instance either enables or disables AC, but otherwise abandons > > > > > > dynamic AC entry and exit. > > > > > > > > > > It's actually revealing existing bugs in most of the cases I would say. But > > > > > still, we are not going to change it. > > > > > > > > This will certainly block async scrolling for the GTK+ port, because of how > > > > the scrolling is handled. It might also collide with other improvements in > > > > composition. > > > > > > Can't those be used only when in AC mode? > > > > > > > Async scrolling requires constant AC mode. Other features will be used only > > when in AC mode, some might require that mode to be constant as well. What I > > don't want to waste time on is addressing the dynamic AC entry-and-exit > > functionality. > > We won't be able to use async scrolling in GTK for now then. We have no > choice right now. > OK. > > > > > I don't think cairo is the problem either. > > > > > > > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has > > > > to be used. This means rasterizing into CPU memory that then gets copied > > > > over to the GPU. So you need to first waste the CPU memory to get all the > > > > backing stores updated, before you waste the GPU memory to hold all the > > > > backing store content there. > > > > > > > > Only improvement possible is leveraging mapping of GPU memory into > > > > user-space and rasterizing with Cairo into that area. The largest problem > > > > then is management of these memory areas, but I can assure you that handling > > > > regularly-occurring AC entries and exits will not help one bit. > > > > > > With exactly the same cairo code epiphany was unusable for most of the users > > > when we switched to always use AC, and became usable again when we added the > > > on demand mode. This is a fact. I would love to switch to always AC, and > > > remove all the complexity of switching between modes, but we simply can't, > > > at least not right now. > > > > > > > What I'm saying is that with Cairo, when in AC mode, you will have the > > memory overhead for the duration between the start of painting into the > > backing store until all that memory is copied over to the GPU. In that > > context, Cairo is the problem. > > Yes, but the checks we did at the time were with about:blank pages. So, I > believe you that cairo adds more overhead on top. > about:blank still requires Cairo to render all the whiteness (yes, really). So 8MB had to be allocated for that alone when in 1080p resolution. This is not the case anymore, but I think that's already reflected in your measurements below. > > Memory consumption in this case was 'improved' by removing the UpdateAtlas > > cache, and relying on bmalloc to efficiently allocate all the CPU memory > > into which the painting is done. But there's still spikes in memory > > consumption as long as painting is done, as described before. > > > > > > > I think we would need to move the threaded compositor to the UI > > > > > process to be able to get rid of the non accelerated rendering mode. > > > > > > > > This in no way improves the backing store memory consumption problem, as > > > > described above. If your argument is that OpenGL-and-GLX combo is still too > > > > heavy to initialize in every WebProcess, we should be looking into adopting > > > > EGL and OpenGL ES universally. > > > > > > The problem was not specific to GLX, it happened exactly the same in wayland > > > using EGL. The problem is quite simple, every gl context requires quite a > > > bit of memory and creating the context also takes some time. When you only > > > have one web view that's not a problem, the browser might be a bit slower > > > once at startup and the gl context only adds some more memory. But when you > > > open epiphany (or any other WebKitGTK+ based browser) with AC always > > > enabled, the memory required for all the gl contexts is too much for most of > > > the users. And every time you open a tab you notice the slowdown. Moving the > > > compositing to the UI (or to a dedicated process as Carlos suggested) would > > > use one gl context no matter how many tabs you have, fixing the problem. > > > > > > > Do you recall how much memory that was? Cause the biggest memory issue I > > recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some > > overhead, but when taken as a percentage of the whole WebProcess consumption > > I don't think you'd be able to mark that overhead as critical. > > I don't remember, it was small for a single tab, but too much for many tabs. > With current trunk loading about:blank in MiniBrowser I get: > > - Wayland no AC: UI: 17,3MB Web: 16,5MB > - Wayland AC: UI: 26,5MB Web: 22,3MB > - X11 no AC: UI: 12,6MB Web: 13,9MB > - X11 AC: UI: 14,5MB Web: 21,1MB > How does this difference scale on a real-life page? Like I said, let's specify the sites and do the measurements. > > When moving composition to a single process, you don't take into account > > that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is > > improved regarding painting, with Cairo all the memory still has to be > > allocated just as before. > > It's fine if only tabs currently using WebGL and GStreamer use additional gl > contexts, the same way it's fine right now that some tabs have AC mode > enabled. > > > If the GL context creation overhead (in terms of memory and time) is a > > problem, how is this not an even bigger problem for you when AC is entered > > on demand, which can happen a bunch of times on a single page? > > When a page enters and leaves AC, it's a single page doing so, I insist that > the problem is having Ac enabled in all the pages. IMO it's only a problem if you do no management of the idle pages. Or if you go out and spawn about:blank pages for every tab. > Note that when a page > enters AC due to a condition change, an animation ro whatever, the page is > already rendered so you are seeing the contents, not a white (or even black) > page. Starting epiphany with a single or even a few tabs with AC enabled, > was a bit slower but acceptable. But with some more tabs the thing was very > noticeable. Not to mention resizing the window. > Why is resizing the window an issue here? Is every web view being resized when you're doing that? I don't think you're rendering every loaded tab all the time, even if it's not focused? > > > > But even then, with lots of tabs open, the large majority of memory is not > > > > spent on the graphics pipeline, but other things like Web content and > > > > caches. You should be looking into WebProcess management instead. > > > > > > If we fix all those problems with cairo and WebKitGTK+ browsers are usable > > > with AC always enabled I'm open to try again, but that's not the case right > > > now, with our current code the amount of memory gl adds on top makes it > > > impossible. > > > > > > > How much is that amount of memory? What percentage is it compared to the > > memory consumption of that whole WebProcess? Let's specify Web pages to > > test, and produce massif profiles and memory mapping dumps for comparison. > > It's not that much percentage for a single web process. If the overhead of > cairo or any other thing is solved and makes this one insignificant, then > I'm open to try again, but we need to fix those first. > This just feels like from the memory consumption POV, we the graphics people are being asked to produce a miracle to reduce the memory burden that originates from spawning about:blank tabs. > > Anyway, my point is, why does Epiphany have to immediately spawn a > > WebProcess for each tab when it's launched, when I haven't even activated > > that tab? And why can't a WebProcess for a given tab be shut down after the > > tab wasn't activated for a while? That's what I meant with 'WebProcess > > management'. > > We could make improvements in process management, but they are not easy at > all. Any improvement there to should be done in WebKit, not in the browser > side. There are things that browsers can do, though, for example epiphany > delays the loads of tabs until they are activated, by using placeholder tabs > consisting of about:blank with a title. But a bunch of about:blank pages was > still a problem in terms of memory and startup times. > Again, I'd really like to hear why this can't be done at the browser level, or rather what still needs to be done at the WebKit level. > As Michael suggested we also have the problem of drivers. To enable AC > unconditionally we need a way to get detailed information from users having > problems. I thought about adding about:gpu or whatever, to show information > about the gpu, the driver, the gl context, the opengl version profile, the > extensions available, etc. With the idea of using > HardwareAccelerationManager.cpp to blacklist known buggy drivers. > > Any change in this needs to be done at the very beginning of a release cycle. OK, understandable.
(In reply to Zan Dobersek from comment #47) > On our side, we can only work against an OpenGL+GLX or OpenGLES+EGL library. > Driver bugs are not ours to fix. Other major browsers have GPU blacklists when there are unfixable driver bugs. If we can't take responsibility for whether WebKit ultimately works or not, then we can't do GPU rendering. Sorry, but driver bugs are common. > How well do you think you scale even with AC disabled if you volunteer to > spawn a WebProcess for each tab when upon launch? I just tested 180 blank tabs and it works fine, though it requires a lot of memory. > > (In reply to Zan Dobersek from comment #41) > This is a current feature of the Safari browser. I don't know at what level > it's implemented. You're sure? I remember when this code was added to and removed from WebKit. When I search for "Safari tab discarding," all the results relevant to tab discarding are for Chrome. Anyway, we don't implement complex low-level features at the browser level, we do it in WebKit. Especially since it's going to require information that's only available to WebKit to handle properly, e.g. whether a page has unload handlers, or whether a page is in page cache. > > In Epiphany, we work around lack of tab discarding by loading blank pages > > into all of the web views on startup, but it's not good enough as the memory > > usage is still significant when you have too many tabs open, using a bunch > > of memory to show nothing. > > > > An optimization would be to share the same web process among different tabs > > with the same security origin. This process model is probably needed for > > WebKit to remain competitive long-term. It might also be possible to create > > and attach the web views on demand as well, but that probably won't be > > useful with a per-origin process model, and it would still be just a hack. > > Proper solutions to these problems would be WebKit-level work. > > Can you explain why this can't be done in Epiphany? Because process launching is controlled by WebKit. Epiphany doesn't have any way to control which processes WebKit chooses to launch. We would need to add a new WebKitProcessModel. It would require changes throughout WebKit, because WebKit is not currently designed to support a per-origin process model. E.g. iframes need to be launched in the right process. We need a web compat plan for how to handle windows no longer having access to parent and child windows, since many websites will break (Apple is currently working on this with Google). That can only be handled in WebCore. And it all depends on Apple's process swap on navigation work, which is still experimental. (In reply to Zan Dobersek from comment #48) > This just feels like from the memory consumption POV, we the graphics people > are being asked to produce a miracle to reduce the memory burden that > originates from spawning about:blank tabs. Why do you think this is not a useful test? about:blank is just useful to show how much memory is required for a WebKitWebView to display nothing. It's a fact that AC mode requires more memory. You can compare with any website you prefer to use instead, so long as it doesn't ordinarily trigger AC mode.
www.gnome.org in Wayland: AC mode: UI 39.4 MiB, web 156.3 MiB Non AC: UI 31.1 MiB, 129.8 MiB Counting only the difference in web process memory usage, the difference would reach 1 GB more memory consumed at around 40 tabs.
(In reply to Zan Dobersek from comment #48) > (In reply to Carlos Garcia Campos from comment #44) > > (In reply to Zan Dobersek from comment #41) > > > (In reply to Carlos Garcia Campos from comment #40) > > > > (In reply to Zan Dobersek from comment #34) > > > > > (In reply to Carlos Garcia Campos from comment #31) > > > > > > (In reply to Zan Dobersek from comment #26) > > > > > > > Comment on attachment 342736 [details] > > > > > > > Patch > > > > > > > > > > > > > > View in context: > > > > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > > > > > > > > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > > > > > > > > + // If the coordinators are different it means that we are attaching a layer that was created by a different > > > > > > > > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > > > > > > > > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > > > > > > > > + // layer and its children. > > > > > > > > > > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes > > > > > > > that only complicate the CoordinatedGraphics stack and any future > > > > > > > improvements. I propose WebKitGTK+ adds an API that for the specific > > > > > > > UIProcess instance either enables or disables AC, but otherwise abandons > > > > > > > dynamic AC entry and exit. > > > > > > > > > > > > It's actually revealing existing bugs in most of the cases I would say. But > > > > > > still, we are not going to change it. > > > > > > > > > > This will certainly block async scrolling for the GTK+ port, because of how > > > > > the scrolling is handled. It might also collide with other improvements in > > > > > composition. > > > > > > > > Can't those be used only when in AC mode? > > > > > > > > > > Async scrolling requires constant AC mode. Other features will be used only > > > when in AC mode, some might require that mode to be constant as well. What I > > > don't want to waste time on is addressing the dynamic AC entry-and-exit > > > functionality. > > > > We won't be able to use async scrolling in GTK for now then. We have no > > choice right now. > > > > OK. > > > > > > > I don't think cairo is the problem either. > > > > > > > > > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has > > > > > to be used. This means rasterizing into CPU memory that then gets copied > > > > > over to the GPU. So you need to first waste the CPU memory to get all the > > > > > backing stores updated, before you waste the GPU memory to hold all the > > > > > backing store content there. > > > > > > > > > > Only improvement possible is leveraging mapping of GPU memory into > > > > > user-space and rasterizing with Cairo into that area. The largest problem > > > > > then is management of these memory areas, but I can assure you that handling > > > > > regularly-occurring AC entries and exits will not help one bit. > > > > > > > > With exactly the same cairo code epiphany was unusable for most of the users > > > > when we switched to always use AC, and became usable again when we added the > > > > on demand mode. This is a fact. I would love to switch to always AC, and > > > > remove all the complexity of switching between modes, but we simply can't, > > > > at least not right now. > > > > > > > > > > What I'm saying is that with Cairo, when in AC mode, you will have the > > > memory overhead for the duration between the start of painting into the > > > backing store until all that memory is copied over to the GPU. In that > > > context, Cairo is the problem. > > > > Yes, but the checks we did at the time were with about:blank pages. So, I > > believe you that cairo adds more overhead on top. > > > > about:blank still requires Cairo to render all the whiteness (yes, really). > So 8MB had to be allocated for that alone when in 1080p resolution. This is > not the case anymore, but I think that's already reflected in your > measurements below. I remember I compared the memory consumption with chrome at the time and the numbers were very similar, with the difference that chrome only had one context in the gpu process instead of one per tab. > > > Memory consumption in this case was 'improved' by removing the UpdateAtlas > > > cache, and relying on bmalloc to efficiently allocate all the CPU memory > > > into which the painting is done. But there's still spikes in memory > > > consumption as long as painting is done, as described before. > > > > > > > > > I think we would need to move the threaded compositor to the UI > > > > > > process to be able to get rid of the non accelerated rendering mode. > > > > > > > > > > This in no way improves the backing store memory consumption problem, as > > > > > described above. If your argument is that OpenGL-and-GLX combo is still too > > > > > heavy to initialize in every WebProcess, we should be looking into adopting > > > > > EGL and OpenGL ES universally. > > > > > > > > The problem was not specific to GLX, it happened exactly the same in wayland > > > > using EGL. The problem is quite simple, every gl context requires quite a > > > > bit of memory and creating the context also takes some time. When you only > > > > have one web view that's not a problem, the browser might be a bit slower > > > > once at startup and the gl context only adds some more memory. But when you > > > > open epiphany (or any other WebKitGTK+ based browser) with AC always > > > > enabled, the memory required for all the gl contexts is too much for most of > > > > the users. And every time you open a tab you notice the slowdown. Moving the > > > > compositing to the UI (or to a dedicated process as Carlos suggested) would > > > > use one gl context no matter how many tabs you have, fixing the problem. > > > > > > > > > > Do you recall how much memory that was? Cause the biggest memory issue I > > > recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some > > > overhead, but when taken as a percentage of the whole WebProcess consumption > > > I don't think you'd be able to mark that overhead as critical. > > > > I don't remember, it was small for a single tab, but too much for many tabs. > > With current trunk loading about:blank in MiniBrowser I get: > > > > - Wayland no AC: UI: 17,3MB Web: 16,5MB > > - Wayland AC: UI: 26,5MB Web: 22,3MB > > - X11 no AC: UI: 12,6MB Web: 13,9MB > > - X11 AC: UI: 14,5MB Web: 21,1MB > > > > How does this difference scale on a real-life page? Like I said, let's > specify the sites and do the measurements. Using about:blank is just a way to set a minimum, any other website will use at least that. > > > When moving composition to a single process, you don't take into account > > > that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is > > > improved regarding painting, with Cairo all the memory still has to be > > > allocated just as before. > > > > It's fine if only tabs currently using WebGL and GStreamer use additional gl > > contexts, the same way it's fine right now that some tabs have AC mode > > enabled. > > > > > If the GL context creation overhead (in terms of memory and time) is a > > > problem, how is this not an even bigger problem for you when AC is entered > > > on demand, which can happen a bunch of times on a single page? > > > > When a page enters and leaves AC, it's a single page doing so, I insist that > > the problem is having Ac enabled in all the pages. > > IMO it's only a problem if you do no management of the idle pages. Or if you > go out and spawn about:blank pages for every tab. That requires changes in WebKit much more complex than having AC on demand. > > Note that when a page > > enters AC due to a condition change, an animation ro whatever, the page is > > already rendered so you are seeing the contents, not a white (or even black) > > page. Starting epiphany with a single or even a few tabs with AC enabled, > > was a bit slower but acceptable. But with some more tabs the thing was very > > noticeable. Not to mention resizing the window. > > > > Why is resizing the window an issue here? Is every web view being resized > when you're doing that? Yes. > I don't think you're rendering every loaded tab all the time, even if it's > not focused? No, painting is suspended, but other things are done, because otherwise when you switch to another tab you see flickering or even worse effects. > > > > > But even then, with lots of tabs open, the large majority of memory is not > > > > > spent on the graphics pipeline, but other things like Web content and > > > > > caches. You should be looking into WebProcess management instead. > > > > > > > > If we fix all those problems with cairo and WebKitGTK+ browsers are usable > > > > with AC always enabled I'm open to try again, but that's not the case right > > > > now, with our current code the amount of memory gl adds on top makes it > > > > impossible. > > > > > > > > > > How much is that amount of memory? What percentage is it compared to the > > > memory consumption of that whole WebProcess? Let's specify Web pages to > > > test, and produce massif profiles and memory mapping dumps for comparison. > > > > It's not that much percentage for a single web process. If the overhead of > > cairo or any other thing is solved and makes this one insignificant, then > > I'm open to try again, but we need to fix those first. > > > > This just feels like from the memory consumption POV, we the graphics people > are being asked to produce a miracle to reduce the memory burden that > originates from spawning about:blank tabs. No, that's why we want to have AC on demand, because we know that gl requires more memory and we can't do anything about it. I'm sure we can do improvements on the graphics side, but to be able to switch to always AC we will require more changes in other parts (process management, idle tabs, etc.) > > > Anyway, my point is, why does Epiphany have to immediately spawn a > > > WebProcess for each tab when it's launched, when I haven't even activated > > > that tab? And why can't a WebProcess for a given tab be shut down after the > > > tab wasn't activated for a while? That's what I meant with 'WebProcess > > > management'. > > > > We could make improvements in process management, but they are not easy at > > all. Any improvement there to should be done in WebKit, not in the browser > > side. There are things that browsers can do, though, for example epiphany > > delays the loads of tabs until they are activated, by using placeholder tabs > > consisting of about:blank with a title. But a bunch of about:blank pages was > > still a problem in terms of memory and startup times. > > > > Again, I'd really like to hear why this can't be done at the browser level, > or rather what still needs to be done at the WebKit level. WebKit is the one spawning the processes, at the browser level we can only not create a web view to avoid the process from being launched. But the point is that we don't want to fix only epiphany, all WebKitGTK+ based applications should benefit from whatever we improve here. > > As Michael suggested we also have the problem of drivers. To enable AC > > unconditionally we need a way to get detailed information from users having > > problems. I thought about adding about:gpu or whatever, to show information > > about the gpu, the driver, the gl context, the opengl version profile, the > > extensions available, etc. With the idea of using > > HardwareAccelerationManager.cpp to blacklist known buggy drivers. > > > > Any change in this needs to be done at the very beginning of a release cycle. > > OK, understandable. It's clear that we can't switch to AC always *right now*, but we might by adopting any or several of the proposals made here. Some of them could be easy to try and some others are more long term goals. So, I propose to list and prioritize things we can do. For example: - Keep AC on demand, but never exit AC once entered for the same website/origin. I liked this idea, it's not a long term solution, but could be easily implemented and would avoid enter/leaves just when a tooltip is shown, for example. - Improve the memory consumption on the graphics side (cairo). - Add one process per origin process model. - Implement tab suspending. - Move the compositing to the UI or dedicated gpu process. - Make it possible to blacklist gpus, and add about:gpu to make it easier to collect the required info from users. Any other idea? Note these tasks are not mutually exclusive, and some of them are blockers like the gpu blacklisting.
> - Keep AC on demand, but never exit AC once entered for the same > website/origin. I liked this idea, it's not a long term solution, but could > be easily implemented and would avoid enter/leaves just when a tooltip is > shown, for example. If this is a valid option, it's the easiest way to fix this bug.
(In reply to Miguel Gomez from comment #52) > > - Keep AC on demand, but never exit AC once entered for the same > > website/origin. I liked this idea, it's not a long term solution, but could > > be easily implemented and would avoid enter/leaves just when a tooltip is > > shown, for example. > > If this is a valid option, it's the easiest way to fix this bug. Yes, I think it's good short-term solution to this bug while we develop a long term solution to be able to switch to AC mode always enabled. Note that I said for the same website/origin, not for the same webview.
(In reply to Carlos Garcia Campos from comment #51) > (In reply to Zan Dobersek from comment #48) > > (In reply to Carlos Garcia Campos from comment #44) > > > (In reply to Zan Dobersek from comment #41) > > > > (In reply to Carlos Garcia Campos from comment #40) > > > > > (In reply to Zan Dobersek from comment #34) > > > > > > (In reply to Carlos Garcia Campos from comment #31) > > > > > > > (In reply to Zan Dobersek from comment #26) > > > > > > > > Comment on attachment 342736 [details] > > > > > > > > Patch > > > > > > > > > > > > > > > > View in context: > > > > > > > > https://bugs.webkit.org/attachment.cgi?id=342736&action=review > > > > > > > > > > > > > > > > > Source/WebCore/platform/graphics/texmap/coordinated/CoordinatedGraphicsLayer.cpp:1009 > > > > > > > > > + // If the coordinators are different it means that we are attaching a layer that was created by a different > > > > > > > > > + // CompositingCoordinator than the current one. This happens because the layer was taken out of the tree > > > > > > > > > + // and then added back after AC was disabled and enabled again. We need to set the new coordinator to the > > > > > > > > > + // layer and its children. > > > > > > > > > > > > > > > > The dynamic AC entry and exit continues to produce bugs and require fixes > > > > > > > > that only complicate the CoordinatedGraphics stack and any future > > > > > > > > improvements. I propose WebKitGTK+ adds an API that for the specific > > > > > > > > UIProcess instance either enables or disables AC, but otherwise abandons > > > > > > > > dynamic AC entry and exit. > > > > > > > > > > > > > > It's actually revealing existing bugs in most of the cases I would say. But > > > > > > > still, we are not going to change it. > > > > > > > > > > > > This will certainly block async scrolling for the GTK+ port, because of how > > > > > > the scrolling is handled. It might also collide with other improvements in > > > > > > composition. > > > > > > > > > > Can't those be used only when in AC mode? > > > > > > > > > > > > > Async scrolling requires constant AC mode. Other features will be used only > > > > when in AC mode, some might require that mode to be constant as well. What I > > > > don't want to waste time on is addressing the dynamic AC entry-and-exit > > > > functionality. > > > > > > We won't be able to use async scrolling in GTK for now then. We have no > > > choice right now. > > > > > > > OK. > > > > > > > > > I don't think cairo is the problem either. > > > > > > > > > > > > It certainly is. Whenever anything is drawn, with Cairo, a backing store has > > > > > > to be used. This means rasterizing into CPU memory that then gets copied > > > > > > over to the GPU. So you need to first waste the CPU memory to get all the > > > > > > backing stores updated, before you waste the GPU memory to hold all the > > > > > > backing store content there. > > > > > > > > > > > > Only improvement possible is leveraging mapping of GPU memory into > > > > > > user-space and rasterizing with Cairo into that area. The largest problem > > > > > > then is management of these memory areas, but I can assure you that handling > > > > > > regularly-occurring AC entries and exits will not help one bit. > > > > > > > > > > With exactly the same cairo code epiphany was unusable for most of the users > > > > > when we switched to always use AC, and became usable again when we added the > > > > > on demand mode. This is a fact. I would love to switch to always AC, and > > > > > remove all the complexity of switching between modes, but we simply can't, > > > > > at least not right now. > > > > > > > > > > > > > What I'm saying is that with Cairo, when in AC mode, you will have the > > > > memory overhead for the duration between the start of painting into the > > > > backing store until all that memory is copied over to the GPU. In that > > > > context, Cairo is the problem. > > > > > > Yes, but the checks we did at the time were with about:blank pages. So, I > > > believe you that cairo adds more overhead on top. > > > > > > > about:blank still requires Cairo to render all the whiteness (yes, really). > > So 8MB had to be allocated for that alone when in 1080p resolution. This is > > not the case anymore, but I think that's already reflected in your > > measurements below. > > I remember I compared the memory consumption with chrome at the time and the > numbers were very similar, with the difference that chrome only had one > context in the gpu process instead of one per tab. > > > > > Memory consumption in this case was 'improved' by removing the UpdateAtlas > > > > cache, and relying on bmalloc to efficiently allocate all the CPU memory > > > > into which the painting is done. But there's still spikes in memory > > > > consumption as long as painting is done, as described before. > > > > > > > > > > > I think we would need to move the threaded compositor to the UI > > > > > > > process to be able to get rid of the non accelerated rendering mode. > > > > > > > > > > > > This in no way improves the backing store memory consumption problem, as > > > > > > described above. If your argument is that OpenGL-and-GLX combo is still too > > > > > > heavy to initialize in every WebProcess, we should be looking into adopting > > > > > > EGL and OpenGL ES universally. > > > > > > > > > > The problem was not specific to GLX, it happened exactly the same in wayland > > > > > using EGL. The problem is quite simple, every gl context requires quite a > > > > > bit of memory and creating the context also takes some time. When you only > > > > > have one web view that's not a problem, the browser might be a bit slower > > > > > once at startup and the gl context only adds some more memory. But when you > > > > > open epiphany (or any other WebKitGTK+ based browser) with AC always > > > > > enabled, the memory required for all the gl contexts is too much for most of > > > > > the users. And every time you open a tab you notice the slowdown. Moving the > > > > > compositing to the UI (or to a dedicated process as Carlos suggested) would > > > > > use one gl context no matter how many tabs you have, fixing the problem. > > > > > > > > > > > > > Do you recall how much memory that was? Cause the biggest memory issue I > > > > recall was fixed 1.5 years ago in bug #164049. Yes, GL will always have some > > > > overhead, but when taken as a percentage of the whole WebProcess consumption > > > > I don't think you'd be able to mark that overhead as critical. > > > > > > I don't remember, it was small for a single tab, but too much for many tabs. > > > With current trunk loading about:blank in MiniBrowser I get: > > > > > > - Wayland no AC: UI: 17,3MB Web: 16,5MB > > > - Wayland AC: UI: 26,5MB Web: 22,3MB > > > - X11 no AC: UI: 12,6MB Web: 13,9MB > > > - X11 AC: UI: 14,5MB Web: 21,1MB > > > > > > > How does this difference scale on a real-life page? Like I said, let's > > specify the sites and do the measurements. > > Using about:blank is just a way to set a minimum, any other website will use > at least that. > Yes, what I'm proposing is investigating what that additional amount of overhead is. > > > > When moving composition to a single process, you don't take into account > > > > that GL contexts are still needed for WebGL and GStreamer-GL. And nothing is > > > > improved regarding painting, with Cairo all the memory still has to be > > > > allocated just as before. > > > > > > It's fine if only tabs currently using WebGL and GStreamer use additional gl > > > contexts, the same way it's fine right now that some tabs have AC mode > > > enabled. > > > > > > > If the GL context creation overhead (in terms of memory and time) is a > > > > problem, how is this not an even bigger problem for you when AC is entered > > > > on demand, which can happen a bunch of times on a single page? > > > > > > When a page enters and leaves AC, it's a single page doing so, I insist that > > > the problem is having Ac enabled in all the pages. > > > > IMO it's only a problem if you do no management of the idle pages. Or if you > > go out and spawn about:blank pages for every tab. > > That requires changes in WebKit much more complex than having AC on demand. > > > > Note that when a page > > > enters AC due to a condition change, an animation ro whatever, the page is > > > already rendered so you are seeing the contents, not a white (or even black) > > > page. Starting epiphany with a single or even a few tabs with AC enabled, > > > was a bit slower but acceptable. But with some more tabs the thing was very > > > noticeable. Not to mention resizing the window. > > > > > > > Why is resizing the window an issue here? Is every web view being resized > > when you're doing that? > > Yes. > > > I don't think you're rendering every loaded tab all the time, even if it's > > not focused? > Is this specific to GLX? > No, painting is suspended, but other things are done, because otherwise when > you switch to another tab you see flickering or even worse effects. > > > > > > > But even then, with lots of tabs open, the large majority of memory is not > > > > > > spent on the graphics pipeline, but other things like Web content and > > > > > > caches. You should be looking into WebProcess management instead. > > > > > > > > > > If we fix all those problems with cairo and WebKitGTK+ browsers are usable > > > > > with AC always enabled I'm open to try again, but that's not the case right > > > > > now, with our current code the amount of memory gl adds on top makes it > > > > > impossible. > > > > > > > > > > > > > How much is that amount of memory? What percentage is it compared to the > > > > memory consumption of that whole WebProcess? Let's specify Web pages to > > > > test, and produce massif profiles and memory mapping dumps for comparison. > > > > > > It's not that much percentage for a single web process. If the overhead of > > > cairo or any other thing is solved and makes this one insignificant, then > > > I'm open to try again, but we need to fix those first. > > > > > > > This just feels like from the memory consumption POV, we the graphics people > > are being asked to produce a miracle to reduce the memory burden that > > originates from spawning about:blank tabs. > > No, that's why we want to have AC on demand, because we know that gl > requires more memory and we can't do anything about it. I'm sure we can do > improvements on the graphics side, but to be able to switch to always AC we > will require more changes in other parts (process management, idle tabs, > etc.) > > > > > Anyway, my point is, why does Epiphany have to immediately spawn a > > > > WebProcess for each tab when it's launched, when I haven't even activated > > > > that tab? And why can't a WebProcess for a given tab be shut down after the > > > > tab wasn't activated for a while? That's what I meant with 'WebProcess > > > > management'. > > > > > > We could make improvements in process management, but they are not easy at > > > all. Any improvement there to should be done in WebKit, not in the browser > > > side. There are things that browsers can do, though, for example epiphany > > > delays the loads of tabs until they are activated, by using placeholder tabs > > > consisting of about:blank with a title. But a bunch of about:blank pages was > > > still a problem in terms of memory and startup times. > > > > > > > Again, I'd really like to hear why this can't be done at the browser level, > > or rather what still needs to be done at the WebKit level. > > WebKit is the one spawning the processes, at the browser level we can only > not create a web view to avoid the process from being launched. But the > point is that we don't want to fix only epiphany, all WebKitGTK+ based > applications should benefit from whatever we improve here. > New WebProcess is only spawned when a load is triggered on a web view, not when the web view is created. > > > As Michael suggested we also have the problem of drivers. To enable AC > > > unconditionally we need a way to get detailed information from users having > > > problems. I thought about adding about:gpu or whatever, to show information > > > about the gpu, the driver, the gl context, the opengl version profile, the > > > extensions available, etc. With the idea of using > > > HardwareAccelerationManager.cpp to blacklist known buggy drivers. > > > > > > Any change in this needs to be done at the very beginning of a release cycle. > > > > OK, understandable. > > It's clear that we can't switch to AC always *right now*, but we might by > adopting any or several of the proposals made here. Some of them could be > easy to try and some others are more long term goals. So, I propose to list > and prioritize things we can do. For example: > > - Keep AC on demand, but never exit AC once entered for the same > website/origin. I liked this idea, it's not a long term solution, but could > be easily implemented and would avoid enter/leaves just when a tooltip is > shown, for example. > > - Improve the memory consumption on the graphics side (cairo). > > - Add one process per origin process model. > > - Implement tab suspending. > > - Move the compositing to the UI or dedicated gpu process. > > - Make it possible to blacklist gpus, and add about:gpu to make it easier > to collect the required info from users. > > Any other idea? Note these tasks are not mutually exclusive, and some of > them are blockers like the gpu blacklisting. Delayed AC entry could help, especially with bugs like this one.
(In reply to Michael Catanzaro from comment #50) > www.gnome.org in Wayland: > > AC mode: UI 39.4 MiB, web 156.3 MiB > Non AC: UI 31.1 MiB, 129.8 MiB > > Counting only the difference in web process memory usage, the difference > would reach 1 GB more memory consumed at around 40 tabs. Don't know if you tested with Epiphany, but given I can reproduce similar numbers with Epiphany 3.28, I'd like to point out that a very large proportion of consumed memory is allocated from the loaded Web extension.
Created attachment 343045 [details] Epiphany 3.28 WebKitWebProcess massif profile Epiphany was launched via $ WEBKIT_FORCE_COMPOSITING_MODE=1 Malloc=1 epiphany -i http://www.gnome.org Quick sum of all the allocations coming from the extension quickly goes north of 50MB.
Created attachment 343046 [details] Epiphany 3.28 WebKitWebProcess massif profile Similar Massif profile, but now with G_SLICE=always-malloc for completeness. It doesn't have a big impact on results though. My point here is, if you're looking to optimize memory usage in WebProcess instances, this extension (I assume the ad blocker) is a very good place to start regardless of how much memory AC consumes in parallel.
(In reply to Zan Dobersek from comment #57) > Created attachment 343046 [details] > Epiphany 3.28 WebKitWebProcess massif profile > > Similar Massif profile, but now with G_SLICE=always-malloc for completeness. > It doesn't have a big impact on results though. > > My point here is, if you're looking to optimize memory usage in WebProcess > instances, this extension (I assume the ad blocker) is a very good place to > start regardless of how much memory AC consumes in parallel. Ouch. This is one more reason to try and enable content extensions, which should be much better than the current adblocker present in Epiphany. I'll try to get back to bug #167941 in the next days.
(In reply to Miguel Gomez from comment #25) > Created attachment 342736 [details] > Patch In the end this is not conflicting with Zan's refactor so I'll rebase and land this patch.
Created attachment 343594 [details] Patch
Comment on attachment 343594 [details] Patch Clearing flags on attachment: 343594 Committed r233193: <https://trac.webkit.org/changeset/233193>
All reviewed patches have been landed. Closing bug.